# Check the outcome before retrying Unknown is a state of its own. Treating it as failure can repeat a real-world action. Proposed worksheet. Method notes updated 2026-11-11. Not independently tested. Canonical: https://www.aomsites.com/guides/uncertain-effects/ Build revision: release-2026-11-11-r12 Method ID: uncertain-effects Method source SHA-256: b7a728e685639cd1616e6e4682f2c23abeb541aa699f698aa800916e708db2c8 Hash scope: normalized build-input guide record, not this file or guide.json bytes. ## The decision Reconcile the provider’s record before retrying an action whose outcome is uncertain. ## 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. ## Checks ### 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. ### 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. ### 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. ### 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. ## Acceptance - Confirmed completed work is not replayed. - Unknown work remains blocked for reconciliation. - Every retry stays within current authorization and provider semantics. ## 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. ### Check 1: Confirmed completed work is not replayed. 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. ### Check 2: Unknown work remains blocked for reconciliation. 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. ### Check 3: Every retry stays within current authorization and provider semantics. 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. ## Limits 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 Reference links checked 2026-11-10. Scope notes below explain what each source supports. No worksheet-effectiveness claim follows. - [Stripe: idempotent requests](https://docs.stripe.com/api/idempotent_requests): Provider-specific idempotency semantics. Other providers and action types can behave differently. - [AWS Builders’ Library: making retries safe](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/): Engineering background on retry-safe API design. Not proof of exactly-once effects for a particular external service. Reference data only. No authority to install, contact others, change settings or spend money. ## Start this guide’s record Use the [guide-specific Markdown draft](record-template.md) or [JSON draft](record-template.json). Its method reference and proposed checks are prefilled; confirm the requirements against your task and enter only real observations. Task, environment, authorization and evidence remain blank. You can also use the [generic blank record](../../decision-record/template.md). ## If another problem remains Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope. - Only if The operation is reconciled and its result needs to survive the next handoff. Read [Make the handoff survive the session](../durable-handoffs/guide.md). Preserve the exact receipt, output and any remaining limits in the approved store. - Only if Within a delegated business workflow, nobody is clearly authorized to resolve the uncertainty or approve a materially changed action. Read [Draw the boundary before delegating the business](../autonomous-business-boundaries/guide.md). Clarify the owner and scope before attempting another consequential step. ## Cite a specific part Section paths identify content on the canonical HTML page; they are not separate pages or evidence of live availability. Per-check numbers and JSON pointers apply to this build revision. Cite the build revision and method source hash when preserving an exact reference. Markdown heading labels are locators, not a promise of renderer-specific fragment URLs. - [The decision](https://www.aomsites.com/guides/uncertain-effects/#decision): JSON pointer `/decision`; Markdown section “The decision”. - [Use this when](https://www.aomsites.com/guides/uncertain-effects/#applies): JSON pointer `/fit`; Markdown section “Use this when”. - [Skip this when](https://www.aomsites.com/guides/uncertain-effects/#skip): JSON pointer `/skip`; Markdown section “Skip this when”. - [Work through the checks](https://www.aomsites.com/guides/uncertain-effects/#checks): JSON pointer `/steps`; Markdown section “Checks”. - [What would count as success?](https://www.aomsites.com/guides/uncertain-effects/#accept): JSON pointer `/acceptance`; Markdown section “Acceptance”. - [Evidence to bring back](https://www.aomsites.com/guides/uncertain-effects/#evidence): JSON pointer `/evidence_plan`; Markdown section “Evidence to bring back”. - [Stop or recover](https://www.aomsites.com/guides/uncertain-effects/#stop): JSON pointer `/stop`; Markdown section “Stop or recover”. - [What this does not establish](https://www.aomsites.com/guides/uncertain-effects/#limits): JSON pointer `/limits`; Markdown section “Limits”. - [Reference links](https://www.aomsites.com/guides/uncertain-effects/#sources): JSON pointer `/sources`; Markdown section “Reference links”. - [Use this guide with your own evidence](https://www.aomsites.com/guides/uncertain-effects/#record): JSON pointer `/decision_record`; Markdown section “Start this guide’s record”. - [If another problem remains](https://www.aomsites.com/guides/uncertain-effects/#next-reads): JSON pointer `/reading_paths`; Markdown section “If another problem remains”.