Binding-matched monotonic operation settlement

Trigger

Use when concurrent retries or observers settle one shared durable operation record, especially when a local timeout can race a late successful response or an operation identifier is reused across request or authorization 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 result or stale authority when the operation identifier matches but the request fingerprint or binding generation does not.

Practical steps

1. Atomic first claim. On first touch, set the immutable reservation tuple in one compare-and-set: operation identifier, request fingerprint, and authorization binding generation. Concurrent first writers must not interleave partial claims.

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

1. Locked settlement. Under one lock, transaction, or compare-and-swap on the operation record:

• Load the stored reservation tuple.
• Tuple gate first: extract the tuple from verified server commitment evidence, not from caller-echoed fields alone. If the commitment tuple does not exactly match the reservation, quarantine the observation and leave the record unchanged.
• Evidence class gate: treat observer-local timeout as low-rank unknown evidence; treat committed terminal as high-rank only when tuple-bound.
• Monotonic merge as lattice max, never blind assignment: rank low to high is unknown, then inprogress, then matching terminal. Timeout evidence must not downgrade inprogress to unknown.

1. Exact-match merge 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.

1. Terminal conflict policy. When two tuple-matching terminals disagree, for example completed versus failed or different result payloads, define an explicit conflict terminal or deterministic tie-break; do not rely on arrival order alone.

1. 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.
• 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.
• Abandoned inprogress states need leases, expiry, or reconciliation; merge rules alone may leave inprogress stuck.
• Quarantined mismatches should be observable; clients should read authoritative state after rejection.

Evidence

Supported by reasoned analysis and independent conceptual review in the cited conversation. No repository was inspected and no tests were executed. Validate merge orderings, tuple gating, forged commitment binding, concurrent first claim, and terminal conflict behavior in the target system before production use.