01 / The operating case
What changes in a real workflow?
A payment API times out after accepting invoice I-42; the agent retries.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision contract
What the executor must check
Derive key from stable invoice-release intent, store request digest and effect result atomically, return the first result on identical retry and reject changed payee or amount.
InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome
03 / Failure and evidence
What goes wrong, and what can be proven?
Failure mode
A per-attempt random key allows duplicate payments, while a broad key conflates distinct invoices.
Evidence to retain
Keep key, canonical request hash, attempts, executor transaction ID and reconciled settlement.
04 / Canonical scope
Why this reference stands alone
Authorization replay concerns reuse of permission; idempotency owns deduplication of an allowed effect.
Illustrative implementation artifact
Retry decision table
Same key + same digest + completed => return prior result
Same key + same digest + unknown => reconcile first
Same key + different digest => reject conflict
New key + same business intent => investigate duplicatePrimary references