A timeout with two possible worlds

A request passes through at least four relevant moments. The caller forms an intent. The remote system accepts or rejects the request. The effect commits. The caller observes an acknowledgement or performs a later readback. These moments are often close together, so ordinary interfaces treat them as one event. Failure separates them.

HTTP formalises one part of the answer. A method is idempotent when multiple identical requests have the same intended effect as one request. That property allows automatic retry after a communication failure, provided the operation is genuinely idempotent or the client can determine that the first request was never applied.¹ The word intended matters. A server can still log every request or produce other side effects. Idempotency is a contract about the requested effect, not a promise that nothing else happens.

Four clocks, not one

The next design move is to stop representing an action with a single status field. A useful action record distinguishes at least four clocks:

1. Intent time: when the principal formed and authorised this particular action.
2. Admission time: when the target system accepted the request for processing.
3. Effect time: when the authoritative state changed.
4. Observation time: when the caller obtained an acknowledgement or read the effect back.

These clocks can share a timestamp in a local database transaction. Across services, they can diverge. A timeout after admission but before observation creates an explicit uncertain state. That state is neither failure nor success.

“Exactly once” belongs to the effect, not the message

Engineers sometimes describe the goal as exactly-once delivery. That phrase can obscure the real obligation. A message broker may deliver once while the worker crashes after applying the effect but before recording completion. It may deliver twice while the application correctly deduplicates both attempts into one effect. The number of deliveries and the number of intended effects are different variables.

Consider a queue containing the instruction “credit account A by £10”. A worker reads the message, credits the ledger, and then loses power before acknowledging the queue. The queue reasonably redelivers. If the worker treats the second delivery as a new instruction, the ledger changes by £20. If it records the stable intent identifier inside the same protected boundary as the credit, the second delivery can return the first result. The queue still delivered at least twice; the business effect occurred once.

This distinction becomes harder across several systems. Suppose a payment service commits the transfer, a notification service sends a message and an analytics service records the event. One idempotency key does not automatically make all three effects atomic. Each consumer needs its own deduplication or replay contract, and the orchestrator needs evidence about which effects completed. Otherwise the system can be financially correct but communicatively wrong, or communicatively correct while the ledger is uncertain.

The useful guarantee is not “the network delivered exactly once”. It is “this declared intent produced no more than one authorised effect in each governed boundary, and every required effect can be read back”. That formulation is less elegant, but it survives crashes, retries and partial execution. It also reveals why a single green checkmark is inadequate for compound actions.

This solves duplicate execution under uncertainty. It does not solve whether the action should have been attempted, whether its effects can be repaired, or whether a model had the authority to propose it. For those questions, we need a second distinction.

flowchart TD
  A["The payment that both happened<br/>and did not"] --> B["A timeout with two possible worlds"]
  B --> C["Undo is not one operation"]
  C --> D["Transaction modes on the slope"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#B96D00,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Undo is not one operation

Imagine an assistant changing a draft invoice address. The new value is wrong. A versioned database can restore the previous address in milliseconds. Now change one property: the invoice has already been sent, imported into the supplier’s system and used to schedule a shipment. The original field can still be restored, but the outcome cannot.

Classic transaction processing gives us atomicity, consistency, isolation and durability for state inside a defined transaction boundary.³⁴ That boundary is powerful, but it is not the world. A database can roll back a row; it cannot make a recipient unread an email, return a lost market opportunity or forget a public allegation.

Rollback, compensation and containment

Three recovery verbs are often mixed together:

• Rollback restores controlled state to a prior valid version, usually before outside observers can rely on the intermediate state.
• Compensation performs a new action intended to neutralise selected consequences of an earlier action.
• Containment stops further propagation when neither rollback nor complete compensation is available.

A refund is compensation. It does not delete the original charge from history, restore the customer’s temporarily reduced balance, recover fees automatically or erase the anxiety created by an unexplained debit. Microsoft’s current guidance makes this boundary explicit: compensating transactions are application-specific, can fail, and do not necessarily return data to its starting state.⁶

A recovery envelope

Rather than ask whether an action is reversible, describe its recovery envelope: the set of states that can still be reached after an error, within an acceptable time, using available authority and resources. Four properties shape that envelope.

1. Restoration gap: how much of the prior state and outcome cannot be re-established.
2. Propagation reach: how many independent systems, people or physical processes can act on the effect.
3. Temporal decay: how quickly recovery options lose value or disappear.
4. External dependence: how much recovery relies on parties or resources outside the controller’s authority.

Each property can be scored ordinally from 0 to 4 for routing, not measurement. A public announcement may score modestly on state restoration because a correction can be posted, but highly on propagation and temporal decay. A database flag may score low on all four. A payment may have a moderate restoration gap, high external dependence and a shrinking recall window.

Here, the four r values are the ordinal recovery properties above. The coupling uplift is one class when at least two properties are already high. This rule deliberately uses the dominant dimension rather than an average. Averaging can hide a fatal property. A perfectly reversible internal record does not make a widely propagated disclosure low risk.

Transaction modes on the slope

The central design decision is not whether an agent may “use tools”. It is which transaction semantics apply to each typed action. Five modes cover most operational cases. They are not maturity levels. A well-designed system may use all five on the same day.

1. Retry-safe mutation. Use a stable idempotency key, request fingerprint, bounded retries and authoritative readback. Appropriate when repetition is the main failure risk and the effect is cheap to restore.
2. Guarded reversible commit. Add version preconditions, a rollback window, immutable history and verification of the post-state. Appropriate when controlled state can be restored before substantial propagation.
3. Compensatable saga. Decompose the workflow into local transactions, record a receipt for each step, define compensating actions and name the pivot after which remaining work must complete. Appropriate when atomic rollback is unavailable but selected consequences can be neutralised.⁵⁷
4. Escrowed pivot. Validate, reserve and prepare first. Require explicit approval against a frozen evidence snapshot. Commit only after resources, authority and recovery plans are ready. Appropriate when the pivot is difficult to reverse but can be delayed safely.
5. One-way commit. Do not allow autonomous release. Require independent verification, named accountable authority, simulation or dry-run evidence where possible, and a containment plan. Appropriate when the act changes rights, publishes sensitive material, produces physical effects or otherwise outruns meaningful compensation.

Idempotency appears in every mode because timeouts and retries remain possible. What changes is what idempotency can accomplish. At T1 it may be the principal safeguard. At T5 it is merely hygiene. Sending the same irreversible instruction only once is better than sending it twice, but it does not make the instruction correct.

The pivot matters more than the workflow label

Saga implementations often distinguish compensable steps, a pivot transaction and retryable steps after the pivot. Once the pivot succeeds, the system cannot simply reverse the earlier sequence; subsequent idempotent work must bring it to a consistent final state.⁷ This is a stronger design idea than “use a saga”. It asks where the option to abort disappears.

Place the pivot as late as possible, but not later than reality permits. Validate beneficiary details before payment submission. Reserve stock before promising delivery. Generate a public statement before the approval meeting, not during it. Freeze the evidence used for approval so the approved object cannot silently change before commit.

A realistic configured-system example

Return to the synthetic supplier payment. The proposal originates in a probabilistic model, but no model output is itself an action. A deterministic action gateway turns the proposal into a typed contract. It validates the supplier identity, invoice identifier, amount, currency, payment date, authority grant and current account state. It then reserves the amount and produces a decision receipt for a human approver.

The approver sees the exact beneficiary, amount, evidence snapshot, recovery class and expiry. Approval authorises only that immutable contract. The gateway submits the transfer with a stable idempotency key. If the connection times out, it queries the bank using the original intent identifier or authoritative transaction reference before deciding whether another submission is permitted. Success is not declared until readback returns the expected effect or a trusted effect receipt arrives.

Review should change position, rather than only intensity

Teams often respond to risk by adding another approval box. The gradient suggests a more precise shift. Low-irreversibility actions can be sampled after execution because rollback remains available. Medium actions need policy checks and readback around commit. High actions need review of the exact contract before the pivot. The highest class needs independent verification and named authority, with no autonomous release.

This also changes what a reviewer sees. “Approve payment?” is not decision-sufficient. The review object should contain the principal, purpose, beneficiary, amount, evidence snapshot, policy result, recovery class, pivot, expiry and expected post-state. Approval of a natural-language summary should not authorise a mutable payload.

stateDiagram-v2
  [*] --> Claim
  state "Thought experiment 1, the<br/>silent wire" as Claim
  state "Four clocks, not one" as Test
  state "“Exactly once” belongs to the<br/>effect, not the message" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Compile the action before the model can call it

A probabilistic model can propose a beneficiary, amount, message or configuration change. It should not decide its own transaction mode, invent its own authority or declare its own success. Those are deterministic control functions.

The smallest useful implementation is an action gateway between model proposals and effectful tools. The gateway accepts only typed contracts. It verifies identity, authority, preconditions and recovery obligations; then it routes the action to the required mode.

The typed action contract

The contract below is intentionally stricter than a generic tool-call schema. It records not only inputs but the conditions under which the effect is allowed, how duplicate intent is recognised, where the pivot lies and what counts as verified completion.

type Level = 0 | 1 | 2 | 3 | 4;
type TransactionMode =
  | "T1_RETRY_SAFE"
  | "T2_REVERSIBLE"
  | "T3_COMPENSATABLE_SAGA"
  | "T4_ESCROWED_PIVOT"
  | "T5_ONE_WAY_COMMIT";

type ActionState =
  | "PROPOSED" | "VALIDATED" | "PREPARED" | "AUTHORISED"
  | "SUBMITTED" | "UNCERTAIN" | "COMMITTED" | "VERIFIED"
  | "COMPENSATING" | "COMPENSATED" | "CONTAINED" | "REJECTED";

interface RecoveryVector {
  restorationGap: Level;
  propagationReach: Level;
  temporalDecay: Level;
  externalDependence: Level;
}

interface AuthorityGrant {
  principalId: string;
  capability: string;
  purpose: string;
  notBefore: string;
  expiresAt: string;
  maxValue?: number;
  currency?: string;
}

interface IdempotencyContract {
  intentId: string;
  key: string;
  requestFingerprint: string;
  scope: string;
  expiresAt: string;
}

interface ActionContract<Payload> {
  actionType: string;
  payload: Payload;
  targetSystem: string;
  expectedStateVersion?: string;
  authority: AuthorityGrant;
  idempotency: IdempotencyContract;
  recovery: {
    vector: RecoveryVector;
    mode: TransactionMode;
    rollbackWindowSeconds?: number;
    compensationPlanId?: string;
    pivotStep?: string;
  };
  review: {
    level: 0 | 1 | 2 | 3 | 4 | 5;
    evidenceSnapshotHash: string;
    requiredApproverRoles: string[];
  };
  verification: {
    readbackQuery: string;
    expectedPostcondition: string;
    effectReceiptRequired: true;
  };
}

function compileMode(v: RecoveryVector): TransactionMode {
  const values = Object.values(v);
  const dominant = Math.max(...values);
  const coupled = values.filter(x => x >= 3).length >= 2;
  const recoveryClass = Math.min(5, dominant + (coupled ? 1 : 0));

  if (recoveryClass <= 1) return "T1_RETRY_SAFE";
  if (recoveryClass === 2) return "T2_REVERSIBLE";
  if (recoveryClass === 3) return "T3_COMPENSATABLE_SAGA";
  if (recoveryClass === 4) return "T4_ESCROWED_PIVOT";
  return "T5_ONE_WAY_COMMIT";
}

// Invariants enforced by the action gateway:
// 1. Same idempotency key + fingerprint cannot create another intended effect.
// 2. A changed fingerprint under the same intent ID is rejected.
// 3. No execution occurs outside authority scope, time or value bounds.
// 4. UNCERTAIN is resolved by authoritative readback, never by assumption.
// 5. T3 requires a resumable compensation plan and named pivot.
// 6. T4 and T5 cannot commit on model authority alone.
// 7. VERIFIED requires an effect receipt or authoritative post-state readback.

The schema exposes logic that prose usually hides: uncertainty is a state, authority is bounded, recovery is typed and successful completion requires evidence from the target system.

Failure injection before release

The contract is useful only if the implementation survives the failure states it names. A minimal test harness should inject four cases:

Interactive irreversibility compiler

The instrument below converts a recovery profile into a proposed transaction mode and review gate. It uses synthetic ordinal inputs. The output is a design prompt, not a compliance decision or actuarial risk score.

What the instrument establishes

A positive result means the proposed action contract contains the minimum fields and controls for the routed mode. It permits implementation testing, not execution in production. A negative result means the action lacks a credible recovery path, authority gate or verification method. The correct response may be to redesign the workflow, narrow the capability or prohibit the action.

The tool cannot establish that an action is ethically justified, legally permitted, free of hidden side effects or safe in every environment. It also cannot infer recovery values from prose reliably. Human domain judgement remains necessary, especially for harms that do not appear in system state.

Where the gradient can mislead

The framework’s strongest boundary is that recoverability is not identical to acceptability. A system may technically reverse a discriminatory eligibility decision while the person still loses time, dignity or opportunity. A high-consequence action can require strict oversight even when database state is easy to restore. This is why consequence remains a separate axis.

The opposite failure is over-gating. A slow approval path can itself create harm during fraud containment, safety response or service restoration. The answer is not to bypass the gradient. It is to design pre-authorised emergency contracts with narrow scope, short expiry, deterministic triggers and mandatory post-event review.

Ordinal scores can also create false precision. Two reviewers may disagree about propagation or temporal decay. That disagreement is useful when it exposes a hidden assumption, but the number should never become a claim that “3.7 is safe”. Use the instrument to route design obligations, then test the actual recovery mechanism.

NIST’s AI RMF treats risk management as continuous across the lifecycle and asks organisations to assign responsibilities, manage impacts and prepare mechanisms to disengage or deactivate systems.⁸¹⁰ Its Generative AI Profile also notes that different systems and risks may require different levels of human oversight, tracking and management review.⁹ The gradient supplies one engineering answer to that general requirement: vary the control location and transaction semantics according to the action’s recovery envelope.

sequenceDiagram
  participant Q as Question
  participant M as Mechanism
  participant E as Evidence
  participant D as Decision
  Q->>M: The payment that both happened and did not
  M->>E: Thought experiment 1, the silent wire
  E-->>M: compare rival explanations
  E->>D: Ask for proof earlier as undo becomes harder
  D-->>Q: revise scope or act

Ask for proof earlier as undo becomes harder

Stop deciding whether an AI system may “take actions” in the abstract. That category is too coarse. Updating a draft note, issuing a refund, releasing a payment, publishing an allegation and moving a physical device are not the same permission with different risk scores. They require different transaction semantics.

The decision to make before connecting a tool is this: what recovery envelope does each typed action have, and which mode follows from it? Once that is explicit, several design choices become clearer.

• Use stable intent identifiers and idempotent handling wherever communication can fail.
• Represent uncertain outcomes explicitly and close them with authoritative readback.
• Call something rollback only when controlled state can truly be restored.
• Call something compensation only when a durable, resumable balancing path exists.
• Move review before the pivot as propagation, time decay and external dependence rise.
• Require an immutable decision receipt before commit and an effect receipt after it.

This changes the practical unit of governance. The unit is not the model, the agent or even the tool. It is the typed action contract at a particular recovery class. A single agent can be highly autonomous for T1 actions, bounded for T2 and T3, and unable to commit T4 or T5 actions without named authority.

The purpose is not to eliminate failure. It is to prevent uncertainty from becoming duplicate effect, prevent compensation from masquerading as erasure, and prevent a persuasive proposal from acquiring authority by crossing an untyped interface. As the world becomes harder to undo, the system must know more, prove more and ask earlier.