"Digital twin" has ended up in the same bucket as "immersive experience": it gets used for any 3D model with a logo on it. We have seen recorded fly-throughs presented as twins. Those are videos.
The test we use is blunt and it works: what can I change, and what does the system tell me back? If the answer is "nothing", it is visualisation. As useful as you like, but a different product, priced and valued differently.
Looking and trying are two different products
A navigable model is a visit. You go in, you look, you leave. That is perfectly fine for selling an apartment or telling the story of a heritage site, and it is often exactly what is needed.
A twin is a test bench. It has a state that changes, it receives data from outside, and it reacts to an action that alters the outcome. All three, not just one.
Worth settling before you commission anything, because it changes everything: the budget, who works on it, what gets delivered, and above all who has to keep it running afterwards.
Data in, decisions out
The part almost no tender specifies is the flow.
Incoming you need a declared source: field sensors, a simulation, a BIM model, an ERP. And a frequency: real time, nightly, at every design revision. A twin fed once is a photograph in 3D.
Outgoing you need something that survives the session. An export, a report, a saved configuration, a comparison between two scenarios. If an hour of work inside the model leaves no file behind, the decision taken in there is not traceable, and in most organisations an untraceable decision is a decision that was never made.
That is what separates a tool from a demo. Demos end when you take the headset off.
Copenhagen: place a barrier, watch where the water goes
The European Space Agency's ImmerseOn programme wanted to check something specific: whether putting satellite data and immersive visualisation together helped cities prepare for climate events. The question was not "does it look good?", it was "do people decide better?".
We built a Unity VR application on our Explore platform that rebuilds part of Copenhagen at 1:1 scale from geographic data and aerial imagery. The flooding scenarios (storm surges, sea level rise for 2050 and 2100, rainfall accumulation) are computed on ESA's servers; the application receives them as water height maps over a REST API, in JSON, and turns them into a surface that rises as the simulation advances.
So far this is visualisation. Carefully made, but visualisation. The jump comes next.
The user places virtual barriers, dikes, embankments, floodgates, and the simulation recalculates where the water ends up. Scenarios with and without the intervention sit side by side. Several people can share the environment and argue while watching the same street flood; sessions are recorded and configurations exported for engineering analysis.
From "here is what will happen" to "let's try what happens if". That is the whole difference.
A note on the 1:1 scale, which looks like an aesthetic detail and is not. A coloured map tells you there will be fifty centimetres of water in that street. Standing in that street in fifty centimetres of water is a different piece of information, and the people who have to approve a multi-million investment receive it differently. This is not about emotion: it is about seeing where the level lands relative to a doorstep, an electrical cabinet, a garage ramp.
Seven requirements for a twin that gets used
This is the list we pull out when someone asks us for a digital twin, before any talk of technology.
- A state that changes. If the scene is always the same, it is a model.
- An input the user controls. Place, move, replace, switch on. Something that is a choice, not a display preference.
- A declared data source, with its update frequency written down.
- An output that survives the session. Export, report, configuration, comparison.
- A recognisable context. Real scale and real landmarks: they are what lets people orient themselves and trust what they see.
- Performance. In VR, below a certain frame rate people take the headset off and nothing else matters. It is a functional requirement, not a finishing touch.
- Someone who maintains it. A name inside the organisation, not in the supplier's contract.
If three or four of these are missing, what you need is probably a good visualisation: it costs less, it ships sooner and nobody ends up disappointed.
The real cost is keeping it alive
Building a twin costs money. Keeping it aligned costs more, and hardly anyone budgets for it.
The data source changes format. The plant gets modified and the model does not. The person who knew how it worked moves on. A year later the twin shows a state that no longer exists, somebody notices during a meeting, and from then on nobody opens it again. That is how these projects usually die: not with an error, with quiet obsolescence.
Two countermeasures, both organisational rather than technical. Decide up front who updates it and how often. And start small: one department, one building, one district. A narrow twin that is up to date beats a complete twin frozen at handover every time.
One question that sorts it out in five minutes
When someone asks us for a digital twin, our first question is: which decision do you want to make by looking at it, and who makes it?
If the answer comes back quickly and contains a name and a choice, where we put the barriers, which line layout we build, in what order we do maintenance, then the project makes sense and we know what to build. If the answer is "show clients how advanced we are", that is a different job, one we are happy to do and that costs a great deal less.
If nobody can prove your twin wrong, it probably is not helping anyone decide.
We build XR platforms and 3D software for industry, real estate and institutions: what System does, or tell us about your case and we will say whether a twin is what you need.