This standalone reasoning problem examines two retries sharing one durable operation record. One retry observes a committed result while another later times out, and a last-write-wins update incorrectly replaces completed with unknown. The key unknowns are the settlement state model, monotonic transition rules, and how to handle either completion order without losing success. No repository inspection or tests are involved.

Reasoning, not executed tests: model settlement as evidence ordered by authority, not by arrival time. A committed terminal result for the exact operation and request binding dominates an unknown timeout. Under an atomic compare-and-set or row lock, merge each report with the current record using a monotonic transition: unknown may become completed when verified commit evidence exists; completed remains completed on timeout; timeout cannot erase the committed result. If timeout arrives first, record unknown and keep the operation retryable or pending reconciliation; a later verified commit upgrades it to completed. If success arrives first, persist completed plus the immutable response or result identifier; a later timeout is recorded only as telemetry or ignored for authoritative state. If the storage layer cannot enforce conditional monotonic updates, serialize settlement through a transaction, append-only event log, or equivalent reconciliation pass; blind last-write-wins is insufficient. Validate identity and request fingerprint before allowing a late success to upgrade the record, and reject or quarantine mismatches. Once completed, replay the stored result for all matching retries. Executed tests: none; this is a standalone reasoning answer.

Reasoning, not executed tests: locked settlement needs a validation gate before the monotonic rank merge. Under the record lock or an equivalent atomic conditional update, compare the late success evidence against the immutable reservation tuple: operation identifier, request fingerprint, and authorization or binding generation. Only an exact tuple match may transition unknown or pending to completed and install the response. A matching operation identifier alone is insufficient. On any fingerprint or binding mismatch, leave authoritative settlement unchanged and store the evidence only in attempt-specific quarantine or diagnostics; never let it upgrade the shared record. If the record is already completed, replay only the result bound to its reserved tuple. Blindly preferring every successful response is unsafe because a stale retry, a different request, or an old authorization generation could attach an unintended result, expose another operation's response, or finalize a record under superseded authority. The safe ordering is: authenticate and validate tuple, acquire serialization, re-read the reservation, apply monotonic transition only on exact match, commit atomically, then replay the immutable result. Executed tests: none; this is standalone reasoning.