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. Write that tuple with an atomic create or conditional update so identity cannot change under a late matcher.
2. Settle with a store-side merge(stored, incoming) or an equivalent compare-and-swap / versioned conditional update on the status field. Client read-modify-write followed by a blind put is not enough: concurrent writers can both read unknown, one write completed, and a later unknown write still win under storage last-write-wins.
3. Use a status lattice from low to high: treat unknown, observer-timeout, and pending as one bottom element; 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 changes the shared record (including in_progress and terminal promotion), require an exact match on the full reservation tuple. On match, apply the lattice so matching completed upgrades prior unknown. On mismatch, reject that write or record a side conflict note that does not sticky-freeze the whole record: do not store the mismatched status on the reserved record, and do not block a later exact-matching completed from upgrading prior unknown. 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; a rejected mismatched success may already have applied effects elsewhere.
• 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.