A digital twin commissioned to mirror a manufacturing process is, by design, built to keep learning. It ingests live sensor data, recalibrates its internal parameters, and narrows the gap between what it predicts and what the physical process is actually doing. That’s exactly what makes it useful. It’s also exactly what breaks an assumption baked into almost every computer system validation approach we currently have: that a system’s configuration and intended use are fixed at the point of validation, and that any deviation from that fixed state is a discrete, identifiable “change.”
A twin that adapts continuously doesn’t hand you discrete changes to catch. It hands you a slope. And a validation framework built to catch discrete changes has no natural trigger for a slope.
Why current guidance and current literature don’t fully close the gap
FDA’s Computer Software Assurance guidance [1] is a genuine shift in how the agency wants manufacturers thinking about validation: away from testing every function exhaustively regardless of risk, toward assurance activities scaled to actual likelihood and severity of harm. That matters here, but it was written with software changes in mind (a release, a configuration update, a patch), each with a clear start and end point that a change-control process can capture and route through the right level of testing.
GAMP 5 Second Edition [2] pushes that same risk-based logic into a structured category system. It tells you how to scale rigor to risk, on the assumption that the system holds still long enough to be categorized in the first place.
GAMP 5 and CSA both hold up well within that boundary. A digital twin built to keep learning from live data sits outside it by design.
The literature is starting to notice the same problem from a different angle. ISPE’s own trade coverage now describes tech-transfer digital twins that watch critical parameters against a qualified design space in real time and kick off a deviation or CAPA workflow the moment those parameters move [3]. A 2026 retrospective on pharmaceutical validation lists digital twins, right alongside AI model drift monitoring, among the things that went from theoretical to operational in the last five years [4]. Outside pharma entirely, a quality framework built specifically for digital twins (Testing, Evaluation, Verification and Validation, or TEVV) treats continuous validation as table stakes, not a nice-to-have, and calls for automated comparison of a twin’s outputs against real-world data on an ongoing basis [5]. What none of it tells you, in trade press or academic literature alike, is the actual number: how much drift, measured against what, over what window, before a system that was validated stops being the system that’s actually running. That’s the gap worth closing here, not restating what’s already been said.
Reframing the trigger: drift threshold as change control
The practical answer isn’t to revalidate on a fixed calendar, and it isn’t to treat every recalibration as a formal change requiring full re-verification either. The former under-protects; the latter grinds the twin’s usefulness to a halt. The better approach is to define, at initial validation, the boundary within which the twin is allowed to drift from the process it represents, and treat a breach of that boundary as what actually triggers re-verification, not a date or a deployment.
This isn’t a hypothetical mechanism. It already exists, just not dressed in GxP language yet. A 2026 framework for self-adaptive digital twins in additive manufacturing detects concept drift statistically, triggers a narrowly scoped update touching a sliver of the model’s parameters, and runs a formal statistical test confirming the updated model actually outperforms the one it would replace before that replacement is allowed to happen [6]. Swap “statistical test” for “documented, risk-based validation evidence” and “model update” for “scoped re-verification,” and the mechanism maps almost exactly onto GxP change control. The engineering answer is already out there. GxP validation just hasn’t given it a name yet, or a place in the risk assessment.
FDA’s guidance on predetermined change control plans for AI-enabled device software [7] already accepts, for a different category of regulated software, that a model can be validated once against a pre-approved envelope of future change rather than resubmitted every time it updates inside that envelope. Pharmaceutical manufacturing doesn’t have an equivalent for the digital twins now sitting inside its production and quality processes, and it should. ICH Q9(R1) [8] already hands the field the vocabulary to justify where a drift threshold belongs: risk-based decision-making, scaled to how severe and how detectable the consequence would be if the twin’s output diverged from reality. The gap isn’t conceptual. It’s that almost nobody is writing these thresholds into their initial risk assessments as a deliberate choice; they’re leaving it as an implicit decision nobody actually made.
Four things follow from treating a drift threshold, rather than time or a code change, as the trigger:
- Set the threshold at initial validation, as risk-assessed evidence, not as an operational afterthought decided informally once the twin is already live.
- Build drift monitoring into the system itself. A threshold nobody is actively watching isn’t a control. It’s a documentation exercise.
- Document the threshold’s rationale the way you’d document a test case, as part of the validation record, ready for an auditor asking why that number and not another.
- Scope re-verification to what actually changed when a threshold is breached, instead of defaulting to a full revalidation that treats every drift event like a ground-up system replacement.
The drift record itself deserves the same data-integrity discipline as any other GxP record: attributable, contemporaneous, traceable under 21 CFR Part 11 [9], and documented inside the manufacturer’s quality management system consistent with ISO 13485:2016 [10]. Not an informal engineering dashboard sitting quietly outside the regulated record set.
The EU Annex 11 angle
The current draft of Annex 11 [11] still frames validation and change control around identifiable, documented changes to a computerized system, the same assumption running through everything above. It doesn’t yet speak to a system whose intended behavior is designed to keep shifting. That’s a real gap, worth naming rather than working around quietly, and it’s not only a European one. As of 2026, the FDA evaluates digital twins case by case within existing regulatory pathways, and the UK’s MHRA requires the same models to clearly define intended use, risk classification, and oversight before they can influence regulated outcomes; neither has established a standalone digital twin approval pathway [4]. Which means a clear, risk-based reading of the principles we already have, not a wait for new rules, is the only practical option on the table right now.
Closing that gap doesn’t need new regulatory text. Annex 11’s existing risk-based principles and its periodic review requirement already support a straightforward reading here: for a continuously adaptive system, periodic review is triggered by a threshold breach, not by the calendar. That’s an interpretation manufacturers can adopt today, not something to wait for in the next revision.
The point
A digital twin that never changed after go-live wouldn’t be worth building in the first place. What the industry needs isn’t a validation approach that pretends adaptive systems hold still; it’s one that treats the boundary of acceptable change as the thing actually being validated, monitored, and defended, continuously rather than once. The mechanism for doing this already exists in adjacent engineering fields. GxP validation’s job now is to give it a name, a threshold, and a place in the risk assessment, not to invent it from scratch.
Author Bio
