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 a representation you can act on, 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.

Asset, Process, and Performance Twins

A second axis of confusion is what the twin actually represents, because “digital twin” gets applied to at least three different scopes of thing, and mixing them up leads to a validation that is scoped for the wrong risk.

Asset twin. Represents a piece of equipment, a bioreactor, a chromatography skid, a lyophilizer, and its own condition: wear, calibration drift, remaining service life. Used mostly for maintenance and reliability planning, not directly for product quality, though a failing asset obviously threatens both eventually.

Process twin. Represents the process running inside or across assets, the reaction, the fermentation, the separation, and predicts or estimates process states such as titer, purity, or a critical process parameter. This is the type the rest of this article is mostly about, and the type most likely to carry direct GxP weight.

Performance or plant twin. Represents a whole line or facility, aggregating multiple asset and process twins to answer questions about throughput, scheduling, or capacity rather than the state of any single batch. Used for planning and debottlenecking more than for a batch decision, though a plant twin that reschedules a batch onto different equipment can indirectly touch GxP concerns such as equipment qualification state.

A single vendor platform can host all three, and the sales deck will call all three a “twin” with no distinction between them. Ask which one you are actually looking at before you ask how to validate it. What follows, and the templates that go with it, is written for the process twin, since that is the one most likely to touch a batch disposition decision, but the same intended-use discipline scales down to the other two.

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.

Neither draft had been finalized as of late September 2026, and the process moved without finishing. The consultation closed 7 October 2025, and EMA and PIC/S held a two-day multistakeholder workshop on 30 June and 1 July 2026 where the Annex 22 drafting group reviewed the consultation feedback with outside experts. What came out of that workshop is worth tracking on its own: EMA’s own account of the event states that the 2025 consultation responses showed support for eventually enabling generative AI in medicines manufacturing, which is a step back from the flat static-model-only line the July 2025 draft drew for critical uses, and that the workshop sought expert input on guardrails and control measures for a risk-based approach rather than a blanket restriction. No revised text has been published as a result, PIC/S still lists Annex 22 as a draft guideline, and neither EMA nor PIC/S has given a finalization date. Read that as movement inside the drafting process, not a change to the rule. Until a revised draft or final text is issued, the practical position for a twin’s data-driven component stays what it was: lock it for critical GxP uses and treat retraining as a controlled change event, because that is what both the current draft and the current in-force Annex 11 support, and a workshop signal is not adopted guidance.

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.

The four stages above are usually easy to place in hindsight. In the room deciding how hard to validate a specific twin, the more useful question is a shorter sequence: does the model act on its own, and if not, who is actually deciding?

Answer the four questions in order and stop at the first yes. A twin that would honestly answer yes to more than one, informing an early scientist’s judgment call today and quietly gating a batch decision next quarter, is usually two twins wearing one name, and each use deserves its own intended-use statement and its own risk class rather than one blended assessment that undersells the riskier use.

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.

Establishing Model Credibility Beyond Accuracy

Accuracy metrics answer “does the twin get the right number.” They do not answer a question reviewers and inspectors increasingly ask anyway: why should this specific prediction, on this specific batch, be trusted when it disagrees with a scientist’s intuition? That second question is about credibility, not accuracy, and it matters most for the data-driven half of a hybrid twin, because a mechanistic model’s answer can usually be traced back to a physical equation while a data-driven model’s answer often cannot be traced back to anything a person can point at.

Three practices build credibility without duplicating the accuracy work already done in validation.

Sensitivity analysis. Vary each input across its plausible range, one at a time, and confirm the twin’s output moves in a direction and magnitude a process expert would expect. A titer-prediction twin that turns out to be more sensitive to a nutrient concentration than the underlying biology supports is not a twin anyone should trust yet, even if its RMSE on the validation set looked fine. Sensitivity analysis catches a model that is accurate on average but right for reasons that will not hold up once conditions drift outside the validated range.

Interpretability of the data-driven component. For the parts of a hybrid or purely data-driven model that are not mechanistic equations, some form of explanation for individual predictions helps a reviewer or an operator understand why the twin said what it said, not just that it has historically been right most of the time. Feature-contribution methods are common here, with a caveat worth stating out loud: they explain the model’s internal logic, not necessarily the true biology, so treat the explanation as a diagnostic aid rather than proof of correctness. The same caution about over-trusting a plausible-sounding explanation is covered in validating AI-enabled GxP systems and applies here without modification.

A documented credibility rationale tied to the context of use. Engineering fields that lean hard on simulation for high-stakes decisions, aerospace being the most mature example, converged years ago on a similar idea under different names: the depth of credibility evidence a model needs should scale with how heavily the decision relies on the model and how bad it is if the model is wrong, not with one fixed checklist applied to every model regardless of the stakes. You do not need to import a whole framework to use the idea. Write down, in the validation file, what would have to be true about the model for this specific prediction to be trusted for this specific decision, then show the evidence for each of those things. A model credibility discussion that shows only an accuracy number and never states what “trustworthy for this decision” actually means is answering a question nobody asked.

None of this replaces the accuracy specification in the validation plan; it sits beside it. It is usually the difference between a twin that survives a skeptical question in an inspection and one that only ever survived a friendly one.

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. The live data path and input fidelity checklist is built to run at a cadence independent of the twin’s own performance monitoring, precisely because a degrading input path can look invisible right up until it produces a confident wrong prediction.

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, expanded into a full procedure in the digital twin model and data-path change control SOP:

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. The output review SOP turns that principle into a per-output procedure with an override-rate check built in, rather than leaving “review before you act” as an unwritten expectation.

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.

Vendor-Hosted and Cloud-Deployed Twins

Very few sites build a digital twin platform from scratch. Most run on a vendor’s simulation engine, a cloud-hosted modeling platform, or a CDMO’s own twin, and that changes what verification and data integrity mean in practice without changing that they still fully apply.

The platform is a GxP system even when you did not write the code. Whether the twin runs on your server or a vendor’s cloud, if its output informs a GxP decision it falls under the same computerized-system expectations either way. A cloud deployment does not lower the bar; it adds questions about where the compute happens, who can access it, and how you pull evidence out of an environment you do not administer. Cloud and SaaS validation covers the shared-responsibility model this depends on: know exactly which controls the vendor owns and which stay yours, in writing, before you rely on the platform for anything regulated.

Supplier assessment has to reach the model, not just the software. A standard software supplier audit checks how the vendor develops and tests code. A twin vendor audit also has to reach the model itself: what data trained the data-driven component, whether that training data or the model changes without your visibility, and how the vendor notifies you of a version change that could shift your twin’s behavior underneath you. Supplier and vendor qualification sets the general expectations; for a twin, add explicit questions about model versioning and change notification to the standard questionnaire, because a vendor that silently updates a shared model is doing the exact thing your own change control forbids you from doing internally.

A CDMO-operated twin needs the same oversight as any other CDMO-controlled process step. When a contract manufacturer runs the twin as part of a transferred or manufactured process, its validation evidence, change history, and monitoring records are part of what you must be able to see and assess under the quality agreement, the same way you oversee any other CDMO-controlled critical step, described in CDMO oversight and quality agreements. Do not accept “the model is proprietary” as a reason you cannot review evidence that a decision affecting your product was sound. A vendor can protect a model’s internals and still show validation and monitoring evidence.

Cybersecurity is now a named expectation, not an assumption. A twin platform that ingests live process data and, in a closed-loop use, can influence a control action, is a bridge between IT and OT that did not really exist before twins became common, and it is exactly the kind of surface the draft Annex 11 revision’s new cybersecurity chapter is aimed at. Segment the twin platform’s network access from the control system it feeds, apply the same identity and access management rigor you would to any system that can affect product quality, and confirm the vendor’s patching and access-control posture as part of the supplier assessment rather than assuming a familiar brand name covers it. See access control and cybersecurity for computerized systems for the baseline controls this rests on.

A twin does not become lower risk because someone else runs the servers. If anything it gains a dependency you have to actively manage instead of one you can walk over and inspect yourself.

When the Twin and Reality Disagree

A monitoring log with a tripped threshold is an alarm. What happens next is an investigation, and it deserves its own discipline, because the instinct in the room is almost always to blame the model first, when the model is often the least likely cause.

There are, broadly, five places a twin-versus-reality gap can come from, and they call for different fixes.

Working the list roughly in that order matters, because it is cheap to check first and expensive to check last. Recalibrating or refitting a whole model over a titer probe that just needed cleaning is a common and avoidable overreaction, and it burns credibility with the people who have to sign off the next revalidation.

Whichever branch closes the investigation, the record should say so explicitly and name which of the five it was, because “resolved, monitoring continues” with no stated cause is the kind of closure an inspector reopens on the spot. A repeat finding of the same suspect, the same sensor drifting a second time, the same input creeping toward the boundary, is itself a signal that the fix from the first investigation did not hold, and that pattern belongs in the periodic review, not only in the individual investigation record.

This discipline is what turns a twin-reality mismatch from an ad hoc argument between the process engineer and the data scientist into a repeatable, documented root-cause process, and it is the basis for the twin-versus-reality discrepancy investigation form.

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.

A discrepancy investigation. Three batches into a new campaign, the twin’s titer estimate on one batch reads 0.3 g/L under the offline assay, outside the action limit. The team works the suspect list in order. The online probe’s calibration is current and the raw signal is physically plausible, so a sensor fault is ruled out in minutes. Timestamps and the data pipeline check out for the affected window. The batch’s conditions sit inside the documented boundary of validity. The monitoring log’s trend window shows the prior five batches all comfortably within limits, so this looks like a single-batch event, not model drift. That leaves the real process, and the batch record shows a longer-than-usual seed-train hold, not itself a deviation, that shifted the cell population’s physiological state in a way the twin’s mechanistic backbone does not represent. The investigation closes as a genuine process variation rather than a twin failure. The harvest decision for that batch is made on the offline assay per the defined response, and the seed-train hold duration is added as a monitored input for the next model review, since it is now a known, if rare, source of exactly this kind of gap.

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.
• No supplier or platform oversight for a vendor-hosted twin. Treating a cloud or vendor-run twin as outside the site’s quality system because IT owns the contract, with no visibility into the vendor’s own model version history or change notifications. The twin’s location does not change who is accountable for the GxP decision it informs.
• No cybersecurity segmentation between the twin and the control system. A twin platform bridges IT and OT by design, live process data in and, in a closed-loop use, a control influence out, and treating it like any other office application misses that it is now a path to a system that can affect product quality.
• A superficial discrepancy investigation. “Recalibrated and moved on” with no stated root cause, or the model gets blamed and refit before the sensor, the timestamps, or the boundary of validity were ever checked, burning a revalidation cycle on a problem a ten-minute calibration check would have found.
• No credibility evidence beyond an accuracy number. A validation report with an RMSE that meets spec and nothing else, so nobody, including the person who built it, can explain why the model produced a specific surprising prediction when someone asks. Accuracy on the validation set is necessary and it is not sufficient on its own.

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. I would also add that the drafting process itself is still moving. EMA held a stakeholder workshop on Annex 22 in mid-2026 and its own account of that session says the consultation responses showed some support for eventually allowing generative AI under a risk-based approach with guardrails, so the final line may move before it is locked. Until it does, I build to the current draft’s stricter reading, not the direction it might end up taking.

“The twin’s prediction and the lab result disagree on one batch. Walk me through what you do.” I do not start with the model. I check the sensor and its calibration first, then the data pipeline and timestamps, then whether the batch was inside the twin’s boundary of validity, then the monitoring trend to see whether this is a one-off or a pattern, and only then, if all of that is clean, do I treat it as a real process event and investigate the process itself. Most disagreements die in the first two checks, and jumping straight to “the model is wrong” burns a revalidation cycle on what usually turns out to be a probe that needed cleaning.

“How do you handle a digital twin that runs on a vendor’s cloud platform?” The same GxP obligations apply regardless of who hosts it. I make sure the shared-responsibility split with the vendor is written down, the supplier assessment reaches the model itself and not just the software, so I know what data trained it and how I am notified of a version change, and I treat the twin platform as a bridge between IT and the control system that needs its own network segmentation and access control. A CDMO-run twin gets the same oversight under the quality agreement; proprietary model internals are not a reason to withhold validation and monitoring evidence.

“Beyond the accuracy number, how do you know a model’s prediction is actually trustworthy on a given batch?” Accuracy tells me the model is usually right; it does not tell me why it is right or whether this specific prediction is one to trust. I run sensitivity checks to confirm the model responds to each input the way the underlying process actually behaves, and for the data-driven component I use an interpretability method so a reviewer can see what drove a specific prediction, treating that explanation as a diagnostic aid rather than proof. I write down, in the validation file, what would have to be true for this specific decision to trust this specific model, and show the evidence for each of those things, rather than letting one aggregate metric carry the whole argument.

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.