---
id: ADR-PFM-SEC-005
title: Durable execution after committed intent
product_area: platform
module: security
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
decision: Use durable Step Functions jobs and start execution after job persistence commits; provisioning and
  retirement couple domain intent to job creation; standalone flush/refresh jobs and onboarding reservation
  have their own creation boundaries.
constrains:
- SVC-PFM-SEC-tenants
- SVC-PFM-SEC-security
- WF-PFM-SEC-001
- WF-PFM-SEC-002
- WF-PFM-SEC-003
- WF-PFM-SEC-004
- WF-PFM-SEC-008
- WF-PFM-SEC-010
- WF-PFM-SEC-013
origin: services-platform:docs/jobs.md (the durable job standard); docs/tenants/tenant-lifecycle-plan.md#4
alternatives:
- option: Execute long work entirely within the HTTP request.
  why_not: The recorded reset timeout demonstrates that a request lifetime cannot reliably contain batched
    removal.
- option: Start external execution before the database commits.
  why_not: A database rollback cannot undo a running external execution, so the job could act without committed
    authority.
consequences:
- Coupled submissions commit domain intent and the job together; standalone jobs have no companion domain write
  to promise.
- Provisioning and purge declare domain failure consequences; generic reconciliation and operator schedule
  recovery have different duties.
- The execution owns waits and batch loops rather than a long-running request process.
supersedes: []
evidence:
- 'services-platform at ad3f6a65: the records named in origin and the code cited by the constrained artifacts'
examined_at: '2026-10-23'
examiner: codex
---

# Durable execution after committed intent

## Context

The durable-job standard is the existing origin. The design describes its actual applications rather than claiming every job shares one domain transaction or domain consequence.

Stopped retirement watchers require resume; portal reservation occurs during its job. These boundaries must remain visible in implementation preparation.

## Decision

Use durable Step Functions jobs and start execution after job persistence commits; provisioning and retirement couple domain intent to job creation; standalone flush/refresh jobs and onboarding reservation have their own creation boundaries.

## Alternatives Considered

Execute long work entirely within the HTTP request. The recorded reset timeout demonstrates that a request lifetime cannot reliably contain batched removal.

Start external execution before the database commits. A database rollback cannot undo a running external execution, so the job could act without committed authority.

## Consequences

Coupled submissions commit domain intent and the job together; standalone jobs have no companion domain write to promise.

Provisioning and purge declare domain failure consequences; generic reconciliation and operator schedule recovery have different duties.

The execution owns waits and batch loops rather than a long-running request process.