A camera-kit reservation request times out. The assistant has no response, but the equipment service may already have created the reservation. A second attempt needs a decision about that uncertainty, not a fresh request identity.
This guide is for the process owner and integration lead deciding what an AI-assisted workflow may do after an unclear write result. MAJLS proposes a retry-decision worksheet that separates one intended business action from its execution attempts. The camera-kit records below are illustrative; no live inventory service or demonstrated MAJLS integration is involved.
Understand what the destination promises
AWS describes an idempotent operation as one that can be retried without additional side effects.[1] Its preferred approach uses a caller-provided request identifier: requests from the same caller with the same identifier can be treated as duplicates.[1] AWS also explains why identical parameters alone can be ambiguous: a caller might genuinely want two identical resources.[1]
For this worksheet, the intent identifier means "this approved reservation," while the attempt identifier means "this particular transmission." A payload fingerprint helps compare versions. Neither a local log nor a fingerprint establishes a server-side replay guarantee.
Inspect the actual destination contract. Stripe, for comparison, saves the first executed request's status and body and returns the same result on later requests with that key, including 500 errors.[2] It rejects changed parameters and generates a new request if a key is reused after the original is pruned.[2] Those are Stripe's rules, not universal rules for inventory services.
Under Stripe's contract, a replay can return an old error rather than complete the intended work.[2] Do not change the identity to escape it. Have the technical owner resolve the documented condition.
MAJLS framework: the retry-decision worksheet
Complete these blocks before allowing replay. Unknown contract support means hold.
| Block | Fields to record |
|---|---|
| Business intent | Approved operation and effect; stable intent ID; caller, account and destination scope; immutable payload/version; approving owner; excluded downstream effects |
| Integration contract | Supported endpoint; deduplication scope; parameter matching; in-flight/concurrent behavior; retention and its start point; retryable conditions; verification route; contract version and technical owner |
| Attempt policy | Allowed attempt count and waiting interval; one active sender; current replay permission; stop conditions and reconciliation owner |
| Attempt evidence | Attempt ID/time; original intent ID; payload fingerprint; result or timeout; destination resource/receipt ID; readback evidence; next allowed decision |
Keep request identifiers free of personal information; Stripe explicitly advises against sensitive data in idempotency keys.[2]
Apply these decision branches:
- Verify a matching existing destination resource. Record its identity and current state before closing the intent; a receipt alone is insufficient for this worksheet.
- Replay only when the original identity, unchanged payload, current contract window, eligible result and permission all match, with no unresolved concurrent attempt. Use the same intent identity, not a new business request.
- Hold when any required condition is missing. Send the exact failed condition and available destination evidence to the named owner for reconciliation.
The AI-assisted role may assemble this record and propose a branch. The process owner sets execution permissions. A named human retains approval for consequential financial, legal, safety, access or customer-commitment actions; a replay contract grants none of that authority. Issuing equipment or sending a notification remains outside this example's permission.
Filled example: one camera-kit reservation
Everything below is illustrative, including the service contract, timestamps, outcomes and identifiers. These are synthetic tabletop cases, not API responses or performance results.
The fictional equipment owner approves reserving kit CK-07 for an internal studio, 5 October 2026, 09:00–12:00 UTC. Intent RES-104 belongs to caller studio-a at inventory endpoint reserve/v1; payload v1 contains that kit and interval. The attempt log uses symbolic fingerprint FP-v1, a placeholder rather than an actual computed hash. Issuance and notifications are excluded.
The assumed contract deduplicates by caller plus endpoint plus intent ID for 60 minutes from first execution, rejects changed parameters and in-flight concurrent submissions, and exposes lookup by intent and reservation ID. Its read-only replay-status check reports first-execution time and must show no execution in flight before replay. The illustrative approved policy permits at most two total transmissions, a 30-second wait before the second, and one active sender. A timeout is replay-eligible only after the sender has stopped and the destination check clears. These numbers are invented policy inputs, not recommendations for a real service.
| Attempt log | Intent/payload | Recorded result and evidence | Next decision |
|---|---|---|---|
| A1, 08:00:00 UTC | RES-104 / v1 / FP-v1 | Response lost; no receipt; destination outcome unknown | Keep open; check replay conditions |
| Check, 08:00:30 UTC | RES-104 / v1 | Synthetic status: first execution 08:00:00; no execution in flight; sender stopped; contract and permission current | Allow second transmission; completion still unknown |
| A2, 08:00:30 UTC | RES-104 / v1 / FP-v1 | Synthetic reply identifies reservation R-88 | Verify R-88 before closing |
| Readback, 08:00:40 UTC | RES-104 / v1 | Synthetic lookup confirms R-88, CK-07, approved interval, active state | Record verified completion; no further transmission |
The following are alternative branches from A1, not additional events after the successful branch above.
| Case | Observable condition | Worksheet decision |
|---|---|---|
| Lost response, 08:00:30 | Unchanged v1; current window; sender stopped; no execution in flight; documented replay permission | Permit A2 with RES-104, then verify its outcome |
| Duration changed to 13:00 | v2 differs from approved v1, identity still RES-104 | Hold; equipment owner reviews amendment and technical owner reconciles original intent first |
| Replay considered at 09:01 | Declared retention has expired | Hold; reconcile destination before considering any newly authorized action |
| Receipt R-88 found | Current destination state cannot be verified | Keep open; owner investigates; receipt does not establish closure |
An incomplete lookup that finds nothing is not evidence of non-execution under this worksheet. Likewise, a second worker still sending A1 creates a concurrent-attempt hold, even if the planned waiting interval has elapsed. A model confidence score cannot clear either condition.
Tabletop checklist before connecting tools
Walk these cases through the worksheet with the integration lead:
- Remove documented replay support: the decision must be hold.
- Change one payload field while retaining RES-104: the decision must be hold.
- Move the replay beyond retention: the decision must be hold.
- Supply a receipt without verifiable current state: closure must remain blocked.
- Leave another sender unresolved: replay must remain blocked.
Start with one uncertain write and fill the contract block from the destination's current documentation. If the technical owner cannot establish that contract, keep replay disabled and give the process owner a reconciliation task. This worksheet controls one request's replay; it does not promise exactly-once completion across a whole workflow.