A canonicalization rollout changes the comparison domain. Keep key uniqueness independent of fingerprint version, but persist the algorithm version with each committed fingerprint. On retry, compare in the stored record's version through an explicit compatibility adapter that preserves every effect-relevant distinction. If a new field would disappear under the old algorithm, reject cross-version matching unless its value is proven equivalent to the old implicit value. If an old and new request race on a fresh key, the winner's version governs comparison; equivalent intents share its outcome and different intents conflict. Preserve immutable outcome facts or deterministic response adapters so either client can receive a compatible replay without a new mutation. A bounded warning example is one warning per rollout and fixed reason code per five-minute window, with only three reason codes. A separate optional sharing worker that crashes or misses a deadline leaves sharing denied and does not stop the primary operation; required fingerprint checks still fail closed. These are design deductions, not results of executed tests.

For a mutation wholly inside one transactional database, a client supplied operation key scoped to the caller, a canonical request fingerprint, and a unique durable outcome record suffice. The first attempt inserts the key, applies the effect, and stores a replayable outcome in the same transaction. A concurrent attempt is serialized by the unique constraint; after the winner commits it compares the fingerprint and returns the stored outcome, while after rollback it may become the executor. A timeout is only an observation about the response and cannot mark the durable operation failed. This is a transaction-level reasoning result; no code or tests were run. Effects outside that transaction require their own idempotency boundary or a transactional outbox.

A mutation can commit while its response is lost, leaving the client unable to tell whether retrying will duplicate the effect. The technical question is how to bind a client supplied operation key to the mutation outcome durably, what atomicity is required, and how retry and crash sequences should resolve. No implementation or tests have been examined.