# Binding-matched monotonic operation settlement
## Trigger
Use when concurrent retries or observers settle one shared durable operation record, especially when a timeout can race a late response or an operation identifier can appear with different request fingerprints or authorization binding generations.
## Failure prevented
Prevents timeout from erasing committed success and prevents stale or mismatched success from hijacking the record. Blind last-write-wins and blind success preference are unsafe because arrival order and response status do not prove that the evidence belongs to the current reservation.
## Practical steps
1. Keep one authoritative settlement path. Per-attempt timeouts, metrics, and diagnostics must not directly overwrite canonical outcome.
2. Establish the reservation atomically before execution. Store the operation identifier, canonical request fingerprint, and authorization binding, including a durable non-reusable generation. Bind execution permission to that reservation.
3. Serialize settlement with a row lock or an atomic conditional update. Re-read the reservation inside that boundary; do not validate from a stale replica or cache.
4. Validate the complete tuple before merging status: operation identifier, request fingerprint, and binding generation must match exactly, with unambiguous canonical encoding and null handling. A matching identifier alone is insufficient.
5. Accept a terminal success only from valid evidence for the exact tuple, and persist its immutable result atomically with the completed state. Make duplicate exact-match successes idempotent.
6. Apply a monotonic state rule: matching completed may upgrade unknown or pending; completed cannot become unknown because of a later timeout. A timeout is observer uncertainty, not contrary commit evidence. Define explicit joins for committed failure, cancellation, and expiration rather than relying on numeric rank alone.
7. If evidence has a mismatched fingerprint or binding generation, leave the authoritative record unchanged. Quarantine only attempt-scoped metadata, with retention and access controls that do not leak the response.
8. Replay a completed result only after validating the retry's exact tuple. If rebinding or request editing is supported, atomically supersede the old epoch and invalidate prior-generation settlement evidence.
## Limits
This settlement rule does not make an external side effect atomic with the record. The effect itself still needs an idempotency mechanism or reconciliation. Unknown means locally indeterminate, not rollback. Binding generation is safe only when its lifecycle is durable and advances atomically on revocation or rebinding. Terminal failure versus success requires an explicit conflict policy.
## Reasoning basis
The supporting analysis was reasoned design review, not executed tests.