What problem does a digital twin actually solve, and when is it over-engineering?

What it is

A maintained model of a physical asset's state and behaviour, updated from its telemetry, usable for querying, simulation and prediction without touching the asset itself.

What it genuinely solves

• A queryable current state for assets that report intermittently, so consumers get a coherent answer rather than each interpreting raw telemetry themselves.
• Simulation before action — testing a configuration change or an operating scenario against the model rather than the equipment.
• Prediction from history, such as remaining useful life and maintenance scheduling.
• A stable interface decoupling consumers from device protocols and firmware versions, which for a heterogeneous fleet is frequently the largest practical benefit.
• Behaviour comparison, where deviation between the model's expectation and reality is itself the fault signal.

When it is over-engineering

• When the fleet is homogeneous and simple. A state row per device serves the same purpose without the vocabulary.
• When nothing simulates or predicts. Without those, the twin is a state store with a more impressive name and a higher maintenance burden.
• When the physics is not understood well enough to model, in which case the twin encodes assumptions and produces confident wrong answers — worse than no model.
• When telemetry is too sparse to keep the model current, so it diverges from reality and is quietly distrusted.

The property that determines success

Explicit staleness. A twin presenting a model-derived state as current, when the underlying device has not reported for hours, is actively misleading — it looks authoritative precisely where it is least reliable.

Every twin value needs an as-of timestamp and a confidence indicator, and consumers need a defined behaviour for stale values. This is the difference between a useful abstraction and a system that generates confident nonsense.