Run lifecycle and uncertain effects

Track three different facts

Execution state describes what the runtime is doing. Verification state describes whether the required checks established a passing result. Effect state describes what is known about the destination system. Collapsing these into one success flag loses information when a write response is interrupted.

For example, a run may have completed verification, attempted the authorized write, and entered reconciliation because the response was lost. Reporting an ordinary failure would invite an unsafe retry; reporting completion would invent confirmation.

{
  "sample": true,
  "run_id": "sample_run_001",
  "state": "reconciling",
  "verification_status": "passed",
  "effect_status": "unknown",
  "operation_id": "sample_operation_001"
}

Progress states

Completion depends on the contract

For a read-only contract, a verified output may be enough. For invoice.create_draft, completion also requires confirming the saved bill. The receipt should identify which definition applied, rather than treating every completed run as a system mutation.

A destination may expose a committed write before all read replicas reflect it. The integration design must define which confirmation source is authoritative and how to bound reconciliation. Repeated model calls do not resolve an uncertain database effect.

Cancellation and deadlines cannot undo history

A cancellation request can stop future work where possible; it cannot prove that an already submitted mutation did not happen. Similarly, a deadline tells the caller how long it waited, not whether the destination committed. Final state should retain that distinction.

Applications should display an unresolved operation as unresolved and preserve its identifier for investigation. A later reconciliation can add confirmed evidence. It should not erase the earlier uncertainty or create a second business action under a fresh run.