The Twin That Never Fails: Why UK Asset Owners Are Buying Reassurance Instead of Answers
There is a slide that appears in almost every digital twin business case put in front of a UK asset owner. It shows a plant, a bridge or a water treatment works rotating slowly in isometric view, dotted with live sensor tags and a tasteful gradient. It is expensive, it is polished, and it is almost entirely decorative.
That is not a criticism of the technology. Simulation and model-based engineering are among the most valuable capabilities available to anyone running ageing infrastructure. The criticism is of a procurement culture that has learned to buy the picture and skip the mathematics underneath it. Across water companies heading into the back half of the AMP8 investment period, energy networks, local authority estates and transport bodies, the pattern repeats: a twin is commissioned as a showcase, demonstrated to a board, and then quietly abandoned when nobody can say which decision it changed.
A market shaped by what funders can see
Digital twins are unusually easy to justify on a funding application and unusually hard to justify on a balance sheet. A visual model photographs well. It appears in annual reports. It satisfies the understandable appetite of non-executive directors for something tangible to point at. Validation, by contrast, produces a document nobody frames.
So the scoring criteria drift. Procurement exercises reward interoperability standards, data ingestion breadth, rendering fidelity and cloud architecture. All of these matter, and none of them tell you whether the model is right. A twin can be beautifully engineered, fully compliant with information management frameworks, and still be wrong about the thing you care about.
There is a second distortion. Twin platforms are frequently sold as a capability rather than a deliverable — a licence, a workspace, an ecosystem. That model suits vendors and IT departments, but it quietly transfers the burden of defining purpose onto the buyer. Asset owners who cannot articulate the specific decision a twin will improve will end up with a general-purpose environment that improves none of them.
The discipline nobody budgets for
In structural engineering, no one accepts a finite element model without calibration against measured behaviour. In safety-critical control, no one accepts a simulation without a validation trail. Digital twins of complex assets routinely enter service with neither.
The gap is partly technical and partly contractual. Genuine validation requires a back-test: take eighteen to twenty-four months of asset history, hide it from the model, run the twin forward, and compare predictions with what actually happened, including the near-misses. It requires stated error bounds and a documented account of where the model is known to be weak. It requires someone with the authority to say the twin is not fit for a particular use.
Almost none of this appears in a standard scope of works, because it lengthens delivery, exposes the vendor, and creates a finding that the client then has to act on. It is cheaper, in the short term, to accept a model that looks plausible.
Why failure is the hardest thing to model
A twin trained on steady-state operation learns normal. It learns that a pump runs at a certain vibration, that a substation load follows a familiar daily curve, that a bridge deflects by a predictable amount under a predictable axle count. Feed it a year of healthy data and it will become an extremely confident description of a healthy asset.
Failure is different. Failures are rare, sparse and often compound. The events that matter — the cascade, the sensor that drifts before the valve sticks, the storm that arrives with a maintenance backlog — are precisely the events for which you have the least training data. A model that cannot be deliberately perturbed is not a twin of your asset; it is a twin of your asset on a good day.
Fault injection is therefore not an advanced feature. It is the feature. It means asking whether the twin can be driven into degraded states on purpose: tags gone stale, latency introduced, a subsystem isolated, a control loop mis-tuned. It means testing the model's behaviour when its inputs are wrong, not only when they are clean. It also means confronting the organisational reason failure modes get quietly dropped from scope — a simulation of a credible failure implicates maintenance regimes, staffing levels and capital deferral decisions, and those findings have owners with an interest in not receiving them.
Five questions before the next signature
Any engineering leader about to commit to another twin contract can test the proposal with a short list.
- Which named decision will this model change, and what does that decision cost today when it is made badly?
- Can the supplier show a blind back-test against historical asset data, with error bounds and known weak points stated in writing?
- What is the model's behaviour when a third of its inputs are missing, delayed or drifting?
- Who owns the model artefact, and can it be exported and run by a different supplier without re-buying the data layer?
- What is the false negative rate on the failure mode that appears highest on the asset risk register?
A supplier who can answer all five is selling a decision engine. A supplier who can answer only the first three is selling a dashboard with ambitions.
Start from the failure, not the geometry
The constructive version of this argument is straightforward. Do not scope a twin of an asset. Scope a twin of three credible failure modes drawn from the asset register, the hazard study and the maintenance history, and build the smallest model capable of discriminating between them. Add geometry only where it earns its place.
That approach is less impressive in a board pack and considerably more useful at three in the morning when a control room needs to know whether to isolate a line. The twin is a hypothesis about how an asset behaves. Treating it as one — testable, falsifiable, bounded — is the difference between an engineering tool and an expensive screensaver.
