The Global Centre for Risk and Innovation (GCRI)
A digital twin is a model of a real system that is continuously updated with data from it, used to monitor, predict and test decisions. Twins of cities, grids, water networks and factories are widely proposed, and many are dashboards or static models under a new name. This page sets out what makes a digital twin, how twins are built and validated, and what evidence serves the institutions considering them.
GCRI · In development · service level R0
Digital twins are models of real systems that are continuously updated with data from them and used to monitor, predict and test decisions. They depend on reliable data flows, validated underlying models and feedback from decisions, and connecting models to live data raises security and accountability questions.
For digital twins: method and limits, in GCRI's spatial-intelligence reading, the map opens on night lights, true-colour imagery and population density with relief in 3D and true colour from NASA GIBS, framed on North America; every other NASA layer, live feed and forecast waits in the layer list.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 3
Connected activity, for this page
Keyboard, with the map focused
Hold Ctrl or ⌘ and scroll to zoom
Latest available
NASA GIBS / EOSDIS · ASTER GDEM (METI, NASA) · Blue Marble (NASA) · © OpenStreetMap contributors (ODbL) · Natural Earth
Loading the latest NASA imagery.
Drag to move. Ctrl or ⌘ and scroll, pinch or the buttons to zoom; hover for the values under the pointer; reset returns to the region.
For digital twins: method and limits, in GCRI's spatial-intelligence reading, the map opens on night lights, true-colour imagery and population density with relief in 3D and true colour from NASA GIBS, framed on North America; every other NASA layer, live feed and forecast waits in the layer list.Satellite and model products as NASA publishes them, each with its own date; indicators, not assessments of any place; claim ceiling INTEGRATED.
Layers and dates
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
Digital twins: method and limits · Coupled model A · Scenario set 3
nodes: models · edges: exchanged variables
| Hydrology | 1 day | runoff | Yes |
| Power system | 1 h | demand, outages | Yes |
| Economy | 1 quarter | output, prices | Partial |
| Population | 1 year | exposure | Yes |
What a twin can and cannot represent, and how it is kept honest. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
A twin assimilates sensor and operational data so that its state tracks the real system, which needs reliable data flows and quality control.
A twin is only as good as its underlying models. Visualisation without validated models is a dashboard, not a twin.
Twins add value when used to test options and inform action, and when outcomes are fed back to improve the model.
Connecting models to live data and to controls raises cybersecurity, data protection and accountability questions.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Data assimilation | Combining model forecasts with observations to estimate a system's current state. |
| State estimation | Estimating the current values of a system's variables from models and measurements. |
| Physical counterpart | The real system that a digital twin represents and is synchronised with. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Data latency from system to twin | minutes | continuous | Data pipeline monitoring | OBSERVED |
| State estimation error | error metric | per evaluation | Validation against measurements | ESTIMATED |
| Decisions informed by the twin | count | per period | Decision records | REPORTED |
| Sensor coverage of the system | percent of key variables measured | per assessment | Sensor inventory | DECLARED |
| Model components validated | percent | per assessment | Validation records | REPORTED |
| Security assessments completed | count | per assessment | Security records | REPORTED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| ISO 23247 digital twin framework | Reference architecture for manufacturing digital twins | Licensed standard, purchase required |
| Digital Twin Consortium definitions and resources | Industry definitions and capability frameworks | Public, terms to check |
| National academies reports on digital twins | Assessment of foundational research gaps | Public, terms per publisher |
| Data assimilation literature | Methods for combining models and observations | Licence per publication |
| Published city and utility digital twin case studies | Applied twins and lessons | Licence per publication |
Systems Science and Modelling prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Operators and city authorities | Whether a digital twin is worth building and for which decisions | Capability assessments |
| Engineering teams | How to validate and secure a twin | Validation designs; architecture reviews |
| Procurement bodies | How to distinguish twins from dashboards in tenders | Capability criteria |
A twin combines models with live or regularly updated data. Data assimilation adjusts the model state to match observations, which can make short-term predictions more accurate. Twins are useful for monitoring, testing interventions virtually and training operators.
A twin is still a model. It represents only the processes and components that were built into it, at the resolution chosen, and it inherits the uncertainties and assumptions of its components. Visual realism can create an impression of completeness that the underlying model does not justify.
Twins can drift. As the real system changes, through new construction, ageing or changing behaviour, the twin must be updated and revalidated. A twin that is not maintained becomes a misleading picture.
Combining model predictions with observations, using statistical methods. Requires good observation coverage.
Testing the twin against independent data for each intended use, using uncertainty quantification.
Defining scope, interfaces and requirements, using systems engineering.
Running and updating twins, using computing. Costs and security must be managed.
A digital twin is a representation, not reality. Its outputs carry the uncertainty of its models and data, and they are shown with that uncertainty.
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.