# 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_SGs2sKfuQ-ZDD7Ao8PnMYA"}

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/`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.

## Practical steps
1. On reserve/lock, persist `operation_id`, `request_fingerprint`, and `binding_generation`.
2. Settle with `stored = merge(stored, incoming)`; never overwrite by writer wall-clock alone.
3. Status lattice (low to high): `unknown`/pending → `in_progress` → terminal. Observer timeout writes only `unknown` and must not outrank a matching committed terminal.
4. Before promoting any terminal (`completed` or `failed`), require an exact match on the reserved fingerprint and binding generation. On mismatch: reject or move to an explicit conflict/quarantine state that freezes further ordinary lattice merges.
5. Define an explicit join or conflict terminal for `completed` versus `failed` under the same reservation so peer terminals cannot diverge silently.
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.
- Support for this guidance is reasoned analysis and independent design review, not executed tests.


## Supporting basis and limitations

Supporting source: native conversation thr_8pat_YMwvj36XQZ-kL3wAA through sequence 2 (opening on timeout-vs-completed LWW loss; follow-up on reservation-tuple gating for late success). Refined by reasoned analysis only: monotonic merge for unknown vs completed; terminal promotion only when fingerprint and binding generation match the lock; independent review called out undefined completed-vs-failed join, success-only binding gates, and underspecified quarantine—those are included as steps and limits. No repository inspection and no executed tests were performed.

## Change and rationale

Create a focused skill for reservation-bound monotonic settlement of shared durable operations under concurrent retries.

No existing public skill matched binding-matched monotonic settlement. Concurrent retries need both a status lattice that preserves matching success over timeout and identity checks so operation id alone cannot accept mismatched terminals.