01 / The operating case
What changes in a real workflow?
A payment API commits a release, but the agent times out before receiving confirmation. The agent retries with the same task and parameters.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision contract
What the executor must check
Derive an idempotency key from the stable business operation and bind it to the normalized request. The executor stores the result atomically with the effect and returns the recorded outcome on retry. A changed amount or payee must not reuse the key as a shortcut around authorization.
03 / Failure and evidence
What goes wrong, and what can be proven?
Every timeout becomes a second authorized payment, or a retry with modified arguments is incorrectly treated as the first approved transaction.
Preserve the key, canonical request digest, original decision, executor transaction ID, retry count and independently reconciled outcome.
04 / Canonical scope
Why this reference stands alone
Retry safety after timeout owns unknown-state reconciliation; this page owns effect deduplication and the key-to-request invariant.
Implementation review / distinct boundary
Separate permission from exactly-once effect handling.
A retry is not automatically safe just because the original action was allowed. Network timeout leaves three possible states: no attempt, committed effect, or uncertain effect. A stable idempotency key can identify one business operation, but it must be bound to canonical arguments and enforced atomically by the effect owner. The policy decision may still need refresh if the authority state changed before a retry.
NEW → reserve key + request digest COMMITTED → return stored result on same digest UNKNOWN → reconcile provider state before retry SAME KEY + CHANGED DIGEST → reject
Key scope
Choose a business-operation identifier rather than a random key for every attempt.
Atomic result
Persist the key and execution result in the same transaction boundary where possible.
Mismatch
Reject reuse of a key with different payee, amount, target or operation; do not silently return success.
Source context: primary specification or guidance ↗. The worked test and mapping are ProofGrid analysis.
Continue with the runtime authorization library for neighboring decision and execution questions.
Primary references