Why idempotency does not prove one-use human approval

Deduplicating a request is a different job

Idempotency usually says, “Treat retries carrying this key as the same request.” It can prevent duplicate processing at one endpoint. It does not automatically say, “Only one successor may consume this exact human decision across every competing path.”

That second claim needs an admission boundary tied to the decision itself: the exact decision digest, request and action revisions, packet digest, approved scope, successor identity, expiry, current status, and a durable uniqueness rule.

A compact race

1. 10:00:00.000 — a human approves successor scope canary-only.
2. 10:00:00.120 — worker A and worker B both read the approval as active.
3. 10:00:00.130 — A atomically claims the one allowed slot and commits a receipt.
4. 10:00:00.131 — B’s competing claim fails. It must not start.
5. After restart — A must read back its accepted claim before successor work begins; a missing or different receipt is a stop.

An idempotency key shared by A and B might collapse requests, but it does not by itself prove which successor was admitted, bind the winning claim to the exact approval, or preserve that answer through a crash.

What the candidate checks

The candidate receipt records a claim order and references the decision, request, action, packet, successor, scope, expiry, status evidence, and start evidence. Cross-record validation rejects a claim made after start, a stale replay, an expired or trusted-revoked decision, a divergent request, scope expansion, and a non-approval decision.

The separate who-decides 44-case proof exercises overlapping claims and starts, restart after claim, concurrent revoke/start, crash after intent, and a legacy/candidate writer race inside a declared local, same-file SQLite boundary.

Restart and ambiguity are part of the design

A process that crashes after intent but before durable admission cannot infer permission from memory. It needs durable readback of its own accepted claim. If external execution may have started but its outcome is uncertain, the honest result is an ambiguous report for human review—not an automatic retry dressed up as idempotency.

What this does not prove

• No distributed consensus or cross-store atomicity.
• No exactly-once provider call or exactly-once external effect.
• No safe automatic retry after an uncertain external outcome.
• No authority from the receipt itself; issuer trust and the admission policy are separate.
• No portable proof of current expiry or revocation from self-asserted fields alone.

See the exact negative fixtures for claim after start, stale replay, and scope expansion.