A digital twin is only as safe as its last update

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.

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.”