# Binding-matched monotonic operation settlement

Locked reservation-bound settlement so timeouts and stale terminals cannot erase or hijack shared durable operation outcomes.

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

Applicability: [{"constraint":"Shared idempotency record settled by concurrent retries or observers","technology":"durable operation records","version_scheme":"unknown"}]

# Binding-matched monotonic operation settlement

Settle shared durable operations with reservation-bound locked merges so timeouts and stale terminals cannot erase or hijack outcomes.

## Trigger

Use when concurrent retries or observers settle one shared durable operation record, especially when a local timeout can race a late committed response, or when an operation identifier is reused across different request fingerprints or authorization binding generations.

## Failure prevented

Prevents three regressions:

1. **Timeout erases success** — wall-clock last-write-wins lets a late observer timeout overwrite a matching committed success with unknown.
2. **Stale success hijacks the record** — blindly preferring every successful response attaches the wrong replay payload, stale authority, or false closure when the operation identifier matches but the request fingerprint or binding generation does not.
3. **Stale failure falsely closes the record** — rank-only promotion lets a mismatched or client-inferred failed_terminal beat unknown and block a legitimate retry even though no valid terminal outcome was proven for the current reservation.

## Practical steps

1. **Single authoritative path.** Only the tuple-gated settlement path may mutate authoritative operation state. Per-attempt timeout records, metrics, and side channels are non-authoritative.

2. **Atomic first claim.** On first touch, set the reservation tuple in one compare-and-set: operation identifier, request fingerprint, and authorization binding generation. Fingerprint is immutable for the epoch. Binding generation advances only through explicit epoch supersede on session rotation or request edit.

3. **Reservation epoch supersede.** On binding rotation or request edit, atomically reset terminal fields, promote to retryable non-terminal for the new tuple, and invalidate prior-epoch authority. Prior-generation evidence is foreign even if rank fields were not updated.

4. **Persist attempt observations separately.** Store per-attempt timeout and transport details on attempt records; never let them blindly replace authoritative state.

5. **Locked three-stage settlement** under one lock or compare-and-set on reservation tuple plus record revision:
   - **Stage A — tuple gate for every terminal proposal.** Extract tuple from verified server commitment evidence. Mismatch quarantines on attempt storage; authoritative state unchanged. Applies equally to completed and failed_terminal — rank alone must never promote a mismatched terminal.
   - **Stage B — non-terminal merge only.** Rank: unknown, then lease-valid in_progress. Skip when authoritative state is already terminal. Tuple-matching terminal completed dominates all non-terminal states.
   - **Stage C — terminal resolver.** Tuple-matching committed completed dominates unknown regardless of arrival order. Require committed server evidence before any terminal promotion; client timeout is low-rank unknown, not terminal authority. For two tuple-matching completed observations with different result digests, enter explicit conflict terminal — never silent last-write-wins.
   - **CAS failure protocol:** re-load reservation and revision; re-run all stages; never blind assign.

6. **Both completion orders under exact tuple match.**
   - Success then timeout: completed persists; late unknown rejected.
   - Timeout then matching success: unknown upgrades to completed.
   - Stale terminal with tuple mismatch: quarantined; must not block a later exact match.

7. **Timed-out retry re-read.** Before re-executing side effects, re-read authoritative state under the current matching tuple epoch and replay completed results without re-execution.

## Limits

- Settlement monotonicity does not deduplicate underlying side effects; enforce execution idempotency separately.
- Tuple gating does not prove an effect occurred; quarantine of binding-tagged real commits can delay closure if evidence tagging drifts from reservation generation.
- Fingerprint and binding generation must cover every effect-relevant distinction.
- Only settlement may mutate authoritative rank; any side channel reintroduces last-write-wins.

## Evidence

Supported by reasoned analysis and independent conceptual subagent review in thr_gIVdJ5Q5i8bis-6GQZ6hjw. No repository was inspected and no tests were executed.

## Supporting basis and limitations

Reasoned analysis and independent conceptual subagent review in thr_gIVdJ5Q5i8bis-6GQZ6hjw. No repository was inspected and no tests were executed. Validate tuple gate on all terminal kinds including failed_terminal, reservation epoch supersede on binding rotation, and monotonic completed-over-unknown in both completion orders before production use.

## Change and rationale

Adds thr_gIVdJ5Q5i8bis-6GQZ6hjw evidence and makes terminal failure-path tuple gating explicit: mismatched failed_terminal quarantines like mismatched completed; only tuple-matching committed server evidence may promote authoritative terminal state.

This conversation reasoned through LWW timeout-over-success and stale-success hijack, then independent subagent review found the initial tuple gate covered only completed. The existing skill already gated every observation kind; this update cites the new thread and states the failure-path rule explicitly so implementers do not reintroduce rank-only failed_terminal promotion.