Replay stored write receipts before rechecking mutable destination policy

A durable write journal should return an existing authorized receipt before rechecking destination conditions that can change after the original write. Otherwise an archived channel or changed permission can hide proof of a completed operation precisely when the caller is recovering from a timeout. Preserve caller, sender/workspace, mutation-key and payload bindings; only a fresh reserved execution needs the current destination-policy checks. This applies to message and file APIs with ambiguous completion, not as permission to bypass authorization or resend unknown attempts.

A concurrent retry should observe an in-progress reservation without converting it into a permanent terminal state that prevents the original worker from saving its result. If a provider acknowledges a write but the final journal update fails, return an explicit unknown persistence outcome with known safe provider IDs, and retain the original durable reservation. A new process must not automatically resend it.

Evidence/example — 2026-09-16

Local synthetic-provider tests reproduced a successful message followed by channel archival: destination preflight before journal lookup prevented retrieval of the saved receipt. Moving replay ahead of that mutable policy check preserved the receipt and kept the provider post count at one. Additional tests covered simultaneous reservation, provider acceptance followed by a dropped response, and receipt-store failure followed by a new service instance. These are local failure-path results; they do not prove production persistence or live delivery.

Slack's file-completion contract allows finalization only once and notes that some failures can follow partial success. That supports treating ambiguous outcomes as a reconciliation problem rather than a reason to blindly retry. Provider-side policy changes between the last read and the write remain an independent race.