Binding-matched monotonic operation settlement

Trigger

Use when concurrent retries or observers settle one shared durable operation record, especially when wall-clock last-write-wins, observer timeouts writing unknown, or late terminal responses are in play.

Failure prevented

Prevents two corruptions of the shared record:

1. A later local timeout or unknown overwriting an earlier committed completed and erasing success.
2. A late terminal that shares the operation id but not the reserved request fingerprint or authorization binding generation from settling the wrong request or stale credentials.

Also prevents the unsafe shortcut of blindly preferring every successful response when only the operation id matches.

Practical steps

1. On reserve or lock, persist operationid, requestfingerprint, and binding_generation as one reservation tuple.
2. Settle with stored equals merge(stored, incoming), or an equivalent conditional update. Never overwrite by writer wall-clock alone.
3. Use a status lattice from low to high: unknown or pending, then in_progress, then reservation-matching terminal. Matching completed outranks unknown in both orders (success then timeout; timeout then success). Observer timeout may propose only unknown and must never outrank a matching committed terminal or clear a completed result payload.
4. Pair inprogress with a lease, expiry, or attempt generation so an abandoned writer can be demoted to pending or unknown; without that, ranking unknown below inprogress leaves a crashed attempt stuck and blocks legitimate peer settlement.
5. Before any status merge that promotes a terminal, require an exact match on the full reservation tuple. On match, apply the lattice so matching completed upgrades prior unknown. On mismatch, reject or move to an explicit conflict or quarantine state that freezes ordinary lattice merges; do not store the mismatched terminal on the reserved record, and do not leave the caller believing durable success unless a separate authoritative path records it.
6. Define an explicit join or conflict terminal for completed versus failed under the same matching reservation so peer terminals cannot silently overwrite each other.
7. When two reservation-matching completed values carry different authoritative payloads, treat that as conflict or quarantine rather than last-write-wins on the payload.
8. Attach outcome class on each write (committed success, committed failure, observer-local timeout). Attach authoritative result payloads only on reservation-matching committed paths.

Limits

• unknown means observer-local indeterminate state, not authoritative rollback of a commit.
• Status merge does not make side effects and status writes one atomic unit.
• Sticky reservation with rotating bindings may correctly refuse settlement and leave an operation non-terminal until rebind or supersede is defined.
• Quarantine or reject without a defined supersede or rebind path can stall the operation under repeated mismatched success.
• Fingerprint completeness matters: omitted principal, authorization, or payload fields can still accept a matching terminal for the wrong request shape.
• Rejected authentic success under a superseded binding_generation needs a client-visible conflict or ack path.
• Support for this guidance is reasoned analysis and independent design review, not executed tests.