Digital Twins
Digital Twin (a synchronised virtual representation of a process, asset, or facility)
A digital twin is a model of a process, asset, or facility that is kept synchronised with its physical counterpart through live or regularly refreshed data. The class spans a spectrum: at one end, mechanistic or statistical process models used offline for development and investigation; at the other, continuously updated representations that estimate unmeasurable states, predict trajectories, and feed model-predictive control. What distinguishes a twin from a simulation is the connection — a twin is fed by the plant it represents, usually from the historian and control layer, and drifts out of usefulness the moment that synchronisation degrades.
What this page does not claim
A system class is not a product. SPEQ describes what a CTMS or a LIMS is; the vendor directory at /tools lists the products that implement one, and a GAMP category is a property of an implementation, not of a class.
What a Digital Twins actually is
A digital twin is a model of a process, asset, or facility that is kept synchronised with its physical counterpart through live or regularly refreshed data. The class spans a spectrum: at one end, mechanistic or statistical process models used offline for development and investigation; at the other, continuously updated representations that estimate unmeasurable states, predict trajectories, and feed model-predictive control. What distinguishes a twin from a simulation is the connection — a twin is fed by the plant it represents, usually from the historian and control layer, and drifts out of usefulness the moment that synchronisation degrades.
In regulated manufacturing the credible uses are specific. Twins explore design space and run in-silico experiments during development that ICH Q8(R2) understanding is built from; they de-risk scale-up and technology transfer by predicting behaviour at the receiving scale before material is committed; they act as soft sensors, estimating attributes no physical instrument can measure in place; they support predictive maintenance on qualified equipment; and they give operators a consequence-free environment to train against upsets. Each use touches the quality system differently, which is precisely why the class resists a single validation posture.
The regulatory question is intended use, and it divides the class cleanly. A twin used for engineering insight, whose outputs a qualified person evaluates before anything happens, is decision support. A twin whose estimates enter the batch record, gate material disposition, substitute for a measurement, or steer control is performing a GxP function — and at that point it is a computerised system under EU GMP Annex 11 and GAMP 5, its records may carry 21 CFR Part 11 obligations, and its model logic needs validation evidence proportionate to what ICH Q9(R1) risk thinking says is at stake. The label "twin" changes none of this; the decision it influences changes all of it.
Validation has to hold two moving parts honestly. The software is tractable — GAMP 5 treats the platform as configured product and the model implementation as custom code, with the category attaching to each element of the implementation. The model is the harder half: its credibility rests on the data that built it, the domain it was validated across, and the monitoring that detects divergence between twin and plant. A twin is never finished — the physical asset drifts, is maintained, and is changed, so synchronisation quality and predictive performance are standing verification obligations, and retraining or recalibrating the model is a change-controlled event, not a background process. Where the model is machine-learned, the AI/ML lifecycle disciplines apply on top.
WHERE THE BOUNDARY ACTUALLY SITS
Not the historian. The historian records what the plant did; the twin estimates and predicts. Feeding the twin from historised data does not make the two interchangeable as evidence.
Historians, SCADA & PLC owns it →Not the PAT layer. A chemometric model converts a measured spectrum into an attribute; a twin models the process itself and may estimate states no instrument measures. Their validation frameworks differ accordingly.
PAT owns it →Not the ML platform. Where a twin embeds machine-learned components, the model development and lifecycle tooling belong to the AI/ML system class; the twin is the consumer of those artefacts.
AI/ML Systems in GxP owns it →Not a validated substitute for qualification. Predicting that equipment will perform does not evidence that it did — qualification and process validation obligations stand, however good the model.
WHAT IT HOLDS, AND WHAT CROSSES ITS BOUNDARY
CORE RECORDS
- Model versions, their governing equations or learned parameters, and the development data behind each
- Validation evidence per model version: the domain covered, acceptance criteria, and prediction-versus-actual results
- Synchronisation records — what plant data refreshed the twin, when, and with what data-quality screening
- Ongoing performance monitoring: divergence metrics between twin predictions and plant behaviour
- Change and retraining records linking each model update to its trigger, evidence, and approval
- Outputs used in GxP decisions — soft-sensor estimates, predictions, and the decisions they informed
DATA FLOWS OUT
Soft-sensor estimates and model-predictive outputs consumed by the continuous line's control strategy
Computed and estimated values written back as derived tags alongside the measured data that produced them
Training datasets, model artefacts, and performance telemetry exchanged with the ML lifecycle platform for learned components
Model performance excursions and retraining proposals routed into change control and, where warranted, deviation handling
HOW THIS CLASS IS USUALLY VALIDATED
- SPEQ synthesis: a digital twin is scoped by the decision its output touches, then validated per element under GAMP 5 — the simulation platform as Category 4 configured product, the model implementation and integrations as Category 5 — with assurance effort scaled by ICH Q9(R1) risk in the spirit of CSA. The category is a property of the implementation; "twin" is a use pattern, not a validation class.
- Model credibility is evidenced explicitly: the validation domain — the operating ranges, materials, and states the model was demonstrated across — is documented, and use outside it is either prevented or flagged, because extrapolation is the class's silent failure mode.
- Synchronisation is part of the validated function: the data path from historian and control layer into the twin, including quality screening and staleness handling, is verified — a twin fed bad or stale data is confidently wrong.
- Ongoing divergence monitoring between twin and plant is a specified control with defined thresholds and responses, and every retraining or recalibration is a change-controlled event with before/after performance evidence.
SPEQ synthesis, not a rating. This is SPEQ’s reading of how this system class is commonly approached, offered to help you scope your own work. A GAMP category is a property of a specific implementation, not of a product class, and one deployment routinely spans several. It is not a classification service and does not replace your own documented risk assessment.
- Stage 1 · Reactive
Models exist as personal artefacts — a scientist's scripts, a vendor's black box — with no version control, no defined validation domain, and no record of what data built them. Outputs are quoted in investigations without anyone able to say whether the model still reflects the plant.
- Stage 2 · Defined
Twins are used for defined offline purposes — development studies, investigation support, training — with versioned models, documented assumptions, and a stated validation domain. Outputs inform humans only, and the boundary against GxP decision-making is explicit.
- Stage 3 · Controlled
Twins operate under governance: synchronisation from plant data is a verified, screened path; divergence between prediction and reality is monitored against thresholds; model updates flow through change control; and where an output enters a GxP decision, the computerised-system validation to support it exists.
- Stage 4 · Predictive
Twins carry load-bearing roles — soft sensors in the control strategy, predictive maintenance on qualified assets, in-silico assessment inside change control — with prediction accuracy trended as a managed metric and model refinement running on a defined lifecycle with quantified benefit.
- Stage 5 · Adaptive
The modelled and physical plant co-evolve: process changes are rehearsed in the twin before they touch material, control strategies are refined against the model within an established governance frame, and the organisation can state, with evidence, where the twin's word is accepted and where the plant must still speak for itself.
SPEQ’s shared five-stage progression, labelled synthesis. It is not the FDA QMM rating scale and not the scored maturity-assessment domains — assess your quality system for those.
WHAT AN INSPECTION PROBES, AND WHERE IT GOES WRONG
INSPECTION SIGNALS
- Whether any twin output enters a batch record, disposition decision, or control action — and if so, whether the computerised-system validation behind it matches that role.
- Whether the model's validation domain is documented and its current use stays inside it, or whether yesterday's development model is quietly answering today's production questions.
- Whether divergence between the twin and the plant is monitored with thresholds and evidenced responses, or discovered only when a prediction embarrasses itself.
- Whether retraining and recalibration are change-controlled events with approval and performance evidence, or a background activity nobody signs for.
- Whether the provenance of the data that built and feeds the model can be produced — an unverifiable training set undermines every downstream claim.
COMMON RISKS
- Scope creep from advisory to load-bearing: a model built for engineering insight starts informing disposition decisions without anyone re-validating it for the promotion.
- Silent divergence — the plant is maintained, modified, and re-piped while the twin still models its younger self.
- Extrapolation as routine: predictions consumed from operating regions the validation domain never covered, with no flag raised.
- Synchronisation pipelines that ingest unscreened data, so instrument faults and historian gaps become confident model outputs.
- Key-person dependency, where the only human who understands the model's assumptions and limits leaves with them.
WHO WORKS IN IT, AND WHERE IT IS SHAPED
ROLES
- Process modelling engineer / simulation scientist
- Data engineer for the synchronisation pipeline
- Process engineer consuming twin outputs
- Automation engineer for control-strategy integration
- QA reviewer for model change control
- CSV analyst
DELIVERY-LIFECYCLE PHASES
[ POSITION IN THE FRAMEWORK ]
6 OF 7 DIMENSIONS · 23 LINKSA process or asset model kept synchronised with its physical counterpart — advisory today, and a regulated computerised system the moment its output enters a batch record, gates disposition, or steers control.
06 · QUALITY MATURITY — DIGITAL TWINS, REACTIVE TO ADAPTIVE
Models exist as personal artefacts — a scientist's scripts, a vendor's black box — with no version control, no defined validation domain, and no record of what data built them. Outputs are quoted in investigations without anyone able to say whether the model still reflects the plant.
Twins are used for defined offline purposes — development studies, investigation support, training — with versioned models, documented assumptions, and a stated validation domain. Outputs inform humans only, and the boundary against GxP decision-making is explicit.
Twins operate under governance: synchronisation from plant data is a verified, screened path; divergence between prediction and reality is monitored against thresholds; model updates flow through change control; and where an output enters a GxP decision, the computerised-system validation to support it exists.
Twins carry load-bearing roles — soft sensors in the control strategy, predictive maintenance on qualified assets, in-silico assessment inside change control — with prediction accuracy trended as a managed metric and model refinement running on a defined lifecycle with quantified benefit.
The modelled and physical plant co-evolve: process changes are rehearsed in the twin before they touch material, control strategies are refined against the model within an established governance frame, and the organisation can state, with evidence, where the twin's word is accepted and where the plant must still speak for itself.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 7
Derived from the 7 standards SPEQ maps to this subject, across 5 regulatory bodies: FDA, EMA, ICH, ISPE, ASTM.
RECORDS & OBJECTIVE EVIDENCE
- Model versions, their governing equations or learned parameters, and the development data behind each
- Validation evidence per model version: the domain covered, acceptance criteria, and prediction-versus-actual results
- Synchronisation records — what plant data refreshed the twin, when, and with what data-quality screening
- Ongoing performance monitoring: divergence metrics between twin predictions and plant behaviour
- Change and retraining records linking each model update to its trigger, evidence, and approval
COMMON INSPECTION FINDINGS
- A twin output entering a batch record or disposition decision without matching computerised-system validation
- Current use outside the model's documented validation domain — a development model answering production questions
- Divergence between twin and plant not monitored against thresholds, discovered only when a prediction fails
- Retraining and recalibration done as background activity, not change-controlled with performance evidence
- Synchronisation pipelines ingesting unscreened data, so instrument faults become confident model outputs
Choosing, validating, and living with Digital Twins
FREQUENTLY ASKED
Is a digital twin a GxP system?
It depends entirely on what its output touches — the honest answer regulators themselves would give. A twin used for engineering exploration, whose outputs a qualified person weighs before any action, is decision support outside the direct GxP boundary. The moment an estimate enters a batch record, gates material disposition, substitutes for a measurement, or drives control, the twin is performing a GxP function: EU GMP Annex 11 and GAMP 5 apply, and its records may fall under 21 CFR Part 11. Scope by the decision, not the technology label, and re-scope every time the use grows.
What is the difference between a digital twin and a simulation?
Synchronisation. A simulation is a model run on assumed or historical inputs — valuable, but frozen at the moment of its assumptions. A twin is coupled to the physical asset it represents: plant data refreshes its state, and its predictions are continuously comparable against what the plant then does. That connection is both the value and the obligation — a twin inherits a standing duty of divergence monitoring, data-quality screening, and re-validation on plant change that a one-off simulation never carries. Many claimed "twins" in regulated industry are, on inspection, simulations with a subscription.
Can a digital twin reduce validation or qualification effort?
It can sharpen it; it cannot replace it. A credible twin lets an organisation rehearse a process change in silico, focus qualification runs on the conditions the model says are worst-case, and bring ICH Q9(R1) risk assessments evidence instead of opinion — all of which makes verification effort better aimed, in the direction ASTM E2500 and CSA thinking encourage. But predicting that equipment or a process will perform is not evidence that it did: qualification and process validation obligations remain, executed against the physical system. The twin earns its keep by improving the questions, not by answering them in place of the plant.
How is model drift controlled in a digital twin?
By treating divergence as a monitored parameter with a defined response, not a discovery. The twin's predictions are compared against plant behaviour on a defined cadence, with thresholds that trigger investigation, restriction of use, or recalibration; the plant-side causes — maintenance, equipment change, material shifts — are connected to the twin through change control, so a physical modification prompts a model-impact assessment rather than silent decay. Every retraining or recalibration is itself change-controlled, with before-and-after performance evidence. For machine-learned components, the AI/ML lifecycle disciplines add data-drift monitoring beneath the prediction-drift layer.