Three Myths About Digital Twins That Hide Their Most Valuable Use

Digital twins occupy an unusually slippery category. The term may describe a live representation of a turbine, a model of a warehouse, a simulation of a power network, or little more than a dashboard attached to sensor data. This elasticity makes the idea easy to promote and difficult to evaluate.

The useful question is not whether an organisation “has a twin.” It is whether a digital representation can improve a consequential decision: when to service equipment, how to reroute work, which configuration to test, or where a failure is likely to propagate.

Three familiar claims obscure that standard. Each contains a legitimate insight. None should be accepted without qualification.

First, define what must be twinned

A digital twin is best understood as an operational model of a specific entity or process, connected closely enough to reality to support observation, prediction, or intervention. That definition has four parts: an identifiable subject, a representation of its relevant state, a mechanism for updating that state, and a decision the representation helps someone make.

Not every twin needs continuous telemetry. Not every model needs simulation. Not every representation needs geometry. A maintenance twin may combine equipment identity, service history, operating hours, vibration features, and a failure model. A logistics twin may represent queues, routes, handling constraints, and order arrivals. Their interfaces and mathematics differ because their decisions differ.

This anatomy gives us a way to test the myths.

Myth one: A digital twin must be a perfect real-time replica

The image is compelling: every physical change is mirrored instantly in software, producing a complete and continuously faithful counterpart. For some systems, freshness genuinely matters. A grid operator responding to rapidly changing demand cannot rely on last month’s state. A manufacturing line balancing work across stations may need frequent updates to identify a developing bottleneck.

But “real time” is not an intrinsic virtue. It is a latency requirement imposed by a decision. If a building team adjusts ventilation schedules weekly, sub-second telemetry adds little decision value. If corrosion develops over months, daily updates may already exceed what the maintenance process can use.

Perfect fidelity is also impossible in practice. Sensors drift, packets disappear, assets are modified without records being updated, and important states remain unobservable. A twin is therefore an estimate assembled from measurements, assumptions, and models—not a flawless duplicate.

The worked example

Consider a pump maintained during planned shutdowns. Its twin receives operating hours each day, vibration summaries after each shift, and inspection findings whenever technicians open the unit. A live waveform stream might expose more detail, but it would also require greater storage, network capacity, signal processing, and monitoring. If maintenance decisions are reviewed every morning, shift-level summaries may preserve the relevant warning signals at far lower complexity.

The design principle is simple: match update frequency and fidelity to the shortest interval in which a different decision remains possible. Faster data is valuable only when someone—or some automated system—can act on it.

Myth two: The 3D model is the digital twin

Geometry is often the most visible component, so it becomes confused with the whole system. A detailed visual model can be indispensable when spatial relationships drive the problem. Technicians may need to locate a valve behind a panel. Engineers may need to detect clearance conflicts. A robot planner must understand obstacles and reachable space.

Yet many of the highest-value operational questions are not primarily visual. Will a bearing survive until the next service window? Which orders will miss their dispatch time? What happens to throughput if one station closes? A beautiful rendering does not answer these questions unless it is connected to state, behaviour, constraints, and outcomes.

The reverse is also true: a spreadsheet-like representation can qualify as a useful twin. A cold-chain operator could model each shipment through identity, location, temperature exposure, remaining journey, and spoilage risk. The interface might be a table of exceptions rather than a virtual warehouse. It is less cinematic, but more aligned with the decision.

The kernel of truth

Three-dimensional interfaces become powerful when they compress spatial complexity. They can provide a shared reference for engineers, operators, and field workers who otherwise use incompatible diagrams. They may also make historical or predicted states legible: where heat accumulated, how people moved, or which components sit downstream of a fault.

The error is beginning with the visual surface. Begin with the decision model, then ask whether geometry improves comprehension or action. If removing the 3D scene leaves the decision unchanged, it was probably presentation rather than core capability.

Myth three: Digital twins are only practical for large industrial enterprises

Large operators possess several advantages: instrumented assets, engineering teams, long-lived equipment, and failures costly enough to justify substantial modelling. Aerospace, energy, and advanced manufacturing are therefore natural homes for sophisticated twins. High setup costs are real when a programme requires custom sensors, detailed physics, systems integration, and continuous validation.

But this does not mean a twin must begin at enterprise scale. The expensive mistake is often scope, not category. Attempting to represent an entire factory, city, or supply chain creates an integration programme before it creates a useful decision.

A smaller organisation can begin with one bounded operational loop. A commercial greenhouse might represent a single growing zone using temperature, humidity, irrigation events, crop stage, and control settings. The first decision could be narrow: identify which climate setting is associated with recurring stress. That does not require a photorealistic facility or a universal agricultural model. It requires reliable records, a defensible relationship between inputs and outcomes, and a way to test an operational change.

Software-only systems also admit twins. A fulfilment operation can replay order arrivals against staffing rules. A data centre team can model workloads, capacity limits, and failover policies. The “physical” counterpart need not be one machine; it can be a process whose state and constraints are observable.

Where digital twin projects actually fail

The recurring dangers are quieter than inadequate graphics or insufficient sensor frequency. They concern ownership and evidence.

• No decision owner: The model produces alerts, but nobody has authority to change schedules, settings, or maintenance plans.
• No counterfactual: The system describes present conditions but cannot estimate what might happen under another action.
• No calibration loop: Predictions are never compared with inspections, failures, delays, or other observed outcomes.
• Unpriced false alarms: Every anomaly prompts attention, gradually teaching operators to ignore the system.
• Hidden data lineage: Users cannot tell whether a displayed state is measured, inferred, manually entered, or stale.
• Scope without boundaries: The team attempts a universal representation instead of defining which variables are relevant to one decision.

These failures reveal an important distinction. A monitoring system asks, “What is happening?” A useful twin can also ask, “What is likely to happen?” and, at greater maturity, “What would happen if we intervened?” The last question is where simulation and experimentation begin to convert representation into leverage.

A disciplined way to start

The smallest credible twin is not the smallest possible model. It is the smallest model capable of changing a real decision while exposing its uncertainty.

1. Name one decision. For example: whether to inspect a refrigeration unit before the next delivery cycle.
2. Set the decision horizon. Determine how early a warning must arrive to make inspection feasible.
3. List only decision-relevant state. This might include compressor runtime, temperature recovery after door openings, ambient conditions, and service history.
4. Choose the lightest sufficient model. Start with explicit thresholds or a degradation model before commissioning elaborate simulation.
5. Expose uncertainty and provenance. Operators should know which inputs are missing and why the system reached its assessment.
6. Record actions and outcomes. Without this feedback, the twin cannot be calibrated or economically evaluated.

Suppose the model flags slow temperature recovery. An operator inspects the unit and records a blocked condenser. That outcome strengthens the relationship between the observed pattern and the maintenance action. If inspection finds nothing, that matters equally: thresholds may be too sensitive, ambient conditions may be omitted, or the presumed mechanism may be wrong.

The revelation: the twin is a decision instrument

The mature opportunity is not to create a digital double of everything. It is to build a controlled environment in which reality can be observed, alternatives can be tested, and consequences can be learned before expensive action is taken.

This reframes the investment. Sensor coverage is chosen according to uncertainty. Update speed follows intervention speed. Visualisation follows the structure of the work. Simulation earns its place by making a counterfactual decision safer or clearer.

A digital twin becomes strategically interesting when it closes a loop: the model interprets the world, an operator or system acts, the outcome returns as evidence, and the representation improves. Without that loop, the twin is often an impressive mirror. With it, the organisation gains something rarer—a practical rehearsal space for reality.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.