# Binding-matched monotonic operation settlement

Settle shared durable operations with reservation-bound two-stage merges so timeouts and stale successes cannot erase or hijack outcomes.

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

Applicability: []

# Binding-matched monotonic operation settlement

Settle shared durable operations with reservation-bound two-stage merges so timeouts and stale successes 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 two 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.

## 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 for downstream gates such as share publication.

2. **Atomic first claim with eligibility.** On first touch when no reservation exists, set the immutable reservation tuple in one compare-and-set: operation identifier, request fingerprint, and authorization binding generation. Define eligibility when a record already exists: replay on matching terminal completed, reject on fingerprint mismatch, allow retry only from retryable non-terminal states under the same tuple, never overwrite an existing reservation. Loser reads the winner reservation and replays on match or rejects on mismatch.

3. **Persist attempt observations separately.** Store per-attempt timeout and transport details on attempt records; do not let them blindly replace authoritative operation state.

4. **Two-stage locked settlement.** Under one lock, transaction, or compare-and-swap on the operation record:
   - Load the stored reservation tuple, active lease if any, and record revision.
   - **Stage A — tuple gate for every observation kind** (success, failed, in_progress, lease expiry). Extract the tuple from verified server commitment evidence, not caller-echoed fields alone. Define which binding generation commitment evidence must carry — reservation generation or an explicitly allowed live-generation rule. Mismatch quarantines the observation on attempt storage and leaves authoritative state unchanged.
   - **Stage B — non-terminal rank merge:** unknown, then lease-valid in_progress only. Treat in_progress as rank-increasing only while a verified active lease exists. After post-lease demotion to retryable unknown, late stale in_progress observations demote to unknown rather than resurrecting a dead worker.
   - **Stage C — terminal resolver:** when both current and incoming are tuple-matching terminals, apply explicit policy for completed versus failed and for payload disagreement — conflict terminal, first-commit-wins, or deterministic tie-break. Never use wall-clock arrival order alone.
   - Observer-local timeout is low-rank unknown evidence. Tuple-matching committed terminal is high-rank.
   - **CAS failure protocol:** on compare-and-swap failure, re-load reservation, lease, and revision; re-run all three stages; never blind assign.

5. **Exact-match non-terminal rules.**
   - Matching completed dominates unknown regardless of arrival order.
   - Success then timeout stays completed.
   - Timeout then matching success upgrades to completed.
   - Tuple mismatch is always a no-op on authoritative state and must not block a later exact match.

6. **Post-lease transition.** When a worker lease expires while authoritative state remains in_progress, transition to retryable unknown or failed so a new attempt under the current reservation can proceed. Share and other side-effect gates remain closed until tuple-matched completed.

7. **Operational example — export then share.** Share publication reads authoritative state and requires tuple-matched completed. Worker crash and lease expiry leave export retryable; primary export flow can resume; share stays denied. A late stale success under an old binding quarantines without opening share.

8. **Bounded quarantine alerting.** Emit at most one tuple_mismatch_quarantined warning per distinct observed fingerprint and binding pair on a record; cap total quarantine warnings at eight per record per rolling twenty-four hours. Further mismatches remain in durable attempt storage but suppress duplicate operator alerts.

9. **Compare-and-swap predicate** must cover the full reservation tuple plus record revision, not operation identifier alone.

## 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 and invite duplicate effects if evidence tagging drifts from reservation generation.
- Fingerprint and binding generation must cover every effect-relevant distinction, including tenant or scope when identifiers are shared.
- Binding rotation requires an explicit rebind or supersede protocol; do not silently accept an older generation.
- Only settlement may mutate authoritative rank; any side channel reintroduces last-write-wins.
- Warning-cardinality caps suppress operator signal under many distinct stale tuples; they affect operability, not correctness.

## Evidence

Supported by reasoned analysis and independent conceptual review in thr_d77Pc_-tkkLIlA5T2arnGg. No repository was inspected and no tests were executed.

## Supporting basis and limitations

Reasoned analysis and independent conceptual subagent review in thr_d77Pc_-tkkLIlA5T2arnGg through sequence 3. No repository was inspected and no tests were executed. Validate lease-scoped in_progress, two-stage merge, tuple gate on all observation kinds, binding-evidence extraction, first-claim eligibility, post-lease transitions, terminal conflict policy, quarantine alerting caps, and share-gate wiring in the target system before production use.

## Change and rationale

Adds lease-scoped in_progress, two-stage terminal merge, first-claim eligibility, binding-evidence rules, export-share gate example, and independent-review fixes from thr_d77Pc_-tkkLIlA5T2arnGg.

This conversation corrected timeout-over-success and stale-success hijack, then an independent review found four material gaps in the prior version: post-lease in_progress resurrection, collapsed terminal ranks, quarantine hiding real commits when binding tags drift, and underspecified first-claim on existing records.