Opening
Publishing Recovery creates a safe path after failure. Retry Governance decides whether another attempt belongs on that path and what kind of attempt it should be.
The distinction matters because retry is often treated as a button rather than a decision. A request fails, a deadline approaches, and the operation sends the same payload again. Nothing in that repetition proves the failed condition changed. Nothing proves the first attempt did not publish late. Nothing limits how many more requests can follow.
A governed retry starts from evidence. It preserves the original attempt, identifies what is known, tests whether repetition would be idempotent, and selects a response suited to the condition. Sometimes that response is a replay. Sometimes the payload must be rebuilt, the destination version regenerated, or execution stopped. When the evidence cannot support a safe choice, escalation is the correct action.
Unchanged repetition multiplies risk
A repeated request inherits every unresolved assumption in the first one. If the asset violated a platform requirement, the same asset still violates it. If the destination identity was wrong, repetition targets the same wrong identity. If the outcome is uncertain, the first request may still become public while the second is being sent.
The risk is not limited to duplicate posts. Repetition can consume an approved attempt limit, create conflicting provider records, detach a later outcome from its cause, or make operators unsure which event produced the public result. The system may eventually show one correct post while its internal history becomes unreliable.
Idempotency is one protection. In practical terms, the same intended operation should not create an additional effect when it is safely repeated. That protection might rely on a stable operation identity, a destination-supported idempotency mechanism, or a verified public-state check before execution. The exact implementation varies, so the governance rule is broader: never assume duplicate safety. Demonstrate it for the specific attempt and destination.
Evidence selects the next action
A retry decision branches only after the prior attempt, duplicate risk, changed condition, and action limit are visible. Every branch returns to one observable history.
What Retry Governance means
Retry Governance is the operating discipline for deciding whether and how another publishing attempt may occur. It turns a tempting repeat action into a bounded choice supported by evidence, ownership, duplicate protection, and a visible record.
The decision has five possible operational responses. Replay reuses the same valid payload after a temporary, understood condition changes. Rebuild repairs the structure of the request, asset package, identity mapping, or execution input. Regenerate creates a newly governed destination version when the content itself must change. Stop closes the retry boundary because the objective is no longer valid, the limit is reached, or risk exceeds value. Escalate transfers the evidence and decision when the operator lacks certainty or authority.
Regeneration carries a special editorial boundary. A new version must still preserve the approved meaning, intent, factual integrity, strategic purpose, and voice established earlier in the series. Retry pressure does not authorize an unreviewed rewrite. If the required change crosses the existing approval boundary, the attempt pauses until the new version receives the appropriate review.
These are not interchangeable labels for “try again.” Each choice describes what changed and why a new event is justified. Governance also defines how many attempts are allowed, who can authorize another one, which interval or dependency must pass, and what evidence must be observed afterward. It does not promise that every retry will succeed.
The Retry Governance Framework
The Retry Governance Framework uses six stages. Each produces evidence for the next, preventing urgency from silently becoming permission.
Preserve the operation identity, payload version, destination, timestamps, provider evidence, confirmation result, known cause, and remaining uncertainty. No retry decision begins from an erased or summarized failure.
Check ownership, authorization, attempt limit, timing or dependency conditions, and idempotency. Verify that another event cannot create an unseen duplicate or exceed the approved operational boundary.
Select replay, rebuild, regenerate, stop, or escalate. State the evidence for the choice and the condition that changed. If no option is defensible, escalation or stopping is the governed result.
Create a distinct attempt identity linked to the original. Reuse only validated inputs, preserve approvals for unchanged material, obtain review for changed content, and authorize exactly one bounded execution.
Run the selected action once, then inspect provider and public evidence. Do not interpret request acceptance as publication, and do not launch another retry while this attempt remains unresolved.
Append the action, evidence, outcome, attempt count, owner, and next boundary to visible history. Close, stop, escalate, or begin a new governed cycle without overwriting any earlier event.
The framework can end without another execution. Stop and escalate are successful governance outcomes when they prevent an unjustified request. When execution does occur, the framework succeeds by making the decision bounded, duplicate-aware, and traceable—not by manufacturing a success state.
Worked example: choosing among three different responses
A campaign has one approved source message and three destination-ready versions. The email version sends successfully. A professional-network request returns a definite temporary service error before an external publication identifier is created. A short-form destination rejects its version because the media dimensions are invalid. A third destination times out after accepting the request, leaving the public outcome uncertain.
Replay the known temporary failure
For the professional network, the operator preserves the failed attempt and confirms three facts: the payload remains valid, the service error was temporary, and no publication identifier or public post exists. The execution route supports a stable operation identity, so the owner authorizes one replay after the dependency returns to normal. The replay receives a new event record linked to the same intended operation. If the service fails again, the attempt limit closes and the case escalates instead of looping.
Rebuild the invalid request
The short-form destination needs a rebuild, not a replay. The meaning and approved copy remain unchanged, but the media package does not satisfy the destination requirement. The team creates a corrected asset package, validates its dimensions, retains the destination version reference, and records why the request structure changed. One new attempt is authorized. Calling this a replay would hide the fact that the input was materially repaired.
Escalate the uncertain outcome
The timed-out request cannot safely be replayed. Provider acceptance means the first event may still produce a public post, and the team lacks evidence that repetition is idempotent. The operator stops execution and transfers the attempt identity, response, expected route, timestamps, and public checks to the accountable owner. Article #9 will develop how uncertain outcomes are reconciled. Here, Retry Governance establishes the boundary: no further attempt is eligible while the first outcome remains unresolved.
The visible history now shows three different decisions from one campaign: replay after a known temporary failure, rebuild after a validated input defect, and escalate when duplicate safety cannot be demonstrated. The team does not use one generic retry rule because the evidence is not generic.
Boundaries that keep retries governed
Replay only when the payload remains valid. A changed asset, identity, or request structure is a rebuild or regeneration. Accurate labels keep approval and causality visible.
Do not infer idempotency. A familiar endpoint, identical payload, or missing public post is not enough by itself. Use an evidenced duplicate-prevention mechanism or keep the retry boundary closed.
Do not let attempt limits reset silently. Rebuilds and regenerated versions remain part of the same recovery history. A new identifier must not erase the cumulative count or previous outcomes.
Do not overwrite an attempt. Append decisions and events. Visible history is what lets operators understand whether a condition actually changed.
Do not resolve uncertainty inside retry policy. Retry Governance stops or escalates when an outcome is ambiguous. Article #9 owns the deeper Publishing Reconciliation method for establishing what happened.
Operational checklist
Answer Yes or No before authorizing another publishing attempt.
- Yes / No — Is the prior attempt intact? Its identity, payload version, state, evidence, timestamps, and unresolved facts remain visible.
- Yes / No — Has the condition changed? The record explains why replay, rebuild, or regeneration is more than unchanged repetition.
- Yes / No — Is duplicate risk controlled? Idempotency or an equivalent evidence-based prevention check is specific to this operation.
- Yes / No — Is the action bounded? Owner, authorization, timing, attempt count, limit, and stop condition are explicit.
- Yes / No — Is uncertainty blocking execution? An unresolved outcome moves to stopping or escalation rather than another request.
- Yes / No — Will observation update visible history? The selected action and resulting evidence will be appended without rewriting earlier events.
Key takeaways
- Retry is a decision, not a button. Evidence must justify another action.
- Replay, rebuild, and regenerate mean different changes. Accurate selection protects approval and causality.
- Stopping and escalation are valid outcomes. Governance can succeed without another request.
- Idempotency and duplicate prevention must be demonstrated. They cannot be assumed from identical inputs.
- Attempts need explicit limits. Ownership, authorization, timing, count, and stop conditions bound execution.
- History stays visible. Every choice, event, and observation is appended so later decisions can use truthful evidence.