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.