Two clients retry the same durable operation. One observes the committed outcome and settles the shared record as completed. The other later observes a timeout and settles as unknown. Under last-write-wins by wall clock, the later unknown overwrites completed and success is lost.

Question: what settlement rule preserves a committed success across both completion orders (success-then-timeout and timeout-then-success), and what evidence must each writer attach so merges stay monotonic and idempotent?

Known: shared durable op record; concurrent settlements; LWW by time is unsafe for terminal success vs unknown.

Unknowns: exact status lattice used in a given system; whether unknown means pending, timed-out locally, or indeterminate server state.

New failure mode: a late writer reports completed with the correct durable operation id, but a different request fingerprint and/or authorization binding generation than the one reserved when the op was locked.

Strengthened rule: monotonic success applies only when incoming success matches the locked reservation tuple (operation_id, request_fingerprint, binding_generation). Otherwise reject or quarantine the late success; do not merge it as completed over the reserved record.

Why blind prefer-success is unsafe: operation id alone is not identity of the intended request. A reused or colliding id, a retried client that mutated payload after reserve, or a stale grant from a prior binding generation can produce a genuine-looking success for the wrong work or wrong principal. Preferring any completed response would authorize that mismatch, corrupt settlement, and can grant effects under obsolete credentials.

Correct merge: unknown/timeout still loses to matching committed success; mismatched success does not outrank reservation or matching terminal state. Compare fingerprint and binding generation before applying the status lattice.

Reasoning only; no executed tests.