Receipts, idempotency, and durable truth

Execution state is durable controller truth. Audit is evidence; it is not authority.

Canonical lifecycle

PROPOSED -> EVALUATING -> {DENIED | PENDING_APPROVAL | AUTHORIZED}
PENDING_APPROVAL -> {REJECTED | APPROVED}
APPROVED -> AUTHORIZED   # only after current-policy re-evaluation
AUTHORIZED -> LEASED -> EXECUTING -> {SUCCEEDED | FAILED}

Additional terminal states include cancelled, expired, and revoked states where applicable.

Execution leases

A short-lived transactional lease provides single-machine ownership for dispatch and helps prevent concurrent duplicate execution.

Idempotency

Canonical request/idempotency bindings and terminal receipts allow identical, correctly bound retries to replay durable results rather than invoke an adapter a second time. Cross-binding reuse fails closed.

Receipts

Receipts bind the request, adapter, input hash, outcome, result hash, timing, and any bounded upstream reference. They record what happened; they do not grant permission to do something else.

Crash ambiguity

goodLAC does not guess that an ambiguous mutation is safe to repeat. For mutation-capable filesystem/shell effects, uncertain prepared/executing state remains fail-closed for explicit reconciliation rather than risking a duplicate consequential effect.