When a Tool Cannot Tell You Whether It Acted

The agent says the ticket request failed. The collection desk may already have issued the ticket. The usual advice is to reconcile with the system of record, but that advice conceals the difficult question: what does a reconciliation answer actually prove? A blank search result, a replayed server error and a signed acceptance message can all be genuine without settling the effect. Recovery becomes defensible only when the next action follows from evidence the recipient's contract makes meaningful.

Define the effect before interpreting the failure

Imagine a collection counter that issues a numbered ticket for a parcel. An AI agent, software that uses a model to select actions and call tools, asks the counter to issue one ticket for parcel Cedar at desk East. The reply never reaches the agent. Nobody is asking it to repeat a calculation: a second ticket would be a second claim on the same collection process. This is a synthetic service used to reason about contracts. Its names, records and message timings illustrate possibilities; they are not incident reports or measurements.

The protected effect is ticket issuance, not successful network delivery, not a completed model turn and not collection of the parcel. That distinction makes a completion claim testable. If the desk issued a ticket but nobody collected the parcel, issuance succeeded while the broader task remains unfinished. If an intermediary accepted a message but the desk issued nothing, transport progressed without the protected effect. Before recovery, write the effect in the recipient's vocabulary. Otherwise two teams can truthfully report success while referring to different milestones.

A recipient is the component that controls that effect. Its contract states which requests it accepts, how it identifies repeated operations, what its responses mean and which facts remain true after failures. A system of record is authoritative for a particular fact, not magically authoritative for every question asked of it. The desk's ticket ledger may establish issuance. A search index built from that ledger may merely help find tickets. Calling both the system of record hides a difference that changes whether an absent result permits another issuance.

Give the intended operation a stable name before submission, and retain its bound arguments: parcel Cedar, desk East, issue one collection ticket. Stable means it identifies the same intended issuance across attempts. An attempt is one submission of that operation; an operation is the business effect those submissions seek. Two attempts can belong to one operation, and two superficially similar requests can be different operations. This distinction is necessary orientation, not the novel contribution here. The question is what guarantees still attach to that identity when recovery begins.

There are three separate things to inspect. First, what is known about whether the effect happened? Second, can a previously submitted attempt still produce that effect later? Third, does the recipient still prevent an additional effect when the original operation is repeated? A receipt may answer the first without describing the third. A retained idempotency record may answer the third while leaving the first unresolved. A negative lookup may answer neither of the first two. Treating these as one successful-or-failed flag discards information needed for a safe decision.

The distinction between acknowledgement levels is established systems knowledge. Saltzer, Reed and Clark's End-to-End Arguments in System Design explains why lower-level communication assurances cannot substitute for the application-level assurance a user needs. RFC 9110, the standard defining HTTP semantics, likewise distinguishes accepted processing from completed processing. HTTP is the request-and-response protocol used by many tools; it does not define the business meaning of Cedar's ticket. The article's own contribution is to turn these boundary distinctions into a comparative recovery method under incomplete tool contracts.

Keep the analysis deliberately narrower than an infrastructure reliability plan. It does not decide where to host the agent, how to persist every workflow transition or how to authorize ticket issuance. Those are important but different questions. Assume the original request was authorized, its identity and arguments are available, and recovery must not create an extra ticket. Even with that orientation settled, deciding what to do next can remain impossible from local evidence. Better logs about the request cannot reveal an external effect that the recipient never made observable.

Two histories, one worker observation

Consider the first history. The agent submitted the Cedar operation, but a network failure prevented the desk from receiving it. The agent's local record shows a submission and then a timeout. No ticket exists. Consider the second history. The desk received the identical operation, issued its ticket and lost the response on the return path. The agent's local record again shows a submission and then a timeout. A ticket does exist. The difference is outside the worker's observation. Neither history requires an attacker, a faulty model or an unauthorized action.

For this comparison, assume the recipient does not recognize repeated operation identities, supplies no reliable outcome lookup and participates in no transaction that couples issuance to the agent's completion record. Also assume recovery obtains no further evidence before choosing. These are explicit limitations of this contract variant, not universal claims about tools. Under these assumptions, submitting the operation anew can create the missing ticket in the first history and an extra ticket in the second. Permanently abandoning the operation avoids the extra ticket but leaves the first history without the intended effect.

The reasoning is an indistinguishable-history argument: different external histories leave the deciding component with the same evidence. A decision rule based solely on that evidence selects the same behavior in both histories, although the action needed to guarantee completion without duplication differs. Randomness does not add an observation; it only changes which risk is selected by chance. No reliability percentage is claimed. The conditional conclusion is that this worker cannot guarantee both eventual issuance and no extra issuance from the evidence and capabilities specified.

A delayed original attempt adds a third possibility. At the moment the worker times out, no ticket exists, but a request remains queued at the desk and can issue a ticket later. Even a perfectly accurate current-state lookup would not distinguish a permanently absent effect from an effect that has not happened yet. This is why safe replacement needs a statement about future execution as well as present absence. The issue is not merely whether the data is stale; it is whether any admitted or delayed copy of the original can still cross the issuance boundary.

A stronger contract changes the result. Recipient-enforced duplicate protection can make repetition safe for the named effect. An authoritative terminal receipt can distinguish histories. A transaction covering issuance and a durable completion record can provide a recoverable answer within its own failure assumptions. The paired histories do not prove that exactly-once effects are universally impossible. They identify what a particular worker lacks. Every claimed recovery guarantee should name the extra recipient capability that rules out the counterexample, rather than invoking exactly once as a property of the whole workflow.

This matters for AI agents because conversational confidence can obscure observational uncertainty. A model may infer that the service probably failed from the absence of a reply and produce a fluent recovery explanation. That explanation is a hypothesis, not evidence from the desk. A larger model can choose more sophisticated actions without acquiring the missing fact. The safest allowed action is therefore not whichever action sounds most resourceful. It is one whose consequences remain acceptable across every history still compatible with the available recipient evidence.

Unresolved is not another name for failed. Failed usually invites correction and resubmission; unresolved says the original may already have acted or may still act. It should preserve the operation's identity and the reason the outcome cannot be determined. That state can still support investigation, customer communication or a separately authorized business decision. It must not be disguised as success, and it must not automatically trigger a new operation. The paired histories explain why truthful incompleteness can be a stronger recovery result than an invented terminal answer.

A receipt proves only the boundary it names

Start with the strongest useful positive evidence: a trustworthy terminal receipt stating that this Cedar operation issued a particular ticket. Terminal means the reported processing outcome is settled for that operation, not merely observed partway through. Trustworthy means the answer comes through the recipient's authorized outcome channel, is correctly correlated and has the documented meaning required by the decision. A cryptographic signature can support authenticity of a statement. It cannot turn a statement about message acceptance into a statement about issuance.

Correlation means connecting the answer to the exact operation under recovery. The parcel name alone may match two legitimate requests; a ticket number alone may identify an object without telling which request created it. For our synthetic contract, the receipt names the operation, its bound parcel and desk, and the issued ticket. Another service might use a request record, an immutable object reference or a provider-supported metadata field. The essential property is not a preferred identifier format. It is that the evidence excludes confusion with a different effect or a different operation.

An acceptance receipt is weaker. RFC 9110 section 15.3.3 defines 202 Accepted as processing accepted but not completed; the request might not ultimately be acted upon. RFC 7240 section 4.1 describes respond-async, a preference for asynchronous handling, not a promise that the requested effect happened. In plain language, the desk has taken your order, not necessarily printed your ticket. An agent receiving acceptance can record admission and follow the documented status mechanism. It cannot complete the ticket-issuance task just because an HTTP response belongs to a success-status class.

A terminal success receipt for the defined effect does not prove every downstream goal. If issuance is confirmed, the agent may durably record issuance and stop reissuing that operation. It may still need to arrange collection under a separate task and contract. Conversely, a service might return completed to mean that its handler ended, even though it handed actual printing to another queue. Ask which boundary completed reaches. This is not semantic pedantry: using handler completion as issuance evidence can cause the agent to promise a ticket the service has not produced.

Positive object evidence can also require interpretation. Seeing a ticket linked to the Cedar operation establishes issuance under the synthetic contract, but a query for all tickets named Cedar is not the same proof. Nor does absence from that query establish nonissuance. A deleted or archived object can leave a historical effect even when its current representation is gone. The right outcome channel may need a durable historical receipt rather than a live resource list. Recovery asks whether the effect happened, which can be a different question from whether its output currently exists.

A status channel itself has a failure contract. Receipts can be unavailable, delivered more than once, reordered or associated with a partial stage. The consumer should interpret each event against the recipient's documented transitions rather than treating arrival order as business order. A late pending event must not erase a trustworthy terminal receipt for the same operation. Where the provider does not define ordering or finality, the agent cannot invent it. A mechanically parsed response still needs a semantic rule explaining why it supports a particular transition.

The practical result is a small but important asymmetry. A properly bound terminal receipt may resolve an unknown outcome positively without permitting any new effect. It can justify repairing the agent's completion record, acknowledging the finished operation and moving on. That recovery is not retrying the business action; it is repairing local knowledge from authoritative remote evidence. Describe those as different actions in the interface. Otherwise a human selecting retry may unknowingly select issuance when only completion-record repair was necessary.

Why not found is not permission to start over

Now change the contract. The desk offers a search page populated from its issuance ledger, but the page can lag behind the ledger. The agent searches for Cedar and finds nothing. That observation is consistent with a request that never arrived, a ticket already issued but not indexed, and a request that has arrived but remains queued. Search availability is useful; it does not establish the negative fact recovery needs. The problem is the inference from absence in a particular representation to absence of the protected effect.

This is a real contract distinction, not an invented objection to lookup. The Amazon EC2 Developer Guide describes eventual consistency: changes made through its API may not immediately appear in subsequent commands. It explicitly says that a not-found response immediately following successful instance creation does not mean the instance does not exist. It also warns that not found after a termination request does not establish that the instance is or will be terminated. These are that service's documented behaviors, used here to challenge a generic inference, not to prescribe its implementation for the ticket desk.

Caching introduces another source of apparent absence. RFC 9111 section 2 permits storage of negative responses such as 404 Not Found. A cache is an intermediary that reuses a previous response rather than obtaining a fresh one each time. Repeatedly receiving the same missing-result response can therefore represent repeated reuse of one observation. Section 4.4's invalidation rules do not establish global cache invalidation after every application change. Repetition of evidence is not independence of evidence, and bypassing a cache still does not by itself eliminate pending execution.

Suppose instead the desk provides a strongly consistent lookup, meaning its reads agree with the ordering of the writes it covers. At this instant the lookup correctly says no ticket was issued for the operation. That improves present-state knowledge, but a delayed original attempt can still arrive after the read and issue one. Strong consistency for ledger reads is not cancellation of the submission path. Safe replacement requires a terminal no-effect answer: no issuance happened for this operation, and every previously submitted attempt is excluded from issuing it in the future.

How could such an answer exist? One synthetic contract closes the operation at the recipient before reporting terminal rejection. Closure includes queued copies and any late copies bearing that identity; the desk persists a rule refusing subsequent issuance for the closed operation. Another implementation could provide a different documented mechanism covering all original attempts. The point is the promised exclusion, not a prescribed tombstone design. A terminal label without that meaning is insufficient, as is an acknowledgement that only one worker stopped while other copies remain eligible.

There is a race in verification itself. Looking up absence and then asking a separate endpoint to create a fresh ticket leaves a period in which the original can issue. Polling faster does not remove that period. Where the recipient supports a conditional replacement that atomically checks the old operation's closure and performs the permitted next operation, its contract may close the gap. Where it does not, two client calls must not be narrated as one atomic decision. This analysis concerns the evidence needed for replacement, not a general introduction to concurrency control.

The agent should therefore record a negative observation with its limitations: where it was obtained, what historical and pending activity it covers, and whether the original can still act. Lack of documentation is not a reason to assume terminality. Waiting and querying can obtain better evidence if the service promises eventual visibility and offers a supported route, but elapsed time alone does not constitute a no-effect guarantee. A business deadline may require escalation. That deadline changes the need for a decision, not the strength of the evidence supporting it.

Duplicate-safe repetition can leave completion unknown

Idempotency means repetition preserves the intended effect beyond the first application; it does not necessarily mean every internal action occurs only once. RFC 9110 section 9.2.2 makes that distinction for HTTP methods. A server can log each request separately while repeated requests retain the same intended effect. For Cedar, the relevant contract is that repeating the same recognized operation does not issue an extra ticket. That is the invariant, a condition the service is required to preserve. It says nothing by itself about whether a particular attempt produced the first ticket.

An idempotency key is a client-chosen identifier the recipient uses to recognize repetitions under a defined scope. Its meaning includes more than the string. Which account or tenant owns it? Which endpoint and arguments are bound to it? How are simultaneous requests handled? How long is the protective record retained? What happens after expiry, and which responses can be replayed? Two services both advertising idempotency can answer these questions differently. Recovery must use the actual answers, not infer an unlimited guarantee from the feature name.

Consider a contract that retains the first response for the Cedar operation. After issuance begins, the handler reports an internal error. It cannot provide a terminal success receipt because it has not established the issuance outcome through its available response path. A protected repeat returns that same error without creating another ticket. Every repetition can be duplicate-safe while every reply remains inconclusive. The agent has improved safety of attempts, not knowledge of completion. Count repeated identical errors as one unresolved outcome with more attempts, not as accumulating proof that the effect failed.

Stripe's advanced error-handling documentation gives a concrete example, explicitly for API v1: a 500 response can be indeterminate and can have side effects; an idempotent POST response may be cached, including that error. During reconciliation the cached response need not change, and reconciliation is not guaranteed to resolve every operation. POST is an HTTP method commonly used to request an action. These are API v1 conditions, not a universal rule for every Stripe interface or every tool. They establish the possibility of duplicate protection without a conclusive replayed outcome.

Concurrent attempts deserve a similarly precise reading. A recipient can refuse a repeat because the original is still executing, without storing a completed result for the refused attempt. That refusal is not proof that the original failed or succeeded. Under a contract allowing it, wait and repeat the same operation with unchanged arguments. Do not bypass the conflict with a fresh identity. A second key can create a second operation even though the first remains pending. Distinguish rejection of this attempt from rejection of the operation, because they justify different recovery actions.

Retention makes safety time-dependent. Stripe's documented API v1 retry guidance uses a bounded window; beyond it an old key is not a safe promise that the original result remains protected. The same string can be treated as a new request after its record is pruned. That does not mean every key is deleted at the window's exact endpoint. It means the client cannot continue relying on retention after the guaranteed interval. A worker that slept through that interval must reconsider its evidence and capabilities, not blindly resume its earlier retry policy.

The engineering question is who can establish that protection still applies to this original operation. A local retry counter cannot prove remote retention. The operation's original acceptance time, provider guarantee and recovery delay may support a conservative bound; some tools may expose an authoritative retained-status query. Where those facts are missing, declare protection unestablished. Do not label it expired as an observed fact unless expiry is actually known. Preserve the difference between a guarantee no longer available to the client and a protection mechanism known to be absent at the recipient.

What stronger recovery contracts actually have to preserve

A stronger recipient can make a useful promise: the protected effect and its completion record survive together. If the ticket is issued, a durable record lets a repeat or lookup recover the outcome. If no ticket was issued, recovery cannot mistake a completion record for an effect that never happened. Durable means the information survives the failures included in the service's contract. Together means the implementation cannot expose an allowed failure state in which one fact survived and the other did not. Storing both eventually is not the same guarantee.

Lee and colleagues' Implementing Linearizability at Large Scale and Low Latency presents RIFL, reusable infrastructure for linearizability. Linearizability means operations appear to take effect in one ordering consistent with their real-time relationships. The paper shows how its infrastructure handles request identity, durable completion records, movement of records and reclamation to support exactly-once execution in the systems it covers. Its completion records and state changes are coupled at the persistence boundary. The contribution is not a slogan about retries; it is machinery with failure and lifecycle assumptions.

Completion records cannot simply accumulate forever, so safe reclamation matters. Reclamation means discarding records no longer needed. RIFL uses client acknowledgements and leases, time-bounded validity of a client's relationship with the service, to constrain when retained results may be removed and which clients may continue requesting work. The relationship between validity and deletion matters: forgetting a completion record while allowing an old retry to execute as new would reopen the extra-effect risk. A provider-specific retry window should therefore be read as part of a whole operation lifecycle, not just a storage optimization.

The paper is evidence that a stronger contract can be engineered, not evidence that Cedar's arbitrary external desk already has it. Our agent cannot make the desk's ledger update and its own local completion update atomic merely by placing both calls in a client-side function. Nor does attaching a database transaction to the agent encompass a separate printer or a third-party endpoint. Ask exactly which effect RIFL-like machinery covers in a proposed integration. Issuing a row in one storage system is not automatically the same effect as producing an external ticket.

A provider can also offer a contract that focuses on operation status rather than replayed responses: accepted, processing, applied or rejected without effect. The critical questions are which transitions are terminal, whether results are historical, how copies are correlated, and whether a terminal no-effect result excludes later execution. These can support recovery without using the same implementation as RIFL. Evaluate the promise the agent needs, then ask how the recipient preserves it through crashes, migration and deletion. An unfamiliar implementation is not weaker merely because its vocabulary differs.

There is a useful procurement consequence. Requiring every tool to claim exactly once can encourage answers that omit the boundaries. A narrower question is more diagnostic: after issuance and response loss, what retained evidence can establish the original effect, and for how long can the original identity be repeated without another issuance? Then ask what happens when evidence retention ends. The answer can reveal a supported automatic-recovery interval, a terminal query path or a deliberate unsupported region. Each is more informative than a platform label or a promise with no failure model.

This article does not evaluate persistence implementations, prove a vendor's service correct or compare benchmark numbers. Its stronger-contract discussion removes the assumptions responsible for the paired-history limit. That is the right use of the literature: identify capabilities sufficient for a particular inference and the assumptions they require. If a deployed recipient's documentation is weaker, use the weaker contract. Do not inherit the paper's guarantees through an analogy, and do not treat an internal test that happened to survive one crash as proof of every claimed lifecycle property.

Derive the next action instead of guessing a status

Now turn the distinctions into a recovery procedure. Begin with the unchanged operation identity, its original arguments and the precise protected effect. Gather recipient evidence without manufacturing a replacement request. Classify the effect as known applied, known not applied, pending or unknown. Pending means the recipient positively reports processing still underway; unknown means the evidence does not settle the outcome. Absence alone belongs in unknown unless its documented meaning is stronger. Classification describes what is established, not what the model predicts is most likely.

Keep a second field for whether the old operation can still act, and a third for whether repetition remains protected. They are not redundant. Known not applied at this instant plus still eligible original execution is not terminal no effect. Unknown effect plus active protection may allow repetition of the original. Known applied plus unestablished protection still justifies recording the existing effect without repeating it. Preserving these dimensions is the article's usable method: decisions depend on their combination rather than on a new name for an all-purpose failure state.

For known applied, repair local completion from the receipt and avoid further issuance. For authoritative terminal no effect, consider a newly authorized operation under current preconditions; terminal rejection is not itself permission to try different arguments. For pending, follow the service's supported observation or same-operation repetition behavior. For unknown with established active protection, a repeat can be permitted within that exact contract, while the outcome remains unknown until better evidence arrives. For unknown without established protection, the procedure cannot authorize an automatic fresh issuance merely to finish the task.

The procedure separates safety permission from operational preference. A duplicate-safe repeat might still consume quota, increase load, return a cached error or violate the service's recommended pacing. It need not be useful simply because it is safe for ticket count. Observation might be preferable when the original is actively processing. Conversely, a status endpoint may be unavailable while protected repetition is the only documented way to retrieve a result. Use provider guidance to choose among permitted actions; do not confuse permission with a universal instruction to repeat.

When evidence sources disagree, compare their authority and boundaries rather than vote. A historical terminal issuance receipt and an empty current search result are not equally strong statements about past issuance. Two independently queried caches do not necessarily provide independent application evidence. If two authoritative terminal answers for the same operation contradict each other under the claimed contract, record a contract violation or unresolved evidence conflict. Do not quietly choose the answer that enables completion. Contradiction changes the evidence quality and requires an explicit response.

Unresolved needs an operational owner, but ownership cannot be invented. The agent can expose the missing fact, supported observation paths, current protection status and the consequence of a new operation. A human can then obtain a receipt, inspect the recipient's authoritative history or approve a business exception that accepts a stated risk. Such an exception is a separate decision, not proof that the original failed. The system should be able to report a completed investigation with an unresolved issuance outcome without treating that as a successful ticket.

For security, the most important discipline is preventing an untrusted suggestion from becoming evidence. A document saying the desk lost the request, or a model explanation saying the earlier attempt was harmless, does not originate from the recipient's outcome mechanism. Those claims can guide investigation but cannot satisfy the receipt contract. This is not another prompt-injection taxonomy. It is a specific boundary on recovery: unsupported content must not transform unknown into terminal no effect, thereby allowing the agent to create a new consequence it could not justify from the actual tool evidence.

An agent's revised plan is not the original operation

The AI-specific complication is not that a model sometimes gives different answers. It is that a changed answer can change the recovery operation. The original request named parcel Cedar and desk East. After a timeout, the model may suggest desk West, another ticket type or a fresh identity to escape an error. Those changes create a new proposal, not another submission of the same bound issuance. The user's broad goal can remain unchanged while the consequence under recovery has changed. Recovery must compare operations, not just natural-language intentions.

Reusing the original key with changed parameters may be rejected by a recipient that binds parameters to identity. That is protective behavior: the service is refusing to collapse two different intended effects into one operation. Issuing a new key instead can be syntactically accepted while bypassing duplicate protection for the unresolved original. The absence of an error is therefore not evidence of safe recovery. Stripe's documented changed-parameter guidance requires first establishing that the original did not succeed and is not still executing before a corrected operation is submitted.

An agent can also alter parameters through apparently cosmetic normalization. Mapping desk East to an alias might be harmless under one provider's canonicalization rules and a different endpoint under another's. Replacing a relative date or recomputing a quantity can materially alter the effect even when the summary still says issue Cedar's ticket. Retain the exact original operation representation relevant to the recipient's comparison. A canonical representation, one normalized according to explicit rules, helps compare meaning only if those rules agree with the recipient's identity and parameter contract.

Authorization for recovery is a separate concern from evidence of the old effect. Suppose a terminal no-effect receipt establishes that East issued nothing and the original cannot issue later. That does not authorize West. Current policy or a user decision must approve the new issuance. Conversely, approval to try West does not prove that East failed. Keep both statements visible: what the recipient established about the original and what authority permits for the next operation. Combining them in one generic retry-approved badge makes it difficult to see which question actually received an answer.

Tool wrappers should expose the distinction in their result shape. Return operation identity, effect evidence, terminality, observation provenance and the scope of any active protection to the recovery layer. Provenance here means where the observation came from, not a model's explanation of it. Do not convert every timeout into a boolean false or every acceptance into true. A useful machine-readable result preserves the uncertainty the next decision needs. The model may explain it to a user, but its explanation must not rewrite the fields that govern permitted effects.

The strongest illustration is the cached-error case. The agent can keep receiving an error while safe repetition remains available for East. Switching to West looks like progress because a new call may succeed. But progress at West can coexist with an already-issued ticket at East, or a delayed East issuance still pending. The revised plan has solved the model's discomfort with an error response, not the business uncertainty. Require the proposed change to confront those surviving histories explicitly before it is treated as recovery rather than a new risk-bearing action.

This method applies wherever an agent can reformulate a consequential tool call after uncertainty: issuing a reservation, creating an account, starting a job or changing a persistent entitlement. Those examples are transfers of the reasoning, not extra worked stories or claims that all services share one contract. Host choice, token federation and cryptographic strength do not resolve the missing receipt. They may determine who can act and under which credentials. The recovery question remains what facts about the old operation justify allowing the next consequence.

Test the inference and state the remaining limits

A meaningful test should challenge the recovery conclusion, not merely make a request timeout. Build a harmless fake recipient that issues an in-memory collection ticket, records attempt identities and can delay responses or requests on command. No real desk, money or customer data is needed. Arrange the two histories so the worker receives identical timeout observations while the hidden effect differs. Then verify that the same recovery logic does not confidently label both as failed or issue an unprotected replacement. The expected result is preserved uncertainty, not a chosen success rate.

Add a delayed-original schedule. Let an accurate lookup return no ticket while the old request remains eligible, then release the old request after the worker considers replacement. A safe policy refuses the inference that current absence makes a new operation harmless. Add a terminal-no-effect variant whose closure covers late copies, and verify that the policy can distinguish its stronger evidence. Merely attaching terminal to a response should not pass the test; the fake recipient must model the documented exclusion that gives that response its meaning.

Exercise protection independently from outcome knowledge. Have the fake recipient retain an indeterminate error and collapse same-operation attempts without issuing additional tickets. The worker should report protected repetition with unknown completion, not convert repeated errors into proof of nonissuance. Then simulate loss of the retention guarantee and verify that the worker withdraws automatic duplicate-safe retry permission while preserving the same operation identity. The important comparison is a change in justified action caused by a change in contract capability, not a change in the model's wording.

A contract test suite can also cover parameter changes, delayed status events and evidence conflict. Ask the model to propose West after East times out and ensure the recovery layer treats that as a new proposal. Deliver a late pending event after a terminal issuance receipt and check that it does not regress known completion. Present contradictory authoritative receipts and demand an explicit conflict result. These are proposed defensive tests, not tests reported as run in this article. No empirical reliability, throughput or model-accuracy result is claimed.

A local fake cannot establish that a production recipient preserves its promises. Its purpose is to test that the client's decisions match the contract it claims to depend on. Provider verification requires documentation, supported failure testing, retention behavior and the actual persistence boundaries. Even then a finite test set does not prove all failure interleavings. The paired histories provide a compact counterexample to a faulty inference; they do not exhaust every possible concurrency or service failure. Explain this distinction before presenting a successful harness as evidence of end-to-end correctness.

The limits are consequential. If the recipient has no reliable effect evidence and protection is unavailable, the method may never resolve the original issuance automatically. Escalation can cost time, and waiting can miss a business deadline. A business owner may deliberately choose a second attempt while accepting duplication risk, but that is not a technical guarantee. There is no invented threshold at which uncertainty becomes failure. The analysis assumes the protected effect and operation are defined correctly; a mistaken definition can make a perfectly followed procedure protect the wrong consequence.

The integrated decision is therefore precise. Reconstruct what the recipient lets you know about the effect, what it excludes about later original execution and what it still protects about repetition. Record a known effect without repeating it. Consider a corrected operation only with terminal no-effect evidence and current authority. Use unchanged repetition only within its documented protection and behavior. Otherwise obtain better evidence or preserve unresolved. The quality of recovery is not how quickly an agent produces another success message. It is whether that message, and every new effect allowed to reach the recipient, can be justified.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

Glossary

Protected effect

The exact external consequence whose duplication or omission matters, such as issuance of one collection ticket.

Recipient contract

The tool owner's guarantees about operation identity, effects, response meaning, failure recovery and lifecycle.

Operation and attempt

An operation names one intended business effect; an attempt is one submission seeking that effect.

Terminal receipt

An authoritative, correlated statement about a settled operation outcome at a named effect boundary.

Terminal no effect

Evidence that no protected effect happened for the operation and that old submissions cannot produce it later.

Idempotency

Repetition preserves the intended effect beyond its first application; this need not mean only one internal execution or log entry.

Duplicate protection

Recipient enforcement that prevents an additional protected effect for a recognized operation under a defined scope and lifetime.

Retention

Keeping the operation's protective or outcome record for the interval promised by the service.

Eventual consistency

A change can exist while a subsequent observation still sees an older state; its exact guarantees depend on the service.

Quiescence

The condition in which old work cannot subsequently produce the protected effect; stopping one observed worker need not establish it.

Linearizability

Operations appear in a single ordering that respects their real-time relationships.

Unresolved outcome

An explicit state where available evidence does not justify a terminal effect conclusion; it is neither success nor established failure.

References

1. RFC 9110: HTTP Semantics (2022), sections 9.2.2 and 15.3.3
2. RFC 9111: HTTP Caching (2022), sections 2 and 4.4
3. RFC 7240: Prefer Header for HTTP (2014), section 4.1
4. Lee, Park, Kejriwal, Matsushita and Ousterhout: Implementing Linearizability at Large Scale and Low Latency (SOSP 2015)
5. Saltzer, Reed and Clark: End-to-End Arguments in System Design (TOCS 1984)
6. Stripe: Advanced error handling (API v1/v2 distinctions; checked 2026-11-08)
7. Amazon EC2 Developer Guide: Eventual consistency in the Amazon EC2 API (checked 2026-11-08)