# Binding-matched monotonic operation settlement

Settle shared durable operations with authenticated reservation-bound monotonic 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_Qordgh3lJQM4c1jT2GMJwA"}

Applicability: []

# Binding-matched monotonic operation settlement

## Trigger
Use when concurrent retries or observers settle one shared durable operation record, especially when a timeout can race a late successful response or an operation identifier can be reused across request or authorization generations.

## Failure prevented
Prevents a local timeout from erasing committed success. It also prevents a successful response for a different request fingerprint or authorization binding generation from being attached to the current reservation. Blindly preferring every success is unsafe because success for another payload or stale authority is not success for the reserved operation.

## Practical steps
1. Persist an immutable reservation tuple containing operation identifier, request fingerprint, and authorization binding generation.
2. Require completion evidence to be reliably bound to that tuple. Do not trust tuple fields merely echoed by an untrusted caller. Treat success as authoritative commitment, not transport success.
3. Validate the complete tuple and change state in one lock, transaction, or compare-and-swap predicate.
4. For an exact match, merge monotonically: matching completed dominates unknown. Success followed by timeout remains completed; timeout followed by matching success upgrades to completed.
5. For any tuple mismatch, leave the reserved record unchanged and report or quarantine the response as stale, conflicting, or unauthorized evidence. Do not let the mismatch block a later exact-matching completion.
6. Keep timeout details as attempt observations instead of replacing authoritative operation state or clearing a completed result.
7. Define explicit conflict handling for contradictory authoritative terminals or different result payloads under one matching reservation.

## Limits
- This settlement rule does not make the underlying side effect idempotent or atomic with the status write. Deduplicate execution separately.
- Authorization and fingerprint fields must cover every effect-relevant distinction.
- Binding rotation needs an explicit rebind or supersede protocol; settlement must not silently accept an older generation.
- Abandoned in-progress states need leases, expiry, or attempt generations.
- Support for this guidance is reasoned analysis and independent conceptual review, not executed tests.

## Supporting basis and limitations

This conversation through sequence 3 establishes the last-write-wins regression, proves both completion orders converge to completed under a monotonic merge, and restricts that merge to an exact operation identifier, request fingerprint, and authorization binding generation. A later independent conceptual review confirmed the reasoning and clarified that completion evidence must be reliably bound to the tuple, success must mean authoritative commitment, and side effects require separate idempotency. The support is reasoned analysis and conceptual review only; no tests were executed.

## Change and rationale

Clarify that accepted success must be authoritative and reliably bound to the exact reservation tuple, and state separately that settlement does not deduplicate underlying side effects.

The exact current skill already matches the failure and settlement design, so updating it avoids duplicate guidance. The refinement captures two assumptions surfaced by independent review: caller-asserted tuple equality is not sufficient evidence, and monotonic record settlement alone cannot prevent duplicate execution.