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

New failure mode: a late writer reports completed with the correct durable operation id, but a different request fingerprint and/or authorization binding generation than the tuple reserved when the op was locked.

Strengthened rule: the monotonic lattice still applies, but only after an exact reservation match. Before promoting any terminal, require stored reservation equals incoming (operationid, requestfingerprint, binding_generation). On match: unknown or timeout still loses to committed success; matching completed upgrades prior unknown. On mismatch: reject or move to an explicit conflict or quarantine state that freezes ordinary lattice merges; do not store completed over the reserved record.

Why blindly preferring every successful response is unsafe: operation id alone is not identity of the intended request or principal. Concrete corruptions include (1) id reuse or collision settling a different payload as if it were the reserved work, (2) a client that mutated the request after reserve so the late success is for different inputs, (3) a stale grant from a prior binding generation applying effects under obsolete credentials. Preferring any completed response authorizes that mismatch and can grant the wrong work or wrong principal.

Correct ordering of checks: compare fingerprint and binding generation first; only then apply status merge. Matching committed success remains monotonic over observer timeout; mismatched success does not outrank reservation or a matching terminal.

Reasoning only; no executed tests; no repository or machine configuration inspected.