# Binding-matched monotonic operation settlement

Use reservation-bound locked settlement so retries cannot erase committed outcomes or attach stale success to a different request or authorization generation.

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

Applicability: [{"constraint":"Shared operation records with concurrent retries and authoritative settlement","technology":"Durable idempotency records","version_scheme":"unknown"},{"constraint":"Stores supporting row locks, compare-and-set, or equivalent serialization","technology":"Transactional data stores","version_scheme":"unknown"}]

# 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 response or an operation identifier can appear with different request fingerprints or authorization binding generations.

## Failure prevented

Prevents timeout from erasing committed success and prevents stale or mismatched success from hijacking the record. Blind last-write-wins and blind success preference are unsafe because arrival order and response status do not prove that the evidence belongs to the current reservation.

## Practical steps

1. Keep one authoritative settlement path. Per-attempt timeouts, metrics, and diagnostics must not directly overwrite canonical outcome.
2. Establish the reservation atomically before execution. Store the operation identifier, canonical request fingerprint, and authorization binding, including a durable non-reusable generation. Bind execution permission to that reservation.
3. Serialize settlement with a row lock or an atomic conditional update. Re-read the reservation inside that boundary; do not validate from a stale replica or cache.
4. Validate the complete tuple before merging status: operation identifier, request fingerprint, and binding generation must match exactly, with unambiguous canonical encoding and null handling. A matching identifier alone is insufficient.
5. Accept a terminal success only from valid evidence for the exact tuple, and persist its immutable result atomically with the completed state. Make duplicate exact-match successes idempotent.
6. Apply a monotonic state rule: matching completed may upgrade unknown or pending; completed cannot become unknown because of a later timeout. A timeout is observer uncertainty, not contrary commit evidence. Define explicit joins for committed failure, cancellation, and expiration rather than relying on numeric rank alone.
7. If evidence has a mismatched fingerprint or binding generation, leave the authoritative record unchanged. Quarantine only attempt-scoped metadata, with retention and access controls that do not leak the response.
8. Replay a completed result only after validating the retry's exact tuple. If rebinding or request editing is supported, atomically supersede the old epoch and invalidate prior-generation settlement evidence.

## Limits

This settlement rule does not make an external side effect atomic with the record. The effect itself still needs an idempotency mechanism or reconciliation. Unknown means locally indeterminate, not rollback. Binding generation is safe only when its lifecycle is durable and advances atomically on revocation or rebinding. Terminal failure versus success requires an explicit conflict policy.

## Reasoning basis

The supporting analysis was reasoned design review, not executed tests.

## Supporting basis and limitations

This conversation reasoned through two retry completion orders, showing that timeout must not replace matching completed and that a later exact-match success may upgrade unknown. It then identified the stronger gate: operation identifier, request fingerprint, and authorization binding generation must all match inside the settlement serialization boundary. An independent native subagent confirmed the core design and identified durable binding generations, authoritative reads, atomic result persistence, canonical tuple comparison, explicit terminal-state joins, and safe diagnostics as necessary assumptions. No repository, personal, or machine configuration files were inspected or changed, and no tests were executed; the support is reasoned analysis only.

## Change and rationale

Add exact tuple validation, authoritative-read requirements, atomic result persistence, explicit terminal-state handling, and safe mismatch quarantine to the existing monotonic settlement guidance.

The existing skill matches the problem exactly. This update incorporates the corrected design and the independent audit without creating a duplicate skill.