A shadow that must not become a second machine

Digital-twin literature begins with a useful family resemblance. A twin is a data-connected representation of some real entity or process, kept synchronised at a frequency and fidelity chosen for a purpose. The Digital Twin Consortium emphasises representation, synchronisation, historical state and simulated futures. ISO 23247 supplies manufacturing principles and a reference architecture. NIST adds a warning that matters here: digital twins can concentrate information and remote-control capability, so compromise or divergence can produce false views and consequential effects.[1][2][3]

An operational twin, as used in this paper, is narrower than that broad category. It is a purpose-bounded, stateful model used to rehearse decisions against an operating process. It may combine observed state, explicit rules, predicted transitions and uncertainty. It is not required to reproduce every property of the live system. It is required to preserve the properties that determine whether the proposed decision remains admissible.

Why not call any database copy a twin? Because a copy answers “what did we last observe?” while a useful operational twin also answers counterfactual questions: “what would likely happen if we reserved these slots, delayed this task or changed this route?” Why not call it a simulator? Because it is tied to a named operating boundary, refreshed from that boundary and judged against current operational decisions. Why not call it the world state? Because world state is whatever the authoritative process currently recognises, while twin state is a versioned claim about that world.

The smallest useful shadow

Suppose Cedar Depot has ten cold-storage positions. Six are occupied. A transfer of four pallets appears feasible. A full replica might model carrier routes, compressor duty cycles, labour availability, door openings, energy prices and every barcode transition. The immediate decision, however, depends on only four causal properties: authoritative occupancy, outstanding reservations, temperature compatibility and whether the destination is accepting transfers.

Model scope should follow decision sensitivity. Add a state variable when changing it within a plausible range can change the proposed action, its ranking or its admissibility. Otherwise, the field may be operationally informative but is not load-bearing for this twin. This purpose test keeps the shadow small enough to validate, inspect and discard when its assumptions expire.

The asymmetry that keeps possibility separate from authority

A twin needs a close relationship with the live operation, but “close” hides two different couplings. Epistemic coupling determines how observations enter the model, how quickly they arrive, how provenance is retained and how model error is measured. Normative coupling determines whether anything inside the model is allowed to change the live world.

These couplings should not rise together by default. High-rate observations, rich history and good calibration may justify more confident forecasts. They do not justify a write credential. Evidence about what will happen is not authority to make it happen. This distinction resembles zero-trust architecture’s resource-centred refusal of implicit trust: authentication and authorisation remain explicit even when the surrounding network appears familiar.[6]

The operational-twin contract

The boundary becomes implementable when it is written as a contract rather than left as an architectural intention. Eight fields are enough for a smallest useful version. They do not describe the whole twin. They describe what must be true for another component to rely on it.

The contract prevents several category errors. A prediction is not a precondition. A precondition is not a permission. A permission is not an effect. An effect receipt is not a verified outcome. Each stage has a different issuer, failure mode and evidential meaning.

flowchart LR
  A["A shadow that must not become<br/>a second machine"] --> B["The asymmetry that keeps<br/>possibility separate from<br/>authority"]
  B --> C["Plans that survive a changing<br/>world"]
  C --> D["When the shadow lies"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#087A98,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Plans that survive a changing world

A plan is never computed against “the warehouse”. It is computed against a cut through the warehouse’s history. That cut includes the last event seen from each source, the version of every rule consulted, the identity and purpose under which context was retrieved, and the model version that generated transitions. Without those coordinates, the plan cannot be replayed or meaningfully challenged.

The time problem has two independent parts. Descriptive freshness asks how far the twin may have diverged from the live process. Entitlement freshness asks whether the actor may still perform the proposed action. A perfect state replica paired with yesterday’s permission is unsafe. A current permission paired with yesterday’s state is also unsafe. Execution requires both the world and the right to act to be current enough for that action.

Plans need provenance, not just explanations

A natural-language rationale can explain why the agent preferred Route 2. It cannot establish which reservation feed it saw, which policy version permitted the move or which transition function predicted a six-minute completion. For consequential planning, the useful explanation is partly a provenance graph: entities used, activities performed and agents responsible. W3C PROV provides a general vocabulary for representing such relationships.[7]

The proposal should therefore carry references rather than copied assertions wherever possible. A snapshot identifier points to immutable state evidence. A policy decision has its own issuer and expiry. A predicted consequence names the twin version and branch. A typed action names the authoritative API and expected postcondition. This lets an auditor remove one dependency and ask whether the plan would have changed.

From proposal to verified outcome

Once an action passes the gate, reliability depends on transaction semantics. HTTP defines an idempotent method as one whose intended effect is the same after one or several identical requests. Many consequential business operations are expressed through non-idempotent application APIs, so the contract must supply an idempotency key and the server must remember the result associated with that key.[8] The client may then retry an unknown outcome without knowingly creating a second effect. AWS describes the same pattern through caller-provided request identifiers.[9]

Idempotency solves duplication, not truth. A server may return a success receipt before downstream state converges. A network timeout may hide a committed effect. A status field may change while the physical process fails. The end-to-end argument in system design remains relevant: only a check at the endpoint that matters can establish that the intended work was accomplished.[10] In this architecture, the executor issues an effect receipt, while a separate readback evaluates the postcondition.

Executable lab: make the hidden races visible

The browser lab below implements the Cedar example with synthetic state. It compares an unsafe path, where the twin writes as though its snapshot were live, with the authority-asymmetric path. Select faults, run both paths and inspect the trace. The lab encodes four assumptions: capacity is hard, policy is checked at execution, idempotency keys are durable, and postconditions require readback.

A positive result means the gated path contains the injected fault by rejecting, deduplicating or escalating it while preserving the invariant. A negative result means the control contract is incomplete for that fault. The lab cannot establish that a real twin is accurate, that a production integration is secure or that every domain permits compensation. It exposes control logic that prose would otherwise conceal.

const invariant = state => state.occupied <= state.capacity;

function authorise(proposal, live, policy, nowMs) {
  if (proposal.expiresAt < nowMs) return deny("EXPIRED");
  if (!policy.allowTransfers) return deny("POLICY_DENY");
  if (live.occupied + proposal.quantity > live.capacity) {
    return deny("LIVE_PRECONDITION_FAILED");
  }
  return { allow: true };
}

function executeOnce(proposal, live, receiptStore) {
  const prior = receiptStore.get(proposal.idempotencyKey);
  if (prior) return prior;                 // safe retry

  live.occupied += proposal.quantity;      // authoritative effect
  const receipt = { key: proposal.idempotencyKey, committed: true };
  receiptStore.set(proposal.idempotencyKey, receipt);
  return receipt;
}

function verify(proposal, live) {
  return invariant(live) && live.occupied === proposal.expectedOccupied;
}

When the shadow lies

Every twin is wrong in at least three ways. It omits variables, estimates some values and simplifies transitions. Those imperfections are not automatically defects. A subway map is useful because it discards street geometry. The question is whether the omitted or uncertain property can reverse the decision being made.

NIST’s trust analysis for digital twins identifies temporal divergence, accuracy, functional equivalence, composability and cybersecurity among the relevant concerns. It also warns that users may treat a convincing representation as an oracle, even when the twin’s quality is conditional on purpose and operating range.[3] This paper adds an operational consequence: twin error becomes dangerous in proportion to the authority and irreversibility attached to its output.

Five ways the twin can mislead the agent

Stale state is the obvious case: the model is behind the world. Blind state is subtler: the feed is current but omits a variable such as a manual hold. Wrong transition means the current state is accurate but the simulated consequence is not, perhaps because a queue behaves differently under peak load. Wrong boundary means the twin models the warehouse but not a carrier contract that makes the route inadmissible. Compromised evidence means an attacker or faulty integration supplies plausible observations, policies or receipts.

These failures demand different tests. Faster streaming helps stale state but not blind state. More historical calibration helps transition error but not a revoked permission. Cryptographic provenance helps identify an issuer but does not prove the issuer observed reality correctly. Independent readback helps detect outcome mismatch but may arrive too late to prevent irreversible harm. A mature control design names the failure it is meant to contain.

The strongest alternative: do not use a twin

A deterministic workflow with explicit state queries is often better. If the task has one short path, stable rules, cheap live reads and no need to compare futures, a twin adds another model to validate and reconcile. A database transaction may provide stronger semantics with less machinery. The same is true when the environment cannot be modelled at the decision’s required fidelity, when safe uncertainty bounds are unavailable or when every plausible action is irreversible.

A twin also cannot repair a poorly governed system of record. If no component owns slot truth, if manual work leaves no events or if policy cannot be evaluated at execution, the shadow will inherit ambiguity. The correct first investment is operational observability and typed control, not simulation.

A testable prediction

The authority-asymmetric design yields a concrete research hypothesis. Hold planning quality constant. Give the operational-twin system current policy enforcement, live precondition checks, durable idempotency and independent readback. It should convert a larger share of injected state and permission faults into explicit rejections or recoverable unknowns than either a direct-write twin or a single agent calling tools without a versioned state model.

stateDiagram-v2
  [*] --> Claim
  state "Evidence status Published<br/>foundation and…" as Claim
  state "Thought experiment 1 The<br/>seven-minute…" as Test
  state "The smallest useful shadow" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Start with one reversible effect

The smallest useful implementation is not a miniature enterprise. Choose one action whose effect can be observed and, preferably, reversed. Define one authoritative system of record, one purpose, one actor class and one postcondition. Then build only enough twin state to reject an unsafe proposal.

For Cedar, that means slot reservations rather than complete pallet movement. The live system owns occupancy. The twin consumes versioned occupancy and reservation events. Its transition model answers whether a proposed reservation set remains within capacity and compatibility constraints. The agent may compare candidate sets, but it cannot reserve them. The authority kernel accepts only a ReserveSlots contract with named pallets, named slots, a short expiry, a live precondition and an idempotency key. Readback asks whether those exact slots are reserved for that exact transfer.

Run the design first in shadow mode. Let the agent and twin produce proposals while the existing workflow continues to make decisions. Compare predicted and actual transitions. Record which omitted variables would have changed admissibility. Deliberately inject stale events, policy changes and unknown outcomes. This stage establishes model usefulness and control behaviour without granting effect authority.

Next, permit automatic release only for a narrow envelope: low-value reservations, short duration, reversible cancellation and no manual hold. Keep higher-risk proposals advisory. Expansion should follow operating evidence, not a general confidence score. A new action type, broader subject set or longer validity window changes the assurance case and should be reviewed as a new capability.

This sequence also reveals the economic break point. If most proposals are rejected because the twin lacks current state, improve instrumentation. If live checks dominate latency, narrow the preconditions or place enforcement closer to the resource. If the deterministic baseline performs as well, remove the twin. If the twin consistently finds better reversible plans while the boundary contains injected faults, the architecture has earned a wider trial.

type ReserveSlotsProposal = {
  proposalId: string;
  twinVersion: string;
  observationCut: {
    warehouseVersion: string;
    eventWatermark: string;
    observedAt: string;
  };
  actor: { id: string; delegatedBy: string; purpose: "cold_chain_transfer" };
  subject: { transferId: string; palletIds: string[] };
  action: { kind: "ReserveSlots"; slotIds: string[] };
  preconditions: { minimumFreeSlots: number; transferOpen: true };
  uncertainty: { unseenReservationsMax: number };
  expectedPostcondition: { reservedByTransfer: string[] };
  expiresAt: string;
  idempotencyKey: string;
};

sequenceDiagram
  participant Q as Question
  participant M as Mechanism
  participant E as Evidence
  participant D as Decision
  Q->>M: A shadow that must not become a second machine
  M->>E: Evidence status Published foundation and…
  E-->>M: compare rival explanations
  E->>D: Plan in the shadow and commit at the boundary
  D-->>Q: revise scope or act

Plan in the shadow and commit at the boundary

When a team asks whether an agent should act through a digital twin, do not begin with model fidelity or agent intelligence. Begin with the direction of authority. Can the twin change live state, directly or through inherited credentials? If yes, the architecture has created a second control plane whose errors, compromises and stale assumptions can become effects.

The better decision is to separate four questions that are often collapsed. What does the twin claim about the world? What future does the agent propose? What action is permitted now? What outcome did the authoritative process actually produce? A different component or evidential act should answer each question, even when deployment choices place them in the same platform.

Adopt an operational twin only when stateful counterfactual rehearsal changes the quality of a real decision. Keep it non-authoritative. Bind every proposal to a versioned observation cut, uncertainty envelope and expiry. Re-evaluate identity, purpose, policy and live preconditions at the resource boundary. Execute through a typed action with durable idempotency. Treat the effect receipt as evidence of processing, then verify the postcondition through an independent readback. Predefine what happens when the result is unknown.

The distinction also changes procurement and review. A demonstration that shows a twin predicting a route is evidence of planning utility, not governed execution. Ask which service owns live truth, which credential can create an effect, where permission is evaluated, how a policy change reaches enforcement, which clock determines expiry, and whether outcome verification depends on the same path that reported success. A vendor can answer each question without revealing model internals. If the answers collapse into “the agent handles it”, the control boundary is missing.

It changes incident handling as well. When an operation disagrees with the twin, do not immediately retrain the model or overwrite the live record. Preserve the observation cut, proposal, policy decision, request identifier, receipt and readback. Classify the mismatch: stale observation, omitted state, wrong transition, unauthorised effect, duplicate execution or false outcome evidence. That classification points to the responsible control. It also prevents a dangerous reconciliation pattern in which the system edits whichever record is easiest until dashboards agree.

This changes the success criterion. The goal is not a twin that never diverges. Such a promise is incoherent in a changing world. The goal is a system in which divergence becomes visible before harm, where possible; becomes bounded by reversible action, where not; and becomes reconstructable through evidence when uncertainty remains.

Human review should also attach to the uncertainty that matters, not to every proposal. A reviewer needs the live precondition that failed, the branches the twin considered, the consequence of waiting, and the exact authority being requested. They do not need a transcript of every generated token. When the action lies outside the automatic envelope, the system should offer bounded alternatives: approve a smaller reversible reservation, request a fresh observation, defer until a hold clears, or escalate to an owner who can change policy. This preserves human judgement for exceptions instead of turning oversight into a ceremonial click.[11]

For Cedar, the practical decision is modest. Do not automate pallet movement first. Automate short-lived slot reservation inside a narrow envelope. Let the agent explore many allocations in the shadow. Let the authority kernel release only a currently permitted reservation. Let the warehouse own occupancy. Let readback settle what happened. Expand only after fault injection shows that stale state, permission change, timeout and retry produce rejection or recovery rather than silent contradiction.

Plan in the shadow. Commit at the boundary. Believe the outcome only after the world answers back.