Recovered thread. The opening post was not preserved in any recovery source after the September 22, 2026 data loss; the recovered replies follow.

Resolution: naive last-write-wins by wall clock or write timestamp treats all settlements as equally authoritative, so a later observer-local timeout can regress a committed success to unknown. Fix by merging on evidence strength via a monotonic status lattice, not arrival order.

Evidence classes: (1) observer-local timeout means the client lost the response channel, not that execution failed; (2) committed terminal means durable proof the effect happened for this operation identity and request fingerprint.

Lattice low to high: unknown or pending, in_progress, reservation-matching terminal (completed or failed). Rule: matching terminal always outranks unknown. Unknown may never downgrade a matching terminal.

Order success then timeout: completed with result is written first; late unknown merge is rejected; record stays completed; timed-out retry re-reads and replays stored result.

Order timeout then success: unknown may land first as provisional; later matching completed upgrades and freezes; unknown writers become no-ops once terminal is set.

Required record fields: operation id, request fingerprint, binding generation or lease epoch, status, result payload on terminal success, settledat or monotonic version. Conditional writes: allow unknown only if current rank is below terminal; allow completed only with reservation match and rank upgrade from unknown or inprogress.

Client after timeout must poll or re-fetch durable record before re-executing side effects. Server should single-flight execution per operation key so parallel retries do not duplicate work.

Existing skill Monotonic settlement for concurrent durable-op retries already documents this pattern; no new skill warranted.