Guidance

Digital Twin (official)

Published 29 October 2025

Overview

A digital twin is a digital representation of a real-world entity, environment or process that allows the inclusion of a 2-way communication (in some applications or subject areas, data and information could be considered interchangeable terms, data here should be understood in its broadest context and information as data with context) flow into and out of the real world in a timeframe that is appropriate for the required decisions and assumptions.

This means the digital twin mimics, in that timeframe and without statistical bias, its real-world counterpart in all relevant aspects within a validation envelope.

Here, bias is a statistical term. Without bias means that the parameters and outputs are represented by a distribution centred at the true value.

Given the complexity of a digital twin, in this context, the definition can be relaxed to a distribution containing the true value within a stated percentile, in other words there is no substantial over or underestimate even if the uncertainty is high.

A digital twin can be used to assess functionality, degradation and impact with a defined level of assurance.

We say that a digital twin is tied to its real-world counterpart.

Full definition

A digital twin must be tied to a real-world process, environment or object, to a known tolerance and perform without statistical bias. It must predict what the associated real-world entity would do given a stimulus. Together with the necessary requirements specified below and a common set of exchange protocols, this ensures digital twins are fully composable with other digital twins. It also provides a known level of assurance in any situation within a specified validation and assumption envelopes, including after integration with other digital twins. This ensures digital twins can be used for test and evaluation and safety case development. A digital twin can be in one of the 3 states defined below.

A digital twin can be in one of the following states at a point in time:

  • connected: if it is currently being fed with data from the real-world counterpart
  • semi-connected: if it is fed with simulated data but contains at least one real-world data feed - semi-connected twins can be used to assess the impact of potential future changes on the digital twin and its real-world counterpart
  • disconnected: if it mimics the physical counterpart up to the point at which is disconnected, but is currently being run using only simulated data and is ready to be ‘twinned’ or reconnected with its physical counterpart

A digital twin may move between these states and remain a digital twin, provided its current state is recorded (see figure 1). A disconnected digital twin can only return to being a connected digital twin if the reconnection occurs within a timeframe in which it will still accurately mimic its real-world counterpart.

A digital twin must also be independent of the physical system, except for the input of data streams into the digital twin; the physical entity must maintain safe functionality even without a continuous connection to the twin.

The communication flow to the twin will usually be of sensed data; the flow from the twin will be of decisions that can be used to change the behaviour of the real-world system or to provide information about future performance and behaviour. A digital twin can therefore inform a control system for the real-world counterpart, but not be an integral part (the control system may not function optimally or fully without a connection to the digital twin, but must function safely) of that control system.

Consider a building digital twin: a digital control system will monitor the temperature inside the building and adjust windows and air conditioning to maintain a fixed temperature. This control system must function irrespective of the presence of the building’s digital twin. The control system is in effect ‘reproduced’ within the digital twin along with characteristics of the building outside of the control system.

In these circumstances the digital twin could provide data to inform the building control system of the state it should be running in.

Figure 1: illustration of the required and potential data flows between the real world and the states of a digital twin. Here the semi-connected and disconnected digital twins would be branched (copied) from the connected digital twin and run to answer 'what-if' analysis. Following these analyses digital twins in this state could be retired or merged with the ongoing connected twin. Two digital twins can be composed together to allow data flow between them, without necessarily changing the state of the individual twins.

Necessary requirements

A digital twin, as defined above, must:

  • mimic its real-world counterpart to a known and unbiased level of tolerance
  • have a specified validation envelope
  • have an associated assumption set
  • run in a timeframe that is appropriate for the required decisions and assumptions
  • be based on physical parameters and specifications
  • be associated with a single known physical entity
  • allow a 2-way data flow into and out of the real world

These requirements are further defined below.

Mimic its real-world counterpart to a known and unbiased level of tolerance

A digital twin must reliably mimic its real-world counterpart in every way known to be relevant to the use case it has been designed for.

Digital twins of the same object must also be consistent; if there are multiple use cases and digital twins, the relevant digital twins could be integrated into a single, or federated set of, more functional twin(s).

A statistical, data or simulation-based model can be a digital twin only if it has been trained specifically on a physics-based (or theory-based) representation of the entity with a known and unbiased level of uncertainty, or if it has been trained using the real-world data provided by the specific physical counterpart. A physics-based model can only be a digital twin if it is associated with a known tolerance and fidelity.

Have a specified validation envelope

A digital twin will only mimic its physical counterpart within known validation windows.

For instance, if the twin is a physics-based model trained on data within a known temperature range there can be confidence within that temperature range. Outside of that range there will be a point at which the physics and data changes and the digital twin will no longer be valid.

To meet the criteria of a digital twin the validation envelope over all relevant parameters must be specified and associated with the digital twin and taken into consideration in ‘what-if’ questions. If the real-world object must unexpectedly operate outside of the validation range, an immediate re-assessment of the digital twin should be undertaken.

Have an associated assumption set

Even within the validation envelope the digital twin will only reflect specific characteristics of the physical entity. It may reflect size, shape, weight, motion and temperature for instance, but not model the effect of an external force.

Consider a digital twin of a car brake system: the digital twin could be classed as such without the ability to model the change to the physical system resulting from a collision with another car, providing that this is captured in the linked assumption set.

Run in a timeframe that is appropriate for the required decisions and assumptions

A digital twin must run in a timeframe that allows it to be run synchronously with its physical counterpart.

This can either be achieved if the 2-way communication flow into and out of the real world is appropriate for the required decisions and assumptions–in other words in a timeframe that allows the digital twin to be updated so it remains sufficiently aligned with the real-world object. For example, if a manufacturing plant runs on a 24-hour schedule with 8 non-production hours, the twin must be capable of updating to current status within that 24-hour window.

Equally, an aircraft engine digital twin must be capable of running to the current status of the physical entity after landing and before the status is next updated. If the digital twin is to be run in order to evaluate ‘what-if’ scenarios in a semi-connected or disconnected state, the twin may further be required to run in faster than real time, however, this capability is not a requirement to meet the definition.

Be based on physical parameters and specifications

A digital twin must represent real-world limitations and specifications within its validation envelope.

Where a digital twin has been developed for a new design of a physical entity, it cannot contain components or properties that cannot be replicated in the real world.

For example, a digital twin would not contain models of metals with properties that cannot be produced in reality. In order to analyse the impact of idealised properties, a digital twin would need to be used with a separate model or simulation.

Be associated with a single known physical entity and allow a 2-way data flow into and out of the real world

In order to generate digital twins of physical entities there will likely be a ‘template’ digital twin for each type of real-world counterpart to be twinned, this template must allow for a 2-way data flow into and out of the real world.

Consider the digital twin of a specific car type for example, every car manufactured will have a unique digital twin instance associated with it and, upon association, the digital twin will be deemed connected. Prior to the manufacture of the physical entity, a running digital twin instance that meets all the above criteria and allows for but does not yet have a 2-way data flow, is termed ‘disconnected’.

Similarly, a connected digital twin that has been severed from the real-world entity and fed from a simulation environment to assess performance would also be termed ‘disconnected’.

A digital twin with a mix of real-world and simulated inputs would be termed ‘semi-connected’.

Consider a digital twin that is dependent on both ambient temperature and external vibration. If the current ambient temperature was still drawn from the real world, but the vibration level was simulated using a model to understand the impact of stress on the real-world object, this would be deemed ‘semi-connected’.

Application areas

Digital twins of assets and capabilities

This area encapsulates component, platform, system and manufacturing (factory) digital twins.

The existence of digital twins of individual components within different industry partners which need to be integrated at the platform level poses a significant challenge, but is proven technology in industry.

However, even in this most well-known sector there are complications driven by the multi-fidelity requirement of digital twins and the need for assured, outputs in an appropriate timeframe.

Digital twins of environments

This area encapsulates infrastructure, transport, manufacturing, environment and mega-structure digital twins. A mega-structure is defined as a complex amalgamation (or ecosystem) of both component, platform, infrastructure and environment twins such as would be found in an urban environment.

This requires complex multi-fidelity twins with real time inputs to ensure accurate representation of an environment and the ability to output to infrastructure in that environment.

This is currently unproven technology with substantial open research and technological challenges.

Digital twins of humans

A true complete digital twin of a human is currently impossible.

Instead, initial efforts are focussing on digital twins of aspects of a human, such as a human heart for example, which provide substantial benefit in their own right. Digital twins of human organs or body structure for example, give huge benefits for medicine and equipment design.

However, even at this level, linking such a physical digital twin to a modelling framework that could output the forces exerted by a body on surroundings or clothing is not yet possible.

Layering a digital representation of the health of the individual over the physical twin is currently intractable but potentially achievable, however, layering a psychological twin over that, means that the single human digital twin becomes currently intractable and ethically challenging.

Threats and security of digital twins

There are complex ethical and security implications associated with digital twins that should be considered, although it is important that the security considerations are proportionate to the particular use case.

The risk of an adversary gaining access to and potentially having an adverse effect on digital twins is not yet clearly understood or defined.

Furthermore, assurance that the digital twins are both representative and error free at time of use will be critical for maintaining capability and safety. The large scale passing of data for maintenance and analysis is crucial to maximise the benefits of digital twins however, the best methods to secure this data are not currently understood or captured in policy and guidance.

The impact of digital twins of humans on healthcare, finance and data autonomy are not well understood and therefore the ethical implications are difficult to determine.