Twins that stay true to the world

01A twin is a promise

A digital twin couples computational models with a physical counterpart, and the coupling is what separates it from an ordinary model or a three-dimensional drawing¹.

Digital twin technology creates electronic representations of real-world entities, along with the ability to view the states of those entities and the transitions between them².

That makes a twin a promise. It claims that what a user sees on the screen is what is happening, or about to happen, in the world outside.

The promise holds only while the twin is fed. A model of a river, a grid or a building drifts from reality as soon as the observations that steer it stop arriving or stop being right.

Observing sites are what keep that promise. Weather stations, gauges, radars and cameras supply the live state, and their quality decides how far the twin can be trusted.

Three properties tell a user whether a twin is still true: how fresh its data is, where each value came from, and how well its outputs have matched independent observations.

None of them is visible in a polished rendering. A twin can look convincing long after it has stopped being right, which is why these properties must be shown to users rather than kept in a log behind the scenes.

A twin is also only as wide as its observations. Parts of the world that no instrument sees are filled by assumption, and a true twin marks those parts clearly instead of drawing them with the same confidence as the rest.

02Freshness: how old is the twin's view?

Every value in a twin has an age. A river level measured a minute ago and one measured yesterday may look identical on a screen, yet only one of them describes the river now.

A twin that stays true shows that age everywhere. Each element carries the time of its last observation, and the twin marks anything older than its purpose allows.

Large twins of the Earth system make the same point at scale. Their forecasts start from initial conditions that combine a previous short forecast with around 60 million quality-controlled observations³.

Those conditions are renewed every six hours, so the model never runs for long on its own assumptions before observations pull it back toward the world³.

Smaller twins need the same discipline. When a feed stops, the twin should say so, fall back to a model estimate with a widening uncertainty, and never present a stale value as current.

Freshness limits depend on the purpose. A twin used to plan maintenance may tolerate data a day old, while a twin used to operate flood gates may need readings from the last few minutes. The same input can be fresh for one use and stale for another.

03Provenance: where each value came from

A twin blends many sources: live observations, archives, models and the judgements of the people who built it. When a value looks wrong, a user needs to trace it back.

Provenance makes that possible. An open ontology for provenance provides classes and properties to represent and exchange information about how data was produced, across different systems and contexts⁴.

In a twin, each value can point to the observation behind it, the instrument and its calibration, the processing that changed it and the version of the model that used it.

Open sensor data standards help at the start of that chain, because observations arrive with their sensor, time and location already described in a common form⁵.

Provenance also protects the twin from itself. Outputs of the twin should never be fed back as if they were observations, and a clear record of origin is what prevents that loop.

Provenance also makes corrections possible. When an instrument is found to have drifted, every value it touched in the twin can be found and marked, instead of the error quietly spreading through later results.

04Validation: checking the twin against the world

Freshness and provenance say what went into a twin. Validation asks whether what comes out matches the world, which is the test that finally counts.

A review of foundational research for digital twins asked what is needed for their verification, validation and uncertainty quantification, and how those needs vary between communities¹.

In practice, validation keeps some observations independent. A twin is steered by one set of instruments and checked against another, so that agreement means something.

The results should be published with the twin, for each kind of output: how often it matched, by how much it missed, and under which conditions it was weakest.

Validation never ends. Each new season, sensor or model version can change how well the twin performs, so the checks run continuously alongside it.

Validation also tells users where not to rely on the twin. A flood twin that performs well on large rivers but poorly on small streams should say so plainly, so nobody uses it beyond what the evidence supports.

Uncertainty is part of the answer, not a flaw in it. A twin that shows a range instead of a single line is more honest, and usually more useful, than one that hides its doubt.

05Twins at the scale of the planet

The largest twins being built today describe the Earth itself. Destination Earth is an initiative of the European Union to create a digital model of Earth to monitor natural and human effects, anticipate extremes and adapt policy⁶.

Its design separates the parts that keep a twin true. A data lake brings together observations from satellites and many other sources, a platform serves users, and a twin engine runs the models⁷.

Its initial twins address weather-induced extremes and climate change adaptation, combining high-resolution forecasts and on-demand simulations with long simulations of the decades ahead⁷.

Machine learning is entering the same field. An operational forecasting system based on machine learning now runs side by side with a physics-based one, starting from the same observation-based initial conditions³.

Local twins of a site, a river or a district can borrow the same discipline: keep data, models and services distinct, and let observation steer every one of them.

Scale changes the numbers but not the principles. Whether a twin covers a pump station or a continent, it is only as current as its freshest observation and only as trustworthy as its last validation.

06Security, trust and a twin that stays true

A twin that only displays the world is a window. A twin that can command valves, switches or vehicles is part of the control system, and it carries that system's risks.

Guidance on digital twin technology discusses both traditional and novel cybersecurity challenges, together with trust considerations in the context of existing security guidance².

A false observation is one of the most direct threats. If an attacker or a faulty sensor can feed the twin a wrong state, every decision based on it inherits the error.

The defences follow from the earlier sections. Fresh data with known age, provenance back to authenticated instruments and continuous validation against independent sensors all make a false state easier to spot and reject.

Design the twin around its observations from the start. Decide which instruments steer it, which ones check it, how stale each input may become and what the twin shows when it no longer knows.

Give people a way to question it. Operators should be able to see, for any value, its age, its origin and its recent validation, and to report when the twin disagrees with what they see on the ground.

Nexus Observatory Inc. designs observing sites and data services that can feed digital twins, with each value carrying its time, origin and quality so the twin can stay true to the world.