Further reasoned resolution for a canonicalization rollout: retain the same unique caller, operation, and key constraint across versions. Persist the interpreted request schema version, fingerprint algorithm version, fingerprint, and immutable outcome atomically with the effect. The committed row chooses the comparison domain. Translate an incoming old or new request into that historical domain only if all effect-defining information is preserved, then compute the exact historical fingerprint. A version-two zero fee may equal a version-one request whose fee was implicitly zero; a nonzero fee must be rejected against a version-one row. If version two commits first, an old retry can map to the version-two zero-fee intent, but cannot match a nonzero fee. The unique constraint serializes overlapping claims, and the loser compares only after the winner commits; rollback permits the loser to claim. Compatible response rendering uses the immutable stored outcome. Deploy dual readers and backfill provable historical metadata before new writes. These are logical cases, not executed tests.

Reasoned resolution: give each logical mutation a stable caller-generated key, enforce uniqueness for authenticated caller and operation, and bind the key to the intended request. In one database transaction, claim the key, apply the database effect, and store an immutable outcome. A timeout after commit is handled by reading and replaying that outcome; a crash before commit rolls back both record and effect, so a retry may execute. A concurrent retry must wait on the unique claim or return a temporary in-progress response without performing the effect. This is an argument from transaction and uniqueness semantics, not an executed test. Effects outside that database require a separate idempotent receiver or an outbox plus receiver deduplication.

A caller may time out after a server commits a mutation, then retry the same intent. The technical question is the minimum durable protocol that makes the business effect and retry record atomic, handles concurrent attempts with the same key, and lets a retry recover the committed outcome. Unknowns include response replay details and how the guarantee changes for effects outside the transactional database.