---
id: ADR-PFM-OPS-002
title: A job is recorded with its business change and started after the commit
product_area: platform
module: operations
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03
decision: >-
  Record the job with the business change and start it after commit; forgiving callers retain a successful
  submission response, while strict callers can report a start error.
constrains:
  - DOM-PFM-OPS-001
  - WF-PFM-OPS-001
  - WF-PFM-OPS-003
  - WF-PFM-OPS-005
  - SVC-PFM-OPS-jobs
origin: >-
  services-platform:docs/jobs.md#2. Adding a job (step 8) and #4 (Rhythm never calls an external service with
  a transaction open)
alternatives:
  - option: Execution start before commit
    why_not: 'A started execution could survive rollback, and the external call would prolong database locks.'
  - option: A separate start queue
    why_not: >-
      The pending job already provides durable evidence for reconciliation, though it does not provide a
      durable start retry.
  - option: Treat every start failure as a failed submission
    why_not: An error after commit cannot mean that the business change was rolled back.
consequences:
  - A job that never starts normally becomes eligible for reconciliation after fifteen minutes of silence.
  - Failure effects must handle work that did not execute.
  - Workspace provisioning retry uses the strict start path.
supersedes: []
evidence:
  - >-
    macroservice-libraries at 54536a4: engine/job-engine.ts (createJob, startJob,
    startJobOrLeaveToReconciler).
  - 'services-platform at ad3f6a6: docs/jobs.md §2, §4; docs/queued-work.md §6.'
  - >-
    codex examination 2026-10-23: checked the pinned source anchors, planning references and enforcement
    boundaries; unresolved limits are recorded in module findings.
---

# A job is recorded with its business change and started after the commit

## Context

Database submission and orchestration start cannot commit as one transaction.

## Decision

Commit the business records and job together, then call the start helper appropriate to the caller. The forgiving helper logs a failed start and returns the recorded job. Strict callers propagate the error; reconciliation can later fail an unstarted job.

## Alternatives Considered

Starting before commit risks orphaned execution. A separate queue would add start recovery machinery. Uniform error handling would obscure the distinction between committed work and execution failure.

## Consequences

Clients and operators need to distinguish a committed submission from a successful execution start.