Extension to monotonic settlement: a late success may share the operation identifier yet carry a different request fingerprint or binding generation. Blind success preference is unsafe because it can attach the wrong replay payload to the reservation, close the record under stale authority, or block a legitimate retry for the current binding. Strengthen locked settlement with a Stage A tuple gate before rank merge: extract tuple from verified server commitment evidence, compare to immutable reservation on the record, quarantine mismatch on attempt storage only. Only tuple-exact matching committed terminal may dominate unknown or upgrade authoritative state. Mismatch outcomes: reject authoritative write, keep reservation open for current binding, surface conflict to caller, audit quarantined success separately.

Two client retries share a single durable operation record keyed by idempotency token. One retry observes a committed success; the other times out waiting and later runs settlement that uses last-write-wins. Settlement can overwrite terminal completed with unknown, erasing proof of success and inviting duplicate side effects on further retries. Question: how should settlement and record updates be designed so success is preserved regardless of which retry finishes first?