Recover an agent action when the receipt is missing

The proposed tool creates one internal handoff ticket after an authorized operator accepts the exact payload. The agent may propose the action; the receiving service owns authorization and execution. A ticket is an external effect in the hypothetical design, so losing its receipt is different from losing a draft.

Your deliverable is a seven-case recovery table and a one-page operator runbook. Spend five minutes on the contract, twelve on the trace, eight on recovery decisions and ten on a receiving-team teach-back. Use the event trace CSV in a spreadsheet or text editor. No installation, credentials or customer data are needed.

Each logical action has an operation key scoped by the trusted tenant and action type. A caller cannot choose another tenant through the key. In this exercise, accepted payloads have a stable fingerprint; a replay must match the original payload. Changed intent needs a new authorized decision, not a disguised retry.

The hypothetical receiver maintains an operation record that binds the scoped key, accepted payload fingerprint, execution state and result reference. Its receipt replay returns an existing result without repeating the effect. These are supplied fixture assumptions; implementing them in a distributed service requires evidence that the actual receiver and storage provide the promised behavior.

A client deadline does not cancel a dispatched action. The stop control prevents new dispatches; it does not undo completed effects or guarantee cancellation of in-flight work. An unavailable status lookup is not proof of no effect. An ordinary application log is not automatically an authoritative record of the destination's commit.

For A, B, D, E, F and G, the supplied commit events and rejection/replay descriptions are complete for the case. In C, the destination outcome is deliberately unavailable. Do not infer a missing commit from an incomplete observation. Sequence numbers order events within each case, not across cases.

Read the CSV first. For each case, write the observed effect count if known, receipt state, whether another execution is permitted and the next responsible role. Keep unknown separate from zero.

Use a table with these columns: case; confirmed effects or unknown; receipt evidence; allowed next action; prohibited shortcut; owner; closure evidence. Mark the event that supports every conclusion. A green client screen cannot replace a destination result reference.

For an uncertain action, write interface copy that preserves the operation reference and tells the operator how to reconcile it. Do not display “nothing happened,” automatically retry with a new key or encourage a manual duplicate while the destination result is unknown. Explain what information the receiving operator can safely see and who can inspect the authoritative record.

Decide what the user can continue doing without repeating this action. The course's trusted manual lookup remains available for read-only work; manually creating a replacement ticket is itself a possible duplicate. A recovery path must distinguish those activities.

Separate receipt retrieval from renewed execution. Even a same-key retry is safe only within a demonstrated receiver contract: key scope, payload binding, retention window, concurrent handling and authorization must hold. A header named idempotency-key does not establish those properties by itself.

Choose one repair for E and one evidence request for C. Describe the earliest boundary that can prevent another effect and the observation that would show it works. Preserve the original trace instead of replacing a failure with a cleaner demonstration.

For G, challenge the engineer who proposes “check whether the key exists, then insert.” Ask what happens if both callers observe absence before either writes. Identify where a uniqueness constraint, transaction or receiver guarantee would serialize the decision. The fixture reports one atomic claim; it is not a benchmark or proof of a production implementation.

For F, separate stopping new work, reconciling in-flight work and reversing completed work. If a ticket should be corrected, use the destination's authorized correction process with its own evidence. Do not erase an audit event or call a code rollback a reversal of a ticket.

The receiver retains operation keys for a limited period. Your client reappears after that period with the original key and an uncertain receipt. State which earlier recovery guarantee no longer follows, what destination evidence is needed and who owns the next decision. Do not invent a retention duration or assume the key survives indefinitely.

Then change access: the original operator no longer has permission to create tickets. Explain how the receiver authenticates a receipt lookup and protects the returned reference without granting a new execution. A remembered key is not an authorization credential. A generated plan cannot restore revoked access.

Spend another twenty minutes turning the retention question into an operator decision. These are three independent synthetic cases, each starting from the same fixture. They do not extend the CSV's timeline or describe the live platform. Keep your first decisions before opening the worked interpretation below.

The receiver accepts a scoped key at 09:00 UTC and commits ticket T-H at 09:02, but the caller loses its receipt. For this fixture only, the operation record expires sixty minutes after acceptance, at 10:00. It is available before that instant and absent at or after it. Expiry removes the replay record; it does not delete the destination ticket. The destination retains a separate audit record binding the trusted tenant, original operation reference, exact accepted payload and T-H. The ordinary client cannot read that audit record. No clocks drift in this exercise; actual services need an explicit time and retention contract.

Write one row per case with observation time, expiry time, replay evidence, destination evidence, confirmed effects or unknown, next action and responsible role. Treat 10:00 as a boundary condition, not as “roughly an hour later.” Name the transition that ends the replay guarantee. A matching ticket title or approximate timestamp alone is not the supplied audit binding.

Worked interpretation — compare after your first decisions

In H, the stored receipt confirms the single committed ticket under the supplied contract. Retrieve and record it without another create request. The operation record remains available for only one more minute; that remaining time grants no authority for a new action.

In I, the missing replay record says nothing about whether a ticket exists. The fixture's earlier commit is known to the exercise author, but it is not observable to the operator at this decision point. The operator must preserve an unknown outcome, suppress renewed execution and request destination reconciliation. The original key has no demonstrated duplicate-prevention guarantee after expiry. A new key cannot repair that uncertainty either.

In J, the separately authorized destination evidence confirms one committed effect even though the replay record is gone. Close the uncertainty with the permitted result reference or a limited confirmation according to the requester's current read permissions. Do not return protected audit content merely because the requester remembers the key. Revoked create permission stays revoked. If the committed ticket needs changing, the receiving owner must authorize the destination's correction process; reconciliation itself authorizes neither a new ticket nor a correction.

Now replace J's audit result with “permission denied.” Revise only the conclusions supported by that observation. Denied access is not proof that the ticket is absent, and it does not erase a previously confirmed commit. Route reconciliation to a currently authorized receiving role, with no credential sharing or creation workaround.

Give the receiving operator a usable recovery note

Write the note for I in fewer than eighty words. Include the preserved operation reference, the expired replay window, the unknown destination outcome, the prohibited duplicate and the responsible receiving role. For example:

Receipt unavailable for OP-H. Its replay window ended at 10:00 UTC; the missing operation record cannot establish whether the destination committed. Do not create a replacement or retry creation. The authorized receiving reviewer must reconcile the original operation and accepted payload against the destination audit, then return only evidence the requester may see. Keep the outcome unknown until that evidence is available.

Ask a partner to handle the exact-boundary case from your note. Keep the first decision, comparison, access-denied revision and receiving response in the same portfolio packet. Record any help used. A successful tabletop response is practice evidence, not a measured recovery rate or permission to enable ticket creation.

Ask a partner to handle C using your runbook without asking you what “check it” means. The runbook should identify the actual kind of evidence needed, the responsible receiving role, the safe status to show and the condition for closure. For this fictional exercise, use role names and placeholders rather than invented production console links.

Keep three items in your portfolio: the trace with event references, your first and revised recovery tables, and the operator runbook. Record whether the receiver found the unknown state and avoided duplicate creation. An authored case or completed worksheet does not establish qualification, live reliability or a measured customer result.

Continue with the client-delivery workbook. Worked interpretations are in the Academy lesson “Rehearse shadow rollout, recovery and receiving-team handoff,” under existing training access.