Monotonic settlement for optional publication retries

Trigger

Use this guidance when an optional background path can publish a remote side effect, the primary task must complete independently, and worker crashes, deadlines, or lost acknowledgements can trigger retries.

Failure it prevents

It prevents four related failures: declaring a possibly committed publication denied, duplicating a publication with a fresh retry, allowing a late timeout to erase confirmed success, and turning auxiliary warning floods into a new failure of the primary task.

Practical steps

1. Locate the commit boundary. If a worker only validates or transforms a candidate before any remote write, initialize the parent verdict to deny and authorize publication only after a complete authenticated worker result. A worker crash or deadline then leaves sharing denied.

1. Treat post-send silence as unknown. If the worker may have sent a remote write, a crash or deadline without durable acknowledgement does not prove rollback. Record an unknown observation until authoritative state can be recovered.

1. Reserve one durable operation identity. Bind an idempotency key to the request fingerprint, authorization binding, and generation. Every retry and reconciliation attempt for that logical publication reuses the same reservation.

1. Reconcile before writing again. Query the durable operation record or remote idempotency result. If reconciliation is unavailable, stop new writes and retain unknown rather than inventing a fresh operation identity.

1. Merge outcomes monotonically. A matching committed terminal outranks pending, in-progress, unknown, and observer-timeout states. A late local timeout cannot overwrite confirmed completion. Reject or quarantine terminal evidence whose fingerprint or binding does not match the reservation.

1. Keep the primary path independent. Persist or return the primary result without waiting for auxiliary publication settlement. The publication state may affect observability and later recovery, but it must not become an input to primary-task success.

1. Bound warnings durably. Enforce one warning record per primary task and warning class with a unique constraint or idempotent upsert. Later failures update that record or increment bounded counters; an in-memory counter is not sufficient across crashes or concurrent workers.

Limits

Idempotency prevents duplicate effects only when the remote system participates or the local system owns an atomic visibility gate. A timeout cannot undo a remote commit. Strict proof that sharing stayed denied requires keeping every remote write after a successful pre-publication gate or using a protocol with a definitive abort or commit decision. Monotonic settlement does not by itself resolve contradictory committed terminals; those require an explicit conflict state and operator or protocol-level resolution.

Evidence

This is reasoned analysis refined by an independent reasoning review. No tests were executed, no code was run, and no repository or configuration was inspected.