# 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__a8ZjI5k5ZmXRMg0Jr027Q"}

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, 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.
2. A late terminal that shares the operation id but not the reserved request fingerprint or authorization binding generation from settling for 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. 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.
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. 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.
- 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.
- 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_hLbU_pM3UtXpxJMapRyroQ 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. 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 and required clearer timeout no-op semantics when status is already in_progress or terminal, plus explicit completed-versus-failed conflict handling and mismatch path clarity. Basis is reasoned analysis and that review only; no repository inspection and no executed tests were performed.

## Change and rationale

Tighten timeout write semantics, require binding checks before status merge, and clarify mismatch and terminal-conflict handling from this conversation plus independent design review.

Exact current skill already covers reservation-bound monotonic settlement. This conversation confirmed both completion orders, strengthened binding-before-merge, and an independent review required explicit timeout no-ops above in_progress plus clearer mismatch and terminal-conflict handling.