A digital twin is only as safe as its last update
Fed stale P&IDs and drifted parameters, a twin gives confident wrong answers, and the data upkeep is the cost the demo hides.
A digital twin of a process unit is a genuinely useful idea: a live model you can interrogate and use to reason about hazards before they arrive. The demo is compelling because the twin answers instantly and confidently. What the demo never shows is the second act, the unglamorous work of keeping the model married to the plant. That work is the actual product.
Currency is a safety property
A twin reasons from its inputs: P&IDs, equipment parameters, control logic, protective-layer configurations. Plants drift. A P&ID revision lags a field change by months; a relief-valve setpoint is adjusted and the model doesn’t hear about it. Now the twin isn’t just less accurate, it’s confidently wrong, wearing the authority of a computed answer. If you use a twin to reason about safeguards, you’ve made data currency a safety attribute. IEC 61511-1:2016, the functional-safety standard for safety instrumented systems, is built on a lifecycle discipline: verify, manage change, and maintain the integrity of what the protective layer depends on across its whole life, not just at commissioning. A twin that informs those decisions inherits that obligation.
The economics follow. The visible cost is the model build. The real cost is a standing maintenance burden: someone owns synchronisation, someone reconciles the twin against field reality on a cadence, someone flags when it’s stale enough to distrust. Skip that and you’ve bought a persuasive way to be wrong.
Three layers drift, and they drift at different speeds
“Is the twin current” is not one question. It is three, and a site can be excellent at one while blind on the others.
Topology is the plant as drawn: lines, vessels, valves, what connects to what. It changes rarely and it changes through management of change, so it is the layer most likely to be governed. It is also the layer where the lag is longest, because a redlined P&ID can sit months behind the steel.
Parameters are the numbers: setpoints, trip points, alarm limits, relief sizing, control ranges. These move far more often than topology and frequently through routes that never touch a drawing. An operator raises a limit to stop nuisance trips. A trip point is adjusted during commissioning of an adjacent unit. Nothing in that path notifies a model.
Logic is the behaviour: interlocks, permissives, sequences, bypass conditions. This drifts through controls work, vendor updates, and temporary jumpers, and it is the layer a twin most needs to be right about, because it is what determines whether a protective action actually fires.
Ask which of the three your twin reconciles automatically and which depend on a person remembering. The answer is usually that topology is governed, parameters are hoped for, and logic is assumed.
A twin has no fail-safe state
Here is the property that separates this from ordinary data-quality housekeeping, and it is the reason to treat it as a safety concern rather than an IT one.
A field instrument that loses confidence in itself can be designed to fail in a known direction. It goes out of range, it drives the loop to a safe state, it raises a diagnostic. The failure announces itself.
A stale model does none of that. It does not know it is stale. Asked what happens on loss of cooling, it returns a smooth, plausible, precisely formatted answer computed from a plant that no longer exists. There is no out-of-range condition, no diagnostic, no visible degradation. The output looks identical whether the model matched the plant this morning or last year, which means the one thing a twin cannot do unaided is warn you not to trust it.
So the safeguard has to be procedural, and it should be visible on the interface rather than buried in a governance document. Every screen that a twin uses to answer a safety question should carry the date it was last reconciled against the plant, the same way a calibrated instrument carries a sticker. Past a defined threshold, it should refuse to be the basis for a safeguard decision at all.
Before you buy
Ask the vendor and watch how fast they answer: when a field change is made, what is the defined process and maximum time lag before the twin reflects it, and who is accountable for that update? If the answer is vague or "it updates automatically," you're buying stale answers delivered with confidence.
What to write into the contract
Treat a twin like any protective assumption: trustworthy only if someone is on the hook for keeping it true. The diligence question isn’t “how smart is the model”, it’s “how do you know it still matches the plant this morning.”
Three clauses make that answerable. A named owner for synchronisation on your side, not the vendor’s, because the changes originate in your plant. A stated maximum staleness for each of the three layers, with the tightest bound on logic. And a reconciliation record you can produce in an audit, showing when the model was last checked against field reality and what was found.
If nobody will sign up to those, that tells you what the twin is. A very good visualisation, and not a basis for deciding whether a safeguard will hold.