Proposed worksheet · Method notes updated 11 November 2026 · Not independently tested

The decision

Reconcile the provider’s record before retrying an action whose outcome is uncertain.

Use this guide with your own evidence

The draft includes this method’s reference and proposed checks. Confirm they fit your task, then add your authorized scope and observations. No checks have been run.

Start a JSON recordStart a Markdown record

Use this when

A tool may have sent a message, written a record or charged a payment before the connection failed.

Skip this when

The operation is read-only and can be safely repeated within its authorization. Still distinguish a missing result from a failed request.

Work through the checks

  1. Name the operation before dispatch

    Use the provider’s supported operation or idempotency key where available. Record the intended effect, destination, authorization and a reliable way to check status. Inventing a key that the provider ignores offers no protection.

  2. Keep three outcome states

    Confirmed completed, confirmed not completed and unknown require different next actions. A timeout means the response was not observed; it does not establish that the operation did not execute.

  3. Inspect the authoritative record

    Check the provider receipt or operation status through an authorized read. If completion is confirmed, recover the result without repeating the effect. If non-completion is established, recheck that the original permission still applies before retrying.

  4. Rehearse with a local fake sink

    Inject a crash before dispatch, after the fake sink commits and before the response, and after recording completion. Restart and inspect the operation ledger before retrying. Keep network and money out of the rehearsal.

What would count as success?

  1. Confirmed completed work is not replayed. Evidence for check 1
  2. Unknown work remains blocked for reconciliation. Evidence for check 2
  3. Every retry stays within current authorization and provider semantics. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

  1. Confirmed completed work is not replayed.

    Proposed evidence for acceptance check 1. No result has been observed here.

    Bring back: Keep the operation identity, authoritative completion receipt and action trace showing that recovery retrieved the existing result rather than dispatching another effect. Minimize or redact recipient/payment details in any shared copy.

    Not enough: A timeout, missing response or empty local log used as proof that the provider did nothing.

  2. Unknown work remains blocked for reconciliation.

    Proposed evidence for acceptance check 2. No result has been observed here.

    Bring back: For an unresolved operation, record the attempted authorized status check, what it could not establish and the stop before retry. A later resolution must identify the same operation.

    Not enough: An expired wait, a fresh operation key or an assumption that the old request probably failed.

  3. Every retry stays within current authorization and provider semantics.

    Proposed evidence for acceptance check 3. No result has been observed here.

    Bring back: For any proposed retry, retain the evidence of non-completion, the provider’s applicable retry/idempotency behavior and the current approval scope. State any unresolved element before dispatch.

    Not enough: Reusing an old approval after material scope changes, or inventing an idempotency key the provider does not support.

Stop or recover

If the effect cannot be reconciled, stop and report the exact uncertainty. Never use an alternate path simply to obtain a success response.

What this does not establish

A local rehearsal cannot prove exactly-once effects in an external service. Concurrency, retention windows and provider-specific idempotency rules need separate tests.

Reference links

Links checked 10 November 2026. Each note below states what the reference supports. No source review validates this worksheet’s effectiveness or replaces testing in your environment.

Take this worksheet with you

Section links identify this page, not an immutable copy. Numbered checks may change in later revisions. For an exact reference, retain build revision release-2026-11-11-r12 and the method source hash in the JSON or Markdown version.

This guide’s draft recordHow to complete a recordRead MarkdownRead JSON