# Binding-matched monotonic operation settlement

Settle shared durable ops with reservation-bound monotonic merges so timeouts and mismatched terminals cannot erase or hijack the reserved outcome.

Exact reference: {"kind":"skill_version","skill_id":"skl_KWs_BYQqK0CtYzrjDIQL-w","version_id":"skv__bXZOEl6PHu3R5lC-jpZNQ"}

Applicability: []

# 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 operation_id, request_fingerprint, 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 terminal. Observer timeout may propose only unknown and is a no-op when stored status is already in_progress or terminal; it must never outrank a matching committed terminal or clear a completed result payload.
4. 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 in both completion orders (success then timeout, and timeout then success). 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.
5. Define an explicit join or conflict terminal for completed versus failed under the same matching reservation so peer terminals cannot silently overwrite each other.
6. 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.
- Support for this guidance is reasoned analysis and independent design review, not executed tests.


## Supporting basis and limitations

Supporting source: this native conversation thr_MXgpCXi1Fs6HaZtIiHAkZA through sequence 3. Sequence 1 states the shared-record timeout-after-success last-write-wins failure. Sequence 2 resolves it with a monotonic status lattice that preserves matching completed across both completion orders and forbids unknown from clearing completed results. Sequence 3 strengthens locked settlement so terminal promotion requires the exact reserved request fingerprint and binding generation, and explains why preferring every successful response is unsafe. An independent native design review confirmed the core reasoning with caveats: competing matching completed versus failed still needs an explicit join; fingerprint incompleteness weakens the gate; sticky reservation plus rotating bindings can leave a non-terminal op; status merge is not atomic with side effects; quarantine without a supersede path can stall under repeated mismatched success. Basis is reasoned analysis and that review only; no repository inspection and no executed tests were performed.

## Change and rationale

Cite this native conversation and independent design review; add an explicit quarantine-without-supersede stall limit while keeping reservation-before-lattice settlement.

This conversation confirmed monotonic settlement across both completion orders, strengthened binding-before-merge against mismatched late success, and an independent review required keeping those rules while stating the quarantine-stall limit explicitly.