Digital Twins Across the Process Lifecycle

A digital twin is one of the most over-used phrases in manufacturing right now, and one of the least precisely defined. Vendors apply it to a static process diagram, a spreadsheet, a dashboard, and a fully coupled real-time model with equal confidence. For a regulated environment that imprecision is a problem, because the validation evidence you need, the data integrity controls you put around it, and the GxP weight you can place on its output all depend on what the thing actually is and what decision it actually drives.

This article sets out what a digital twin is and is not, how twins are used across the process lifecycle from development through commercial monitoring, how mechanistic and data-driven models combine in practice, and, most importantly for a quality professional, how you verify and validate a twin and govern it once its output starts to inform regulated decisions. It is written so that after reading it you could scope the qualification of a twin, defend it in an inspection, and answer the questions an interviewer will ask. If you have not built a foundation in process validation, read the process validation lifecycle first; the twin sits on top of that base, it does not replace it.

What a Digital Twin Actually Is

A digital twin is a computational representation of a specific physical asset or process that is kept synchronized with that asset using live or near-live data, and that is used to predict, optimize, or monitor the behavior of the real thing. Three properties separate a true twin from the looser uses of the word.

It is tied to a specific instance. A generic process model describes how a class of bioreactors behaves. A twin is bound to bioreactor BR-204 in suite 3, fed by the actual measurements coming off that vessel. The binding to one physical instance is what makes it a twin rather than a model.

It is synchronized with live data. A twin ingests the real process data, sensor readings, batch records, environmental conditions, and updates its internal state to match reality. A model you run once with assumed inputs is a simulation; a model continuously fed by the running process is a twin.

It produces an actionable representation, not just a picture. The twin lets you ask “what is happening that I cannot directly measure” or “what will happen if I change this parameter,” and get an answer grounded in the current state of the real asset.

It is worth being blunt about the distinctions, because they are routinely blurred and the blurring is where validation scope goes wrong.

The reason this taxonomy matters: the validation burden and the GxP risk rise as you move down the table. A digital shadow that only visualizes data carries data-integrity obligations for the data it displays. A twin whose prediction adjusts a process parameter carries the full weight of a model that influences product quality, and must be validated as such.

The guidance that governs the data and the systems here was not written for digital twins. 21 CFR Part 11 and EU GMP Annex 11 govern the electronic records and the computerized systems; ICH Q8, Q9, and Q10 govern the process understanding, the risk basis, and the quality system the twin operates inside. None of them names the word “twin.” You reason from these principles rather than following a recipe, and you document where you are reasoning by analogy.

Why a Digital Twin, and Where the Regulatory Hook Is

Why (the business and the regulatory case)

The honest business case is that some process states cannot be measured directly, fast enough, or cheaply enough. You cannot put a probe on every molecule; some critical quality attributes come back from the lab hours or days after the batch decision had to be made. A twin that estimates those states in real time, from the measurements you do have, lets you see and act on the process while it is still running rather than after the fact.

The regulatory hook is process understanding. ICH Q8 frames quality by design around understanding the relationship between process parameters and product quality, and defining a design space within which quality is assured. A mechanistic or hybrid model that captures those relationships is, in effect, an executable form of that process understanding. Used in development it accelerates the design-space work; used in commercial operation it can become part of a control strategy. The same body of thinking underpins continued process verification, where the question is whether the process stays in its validated state over time, exactly the question a monitoring twin is built to answer.

The risk that earns the controls

The risk is straightforward to state: if a twin’s prediction is wrong and a decision is made on it, the consequence lands on product quality and ultimately the patient. A soft sensor that under-reads a critical attribute could let a batch proceed that should have been held. A twin used to set a feed rate could push the process toward an edge the model did not represent well. The severity of that consequence, sized through quality risk management under ICH Q9(R1), is what determines how hard you validate the twin and how much human control you wrap around it. A twin that only advises a scientist during development is low risk. A twin in a closed control loop on a commercial batch is the highest risk, and the validation effort must match.

Direction of travel: the draft Annex 22 and the Annex 11 revision

There is still no guidance that names digital twins, but two EU drafts published on 7 July 2025 change the backdrop a twin operates against, and both bear directly on how a twin’s model can be used. The European Commission released a draft revised Annex 11 on computerised systems and a companion new draft Annex 22 on artificial intelligence for public consultation; the consultation closed on 7 October 2025 and final text is expected around 2026, likely with a transition period. Neither is in force, so you still build to the 2011 Annex 11 and reason from ICH Q8, Q9(R1), and Q10. Read the drafts for direction, not as binding text, and confirm the published wording before you cite it.

Annex 22 matters most for twins because it takes a position on the kind of model you can put in a critical GMP application. As drafted, it allows static, deterministic models (same input, same output, no self-updating in production) in critical uses when they are qualified and kept under lifecycle control, and it pushes dynamic (continuously learning) models and generative AI out to non-critical uses with documented human oversight. Map that onto the lifecycle table below. A twin whose data-driven component is locked after validation and changed only through controlled change control reads as a static, deterministic model and can sit in a critical use such as advisory or closed-loop control. A twin that retrains itself on live data in production is a dynamic model, and the draft’s direction would keep it out of critical GMP decisions unless you lock it first. This is the same locked-by-default principle that runs through the GxP ML model lifecycle: freeze the model for its GxP use, and treat any update as a controlled change event rather than continuous learning in place.

The draft Annex 11 revision reinforces the surrounding controls a twin needs regardless: more explicit expectations on audit trails, supplier and service management (relevant when the twin or its platform is vendor-supplied or cloud-hosted), identity and access management, periodic review, and, for the first time, cybersecurity as a core expectation. None of that is a surprise for a well-scoped twin, but it is where inspector expectations are heading, so design the twin’s records, access, and supplier oversight with the revision in view.

The Twin Across the Process Lifecycle

A twin is not one thing used one way. The same underlying model can serve very different purposes at different stages, and the validation expectations shift with the stage. Mapping the uses to the conventional process lifecycle keeps the scope honest.

Stage 1 - Process Development and Design

In early development the twin is a research and design tool. Scientists use it to explore the process space, narrow the number of physical experiments, and build the understanding that feeds the design space. At this stage the twin is not making GxP decisions; it is informing experimental design and scientific judgment.

• What it does: predicts outcomes of conditions not yet run, identifies the most informative experiments to run next, and helps map parameter-to-attribute relationships.
• GxP weight: low. The twin supports human scientific decisions; the data that goes into the design space still has to be confirmed experimentally.
• What you still owe: the data feeding the model and the model’s role in any decision that ends up in a regulatory filing must be documented and reproducible. A model output that becomes a justification in a filing is no longer purely internal.

Stage 2 - Scale-Up and Technology Transfer

Scaling a process from bench to pilot to commercial is where mechanistic understanding pays off. The physics of mixing, mass transfer, and heat transfer change with vessel size in ways that pure empirical correlation does not predict well. A mechanistic or hybrid twin that captures those physics can predict how a process will behave at the larger scale and reduce the number of expensive scale-up runs.

• What it does: predicts large-scale behavior from small-scale data plus engineering first principles; supports the technology transfer between sites or scales.
• GxP weight: rising. Predictions here can shape the commercial process design and the validation strategy. For biologics this connects directly to the biologics process validation work, where scale and biological variability interact.
• What you still owe: documented assumptions about what changes with scale and what does not, and confirmation runs at scale that test the twin’s predictions rather than assuming them.

Stage 3 - Process Control

This is the highest-stakes use. The twin estimates a current process state in real time, often a critical quality attribute or a critical process parameter that cannot be measured directly fast enough, and that estimate is used to make or recommend a control action. Two flavors:

• Advisory control: the twin recommends, an operator or engineer decides and acts. Human judgment stands between the model and the process.
• Closed-loop control: the twin’s output feeds an automated control action directly. No human in the immediate loop.

GxP weight is highest here, and closed-loop is higher than advisory. The twin now influences a parameter that affects product quality, so it must be validated to that standard and it must sit on top of the conventional automation and control system validation for the underlying equipment. Critically, a closed-loop twin needs deterministic safety interlocks, engineered limits that prevent the process from leaving its validated operating range regardless of what the model says. The interlock is a conventional control you can validate the old way; it is what keeps a predictive component inside a defensible envelope.

Stage 4 - Commercial Monitoring and Continued Verification

In routine commercial manufacturing the twin runs alongside every batch, estimating states and flagging deviations from expected behavior. It becomes a tool for continued process verification: a live check that the process remains in its validated state, with the twin surfacing drift or anomalies earlier than end-of-batch testing would.

• What it does: real-time deviation detection, golden-batch comparison, early warning of trends that classical sampling would catch later.
• GxP weight: moderate to high, depending on whether the twin only alerts (advisory) or whether its output gates batch decisions.
• What you still owe: evidence that the twin still performs, because a model validated at release can degrade silently as raw materials, equipment, and conditions drift, the same drift problem that affects any model and is covered for learning systems in the GxP ML model lifecycle.

A summary view:

Hybrid Models: Mechanistic Plus Data-Driven

The model inside a twin is rarely purely one kind. Understanding the three families and why they are combined is core to scoping the validation.

Mechanistic (first-principles) models are built from the physics, chemistry, and biology of the process: mass balances, reaction kinetics, mass and heat transfer, fluid dynamics. Their great strength is that they extrapolate. Because they encode the actual mechanism, they can predict behavior in regions you have not run, which is exactly what scale-up needs. Their weakness is that real bioprocesses are messy, and some phenomena, cell metabolism being the classic example, are too complex to model fully from first principles. Mechanistic models also need parameters (kinetic constants, transfer coefficients) that have to be estimated from data.

Data-driven (empirical) models, including statistical and machine-learning models, learn relationships directly from process data without encoding the mechanism. Their strength is that they capture complex patterns a mechanistic model would miss, and they are often quicker to build where data is plentiful. Their weakness is that they do not extrapolate safely. Outside the range of the data they were trained on, their predictions are unreliable in ways that are easy to miss, because the model will still confidently produce a number. They also inherit every problem of any ML system: drift, the need for representative training data, and limited interpretability, all of which are treated in validating AI-enabled GxP systems.

Hybrid models combine the two, and in bioprocessing they are usually the practical answer. A common pattern uses a mechanistic backbone for the parts of the process the physics describes well, mass balances, transport, with a data-driven component estimating the parameters or sub-processes the mechanism cannot capture, such as the specific cell-metabolism rates. The hybrid keeps the extrapolation strength of the mechanistic model where it can, and uses data to fill the gaps the mechanism cannot reach.

The validation consequence of a hybrid is that you carry both sets of obligations. You verify the mechanistic part against physics and known data, and you validate the data-driven part as you would any model: with a representative training set, a locked held-out test set, and drift monitoring. And you must understand how the two interact, because a failure in the data-driven parameter estimate propagates into the mechanistic prediction.

Verification and Validation of the Twin

This is the section that matters most for a quality professional, because a twin that informs a GxP decision is a computerized system and a model at the same time. Two distinct questions sit underneath the loose word “validation,” and inspectors will separate them even if your documentation does not.

• Verification: did we build the model right? Is the math implemented correctly, do the equations solve as intended, does the code do what the specification says?
• Validation: did we build the right model? Does the twin predict the real process accurately enough for its intended use, on data it has not seen?

You need both. A twin can be flawlessly implemented (verified) and still be a poor representation of reality (not validated), and vice versa.

Step by step

1. State the intended use and the decision the twin drives. As with any model, the most important single decision is to write down, in one sentence, what the twin outputs, what action that output triggers, and who is accountable for the consequence. “The twin estimates product titer in real time; the estimate informs the harvest-timing recommendation; the process engineer confirms or overrides and owns the harvest decision.” If you cannot write that sentence cleanly, the scope is not defined and everything downstream is mis-sized. This statement sets the risk class and therefore the depth of everything that follows.

2. Assign the risk class and size the effort. Using ICH Q9(R1), classify the use (development advisory / scale-up prediction / advisory control / closed-loop control / monitoring) and document the rationale. The risk class is the justification for why you validated this twin lightly or heavily, and it is the first thing an inspector will probe.

3. Verify the implementation. Confirm the model is built correctly: the equations are the intended equations, the numerical solver converges and is stable, unit conversions are right, and the code matches the specification. For the data-driven component, verify the training pipeline does what it claims. This is conventional computerized-system verification applied to the model engine.

4. Define acceptance criteria before you validate. A twin is validated against a quantitative accuracy specification, not a pass/fail functional spec. State the metric and the threshold before you test, tied to the consequence of error. For a continuous prediction the common metrics are:

• Root mean square error (RMSE) or mean absolute error (MAE): how far off the prediction is from the truth, in the units of the variable. The threshold must be tied to what the decision can tolerate.
• Bias (mean error): is the twin systematically high or low? A biased soft sensor that consistently over-reads a quality attribute is dangerous in a specific direction.
• Coverage of prediction intervals: if the twin reports uncertainty, does a stated 95 percent interval actually contain the truth about 95 percent of the time? An overconfident twin that reports tight intervals it does not earn is worse than one that is honestly uncertain.
• Accuracy across the operating range: the twin must be accurate not just on average but across the range of conditions it will face, including the edges where decisions are most consequential.

5. Validate against independent data. Validate the twin’s predictions against real process data the model was not built or fitted on. For the data-driven part this is the locked held-out test set discipline: a dataset, ideally from batches run after the training data, that the model never saw during development, touched once to report the number that goes in the validation report. Performance reported on the data the model was fitted to is meaningless as validation evidence. Where possible, validate against batches that span the operating range and include the edge cases that matter.

6. Establish the boundary of validity (the design space of the twin). A twin is only valid within the range of conditions it was verified and validated for. Document that boundary explicitly: the ranges of inputs, scales, products, and conditions inside which the twin’s accuracy was demonstrated. Outside it, the twin’s output is not validated evidence, and the system must either refuse to predict or flag the prediction as out of validated range. This is the single most common gap, a twin used confidently in a region it was never validated for.

7. Validate the integration, not just the model in isolation. The twin lives inside a chain: sensors feed it, it computes, its output goes to an operator screen or a control system. Validate the whole path. A perfectly accurate model is useless if the sensor feeding it is mis-mapped, the data arrives late, or the output is displayed against the wrong batch. The integration seams are where real systems fail.

Acceptance criteria for the twin (release checklist)

Before a twin is released for a GxP use, the file should be able to show all of the following:

• The intended-use statement names the output, the action it triggers, and the accountable role, and is approved by Quality.
• The risk class is assigned with an ICH Q9(R1) based rationale on file.
• Verification evidence shows the model is implemented correctly (equations, solver, code, training pipeline).
• An accuracy specification with metric, threshold, and a justification tied to the consequence of error was written before validation.
• Validation against independent data the model never saw meets the specification, across the operating range including the edges.
• The boundary of validity is documented, and the system handles out-of-range conditions explicitly.
• The full data path (sensor to output to decision) is validated, not only the model.
• For closed-loop control, deterministic safety interlocks are independently validated.
• A monitoring plan is live from day one with defined triggers and responses.
• Traceability runs from intended use to requirements to test evidence, with rationale recorded where guidance was silent.

If any line cannot be evidenced from the file, the twin is not ready for release regardless of how well it predicted in a demo.

Data Requirements

A twin is only as good as the data feeding it, in two distinct senses: the data used to build and fit it, and the live data that drives it in operation. Both are GxP records when the twin informs a regulated decision, and both inherit the ALCOA+ expectations.

Build and training data. The data used to fit the model parameters or train the data-driven component must be representative of the conditions the twin will face, traceable to its source, and version-controlled so the model can be reproduced. Reproducibility is the model analogue of a retained record: if you cannot rebuild the twin, you cannot investigate it after a problem. For a hybrid model, both the parameter-estimation data and the training data carry this obligation.

Live operational data. The sensor readings, batch context, and process data that synchronize the twin in real time must be accurate, attributable, and timely. Specific concerns:

• Sensor accuracy and calibration. The twin trusts its inputs. A drifting or out-of-calibration sensor feeds the twin bad data, and the twin produces a confident wrong answer. Sensor calibration status is part of the twin’s data-integrity boundary.
• Time alignment. A twin synchronizes data from multiple sources. If the clocks are not aligned or latency is uncontrolled, the twin computes on mismatched data. System clock control matters here exactly as it does for any time-stamped GxP record; see timestamps and system clock control.
• Missing and out-of-range data. Define what the twin does when an input is missing, late, or implausible. Silently substituting a default or carrying the last value forward can produce a misleading prediction with no flag. The handling must be specified and validated.
• Data lineage. The path from sensor to twin to output must be traceable, so that a prediction can be reconstructed and explained. If a harvest decision was made on a twin estimate, you must be able to show the inputs that produced that estimate.

A useful discipline: treat the twin’s input data with the same rigor you would treat the raw data behind a batch release, because in the highest-risk uses it effectively is.

GxP Considerations When a Twin Informs Decisions

Once a twin’s output crosses from “interesting to a scientist” into “informs a GxP decision,” a set of obligations attaches that pure engineering teams often miss.

The twin is a computerized system. It falls under the records and systems expectations of 21 CFR Part 11 and EU GMP Annex 11: access control, audit trails over the data and any configuration changes, and electronic-record integrity. A twin that adjusts its own parameters needs the configuration history captured as a controlled, auditable record.

Change control applies to the model. A change to the twin, refitting parameters, retraining the data-driven component, updating the mechanistic equations, changing the input set, is a system change in the validation sense and runs through change control for validated systems. The hard part is that “update the twin” spans a wide range, from a minor parameter refresh to a structural change of the model. A predetermined approach that classifies anticipated changes and the testing each requires keeps routine maintenance controlled instead of treating every refit as an unplanned deviation. A worked classification:

Human oversight scales with risk. For advisory uses, a qualified person stands between the twin and the action and owns the decision; the twin informs, it does not decide. For closed-loop control, the human control shifts to the engineered interlocks and the monitoring, because there is no human in the immediate loop, plus periodic human review of the twin’s performance. The principle from validating AI-enabled GxP systems holds: a regulated decision needs documented human judgment somewhere in the system, and you must guard against automation bias, the tendency to stop truly reviewing a model that is usually right.

Ongoing performance must be demonstrated, not assumed. A twin validated at release can degrade as the process, materials, and equipment drift, with no change to the twin at all. The validated state therefore includes monitoring: periodic comparison of the twin’s predictions against actual measured outcomes, tracking of prediction error over time, and a defined response when error exceeds a threshold. A twin with no monitoring is not in a validated state regardless of how it performed at release, because there is no evidence it still works. This is the twin’s version of periodic review, described in the validation master plan and periodic review article.

Roles and Responsibilities

A twin fails most often at the seams between functions, because no single role owns the whole thing: the process scientists own the mechanism, the data scientists own the model, automation owns the control system, and quality owns the decision. Name owners explicitly.

The recurring failure is treating the twin as a pure engineering or data-science deliverable that QA reviews only at the end. The intended-use statement, the boundary of validity, the data-integrity controls, and the change plan all need quality involvement while the twin is being built. See GxP roles and responsibilities for the broader accountability model.

A Worked Lifecycle Example

Follow one twin through its life to make the abstractions concrete. The example is a soft-sensor twin for a mammalian cell-culture bioreactor that estimates product titer, the concentration of the product, in real time. Titer is normally measured by an offline assay that takes hours, too slow to inform the harvest-timing decision while the culture is running.

Development. A hybrid model is built: a mechanistic backbone of mass balances for the key nutrients and metabolites, with a data-driven component estimating the cell-specific productivity that the mechanism cannot derive from first principles. Scientists fit it on data from a set of development runs and use it to explore harvest timing in simulation, reducing the number of physical runs needed to characterize the harvest window. GxP weight is low; the twin informs experimental design and the data feeding the eventual filing is documented and reproducible. The team versions the training dataset and records the fitting procedure.

Scale-up. Moving from the bench bioreactor to the commercial-scale vessel, the mechanistic backbone earns its keep: the mass-transfer and mixing terms change with scale, and the first-principles part predicts how titer development will differ at the larger volume. The data-driven productivity component is refitted with the limited large-scale data available. Confirmation runs at scale test the twin’s prediction rather than assuming it; the boundary of validity is documented to cover the commercial scale and the product, and explicitly not other products or scales.

Validation for advisory control. The intended use is now stated precisely: “The twin estimates titer in real time; the estimate informs the harvest-timing recommendation to the process engineer; the engineer confirms or overrides and owns the harvest decision.” Risk class is advisory control, high but not closed-loop, with the ICH Q9(R1) rationale on file. The implementation is verified (the mass-balance equations, the solver, the training pipeline). An accuracy specification is written before validation: the twin’s titer estimate must be within a stated absolute error of the offline assay across the harvest window, with a documented bias limit, because a twin that consistently over-reads titer could prompt an early harvest that loses product, while one that under-reads could prompt a late harvest with quality consequences. The twin is validated against offline assay results from a set of qualification batches the model was never fitted on, spanning the operating range; the reported error meets the specification. The full data path is validated: the online probes feeding the twin are calibrated, the time alignment is confirmed, and the displayed estimate is verified to bind to the correct batch. The handling of a missing or out-of-range input is specified, the twin flags rather than silently substitutes.

Commercial operation and monitoring. In routine manufacturing the twin runs every batch, displaying a live titer estimate and flagging deviation from the expected trajectory. It feeds continued process verification: a persistent rise in the twin’s prediction error, or a systematic bias creeping in, is an early signal that something, raw material lot, cell line, equipment, has shifted. The monitoring plan, live from day one, compares the twin’s estimate against the offline assay on every batch (the assay still runs, it is just no longer on the critical timing path), tracks the error over time, and defines the response when error exceeds the threshold: the twin’s advisory output is suspended and harvest reverts to the offline-assay-driven procedure while the error is investigated. The engineer’s confirm-or-override action and the model version that produced the estimate are captured in the batch record.

A change event. A new raw-material supplier is qualified, shifting the nutrient profile slightly. Under the predetermined change plan this is a “new input characteristics” event: the team checks the twin’s accuracy on the first batches with the new material against the validation spec, finds the error still within limits, documents the confirmatory check, and the twin continues in use. Had the error exceeded the spec, the plan would have required refitting and revalidation before the twin could keep informing harvest timing. The decision logic was approved before anyone had a result to defend, which is the entire point of writing it down in advance.

Common Inspection and 483-Type Mistakes

These are the recurring failure patterns, framed generically. Each maps to a real category of finding seen against computerized systems, process validation, and data integrity.

• Used outside its validated range. The twin is applied to a new scale, product, or condition it was never validated for, on the assumption that a model that worked once works everywhere. Data-driven components especially fail silently outside their training range, still producing a confident number. The fix is a documented boundary of validity and a system that refuses or flags out-of-range predictions.
• Validation evidence on fitted data. Reporting the twin’s accuracy on the very data used to build or fit it, so the headline number is flattering and the twin underperforms in production. The fix is independent validation data the model never saw.
• Verification mistaken for validation, or vice versa. Showing the model is implemented correctly (verification) and calling that validation, or showing it predicts well once and never verifying the implementation. Inspectors separate the two questions; the file should too.
• The model validated, the data path ignored. A correct model fed by a mis-mapped sensor, late data, or an output bound to the wrong batch. The integration seam was never validated.
• Sensor integrity outside scope. Treating the twin as a software problem and ignoring that a drifting, out-of-calibration input feeds it bad data. The twin’s accuracy is only as good as its calibrated inputs.
• No model change control. Refitting parameters or retraining the data-driven component with no governance, so the validated state silently lapses. Without a predetermined change plan this is almost guaranteed.
• Deploy and forget. No monitoring, so there is no evidence the twin still predicts accurately months later. The validated state is asserted, not demonstrated, while raw materials and equipment have drifted underneath it.
• No defined response when it goes wrong. Monitoring exists but there is no specified action when prediction error trips the threshold, so a degrading twin keeps informing decisions. A monitoring system with no defined response is decoration.
• Overstated as a “twin” or understated as a “shadow.” Calling a static model a twin to sound advanced, or calling a decision-driving twin a “shadow” to dodge the validation burden. The classification has to match what the system actually does and what decision it actually drives.
• Automation bias in advisory use. Operators rubber-stamping the twin’s recommendation because it is usually right, hollowing out the human control that the advisory design depends on. Watch the override rate and treat a near-zero override rate as a signal to investigate, not as success.
• Closed-loop with no interlock. A twin driving a process parameter automatically with no deterministic engineered limit to stop it leaving the validated range when the model is wrong. The interlock is the control that keeps a predictive component inside a defensible envelope.

Interview Questions and How to Answer Them

If you are interviewing for a digital quality, CSV, or process validation role and digital twins come up, these questions separate a real practitioner from someone reciting the buzzword. Short, concrete answers win.

“What is the difference between a digital twin, a model, and a simulation?” A model is a general mathematical representation of how a process behaves. A simulation is a model run with chosen inputs to explore a scenario, not tied to a live asset. A digital twin is bound to a specific physical instance, synchronized with live data from that asset, and used to predict, optimize, or monitor it. The validation burden rises along that progression, because the twin is the one actually influencing a real running process.

“How do you validate a digital twin?” I separate two questions. Verification: is the model implemented correctly, equations, solver, code, training pipeline? Validation: does it predict the real process accurately enough for its intended use, tested on independent data it was never built or fitted on? I set an accuracy specification before testing, tied to the consequence of error, validate across the operating range including the edges, document the boundary of validity, and validate the whole data path, not just the model in isolation.

“What is special about validating a hybrid mechanistic-plus-data-driven model?” I carry both sets of obligations. The mechanistic part I verify against the physics and known data and check that its parameters are estimated soundly; the data-driven part I validate as any ML model, representative training data, a locked held-out test set, drift monitoring. And I check how the two interact, because an error in the data-driven parameter estimate propagates into the mechanistic prediction. The mechanistic backbone is also what lets the model extrapolate at scale-up; the data-driven part does not extrapolate safely outside its training range.

“How do you know a twin is still valid after a year in commercial use?” Because monitoring shows it. I compare the twin’s predictions against actual measured outcomes on an ongoing basis, track prediction error and bias over time, and have a defined response when error exceeds the threshold, usually suspending the twin’s advisory role and reverting to the conventional measurement while I investigate. Without that evidence the validated state is just an assertion from release day, and the process underneath the twin has almost certainly drifted.

“A twin drives a process parameter automatically. What is your biggest concern?” That the model is wrong in a region it was not validated for and there is nothing to stop it driving the process out of its validated range. I mitigate with a deterministic safety interlock, independent of the model, that holds the process inside engineered limits regardless of the prediction, plus monitoring and a change plan. The interlock I can validate the conventional way, and it is what makes a probabilistic component defensible in a closed loop.

“Where does a digital twin sit in the regulatory framework?” There is no guidance that names digital twins. I reason from the principles: 21 CFR Part 11 and Annex 11 for the records and the system, ICH Q8 for the process understanding the twin encodes, ICH Q9(R1) to size the validation effort to risk, and ICH Q10 for the quality system it operates inside. I document explicitly where I am reasoning by analogy, because no single guidance fits cleanly, and that honest documentation is more defensible in an inspection than claiming the twin slots neatly under a framework that does not quite cover it.

“Does the draft EU Annex 22 change how you would deploy a twin?” It sharpens one design choice. As drafted, Annex 22 allows static, deterministic models in critical GMP applications and pushes continuously learning models and generative AI to non-critical uses with human oversight. So a twin I want in an advisory or closed-loop control role should be locked after validation, with any change routed through change control, which makes it a static, deterministic model in the draft’s terms. A twin that retrains itself on live data in production would, under that direction, be kept out of critical decisions until it is locked. It is a draft and not in force, so I still build to the current Annex 11 and treat Annex 22 as direction of travel, but it reinforces the locked-by-default posture I would take anyway.

The Honest Assessment

Digital twins are genuinely useful in bioprocessing, because they let you see and act on process states you cannot measure directly fast enough to matter. The value is real, especially for scale-up and for real-time monitoring of attributes that classical sampling catches too late.

The risk is that the word carries more confidence than the evidence underneath it often supports. A twin is a model bound to a live asset, and it inherits every limitation of the models inside it: mechanistic models need sound assumptions and break outside their physical validity, data-driven models drift and fail outside their training range, and hybrids carry both failure modes. None of that disqualifies a twin from a GxP role. It just means the discipline that governs any model in a regulated environment applies here too, scaled to the risk: a precise intended-use statement, an accuracy specification set before testing, validation on independent data, a documented boundary of validity, validation of the whole data path, governed change control, deterministic interlocks where the twin acts automatically, and monitoring that proves it still works rather than assuming it does.

A twin deployed with that file behind it, and with honest documentation of where the framework was silent and where the model’s limits lie, reads as a system under control. One deployed on the strength of an impressive demo, with no boundary of validity and no monitoring, is an inspection finding waiting to be written. The difference is not the sophistication of the model. It is the rigor of the evidence around it.