Your Operational Digital Twin Is Live. Can It Help You Decide?

A practical framework for evaluating digital twin capabilities, from live monitoring to autonomous action.

"Digital twin" gets used for at least four different things: a 3D model of the warehouse shown in a board presentation, a live screen counting the orders picked so far, an alert that a conveyor motor is running hot, and a simulation that tells the shift manager which part of the floor needs more people. They don't cost the same to build, they don't sell for the same money, and they don't solve the same problem. When one word covers all four, a buyer can pay decision-support money for a picture, and a team can spend years building the simplest of the four while believing it's building a twin. This article gives you a scale for telling them apart, and a question for testing each claim.

A useful distinction is what the system does with operational data: describe conditions, diagnose problems, predict outcomes, recommend actions or act autonomously.

What makes a twin operational

Grieves and Vickers's account dates the underlying concept to Michael Grieves's 2002 presentation and credits the later name to John Vickers. Its core elements are a physical entity, a virtual representation, and links carrying data and information between them.

For this article, an operational digital twin is a model of a specific asset or process, updated from the operation at a frequency and level of detail appropriate to the decisions it supports. Information can return to the operation through people or control systems.

The Digital Twin Consortium's explanation makes that fitness for purpose explicit: synchronisation frequency and fidelity depend on the use case. A nightly refresh may suit a long-term staffing review; reallocating pickers during a shift needs more current information. Whether data is current enough depends on the decision.

The capability ladder

Stadtmann, Rasheed, Kvamsdal and colleagues describe six capability levels in "Digital Twins in Wind Energy: Emerging Technologies and Industry-Informed Future Directions" (IEEE Access, 2023, section II.B). The paper builds on earlier classifications and applies the framework to wind energy. Here, I adapt it to warehouse operations. Treat it as a useful framework, not a universal standard.

The paper includes a standalone digital twin at level 0, potentially before the physical asset exists. I retain that category while using levels 1–5 for operational twins. The capability descriptions below are paraphrased; the warehouse examples are mine.

Consider a warehouse preparing a batch of orders, called a wave, for dispatch. Workers, or pickers, collect items in different zones; orders are then packed and loaded before the trucks leave—the dispatch cutoff. Zone C has a growing queue and fewer pickers logged in than planned. Should the manager move two workers from zone A, and what would that cost elsewhere? The example and its figures are illustrative.

Is, is wrong, may happen, should do, has acted: these phrases help readers remember the levels. Classification depends on what the system does, not its grammatical tense. A past-tense report could describe a human decision. At level 5, the system acts without requiring approval for each action, within authorised operating limits.

Synchronised with what?

Operational data can come from sensor readings, scans, business system transactions or human input. For this warehouse decision, the model also needs to represent the wave as a distinct record with its own identity, plan and history. That lets the team compare tonight's progress with tonight's commitments.

A simplified progression is planned → released → picking → packing → staged → dispatched. Items are boxed at packing benches, wait in staging lanes, and leave through loading bays. In practice, these stages overlap, pause and repeat.

Three modelling rules make the representation useful.

Keep the schedule separate from each occurrence. The evening wave runs nightly, but tonight's wave has its own orders, staffing plan and outcome. Keeping those records separate lets you compare tonight with last night.

Finished is not gone. Picking can be complete while pallets still occupy staging lanes. A loaded trailer can still block a loading bay while awaiting paperwork. Record when each resource becomes occupied and when it is released. A single current-status field cannot recover that duration; two timestamps can describe each occupancy interval. Measure it before deciding how much is avoidable.

Store the forecast with its issue time. Save when a forecast was made, what event it predicted, and the eventual outcome. A prediction of when picking finishes is different from one of when the wave is loaded. Without the issue time, you cannot judge how useful either forecast was when someone had to decide.

Grade features, not just products

A single product-level score hides differences between features. "Mostly descriptive and diagnostic, with one validated forecasting feature" tells a buyer more than "level 3" alone.

Define the system being assessed. A screen that displays a conveyor controller's diagnosis is descriptive as a display. An integrated system that includes the controller can have diagnostic capability. Identify where the capability is performed and which components the assessment includes.

Score capability and usability separately. A validated forecast displayed as a plain timestamp remains predictive, even if the interface fails to highlight a missed cutoff. A dashboard can also display prescriptions. Presentation affects usefulness, but does not determine the capability level.

Builders should distinguish improving existing capabilities from adding new ones. More descriptive features can be valuable without adding prediction or prescription.

From a finding to a recommendation

A useful diagnosis separates measurements, interpretation and verification:

• We observe… zone C's queue is growing, and fewer pickers than planned are logged in.
• We infer… staffing may be limiting throughput.
• We would check… actual attendance, work allocation, task difficulty, equipment availability and recent pick confirmations.

A login count alone does not establish who is working or why throughput is low. A diagnosis can identify a likely problem without proving its root cause.

A recommendation goes further: it compares the current plan with feasible alternatives over the same period. Before moving workers, check that they are qualified for the work, that zone A can release them, and that packing and loading can handle the extra output. Otherwise, faster picking may simply move the queue downstream.

The recommendation should state the action, expected outcome, uncertainty and effects elsewhere. Here, it should compare keeping the current staffing with moving two pickers, including the effect on zone A's next wave.

If it includes a confidence figure, name the event. "The wave makes the cutoff," "we recover at least an hour" and "this is the best available option" are different claims. A bare percentage leaves the reader guessing.

Prescriptive capability is not the first point at which value appears. Better visibility and faster diagnosis can already save time and improve decisions. The appropriate level depends on the problem worth solving.

Testing a twin claim

Start with the connection: "Show me a value changing because the operation changed." Trace a pick-count update back to a scan. Scripted demo data can imitate movement; animation alone is not evidence of operational synchronisation. A forecast or what-if simulation may legitimately evolve while the physical system remains still.

Then ask for evidence of the claimed capability:

A verified update establishes a data link, not diagnostic or predictive capability. Likewise, issuing a command does not prove that the intended operational change happened.

Ask separately whether people followed a recommendation and what happened afterwards. Those questions address adoption and results. A recommendation remains prescriptive when an operator declines it; assessing its benefit requires comparison with what would otherwise have happened.

What builders need at each level

The ladder also helps identify engineering work:

• 0 → 1: a suitable data connection, matching events to the right assets or work records, current-state handling and trustworthy timestamps.
• 1 → 2: rules or models that evaluate conditions, with findings someone can inspect.
• 2 → 3: forecasting models and historical outcomes against which to validate them.
• 3 → 4: a way to compare feasible actions under constraints, often through simulation or optimisation, with uncertainty and risk considered.
• 4 → 5: authorised control interfaces, operating limits, interlocks, audit records, feedback and a safe way to stop or reverse an intervention where possible.

What to take into the next demo

Ask what the model represents, how it stays aligned with the operation, and what evidence supports each claimed capability. For recommendations, examine the alternatives and consequences. For autonomous actions, inspect authority and feedback. Choose the capabilities that help your team make and carry out better decisions.