This is a ready-to-use validation plan for a digital twin whose output informs a GxP decision. A twin is a computerized system and a model at the same time, so this plan separates the two questions an inspector will separate: was the model built right (verification) and does it predict the real process well enough for its intended use (validation). Replace every <<FILL: ...>> placeholder with your own specifics and route it through your normal document control. A filled specimen of the intended-use and risk sections follows. Verify each cited standard against the current source before you rely on it. There is no guidance that names digital twins, so this plan reasons from established principles and records where it does so.
Approval page
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Validation / CSV) | <<FILL>> | ||
| Reviewer (Process Science) | <<FILL>> | ||
| Reviewer (Data Science) | <<FILL>> | ||
| Reviewer (Automation / Engineering) | <<FILL>> | ||
| Approver (QA) | <<FILL>> |
1. Document control header
| Field | Entry |
|---|---|
| Document title | Validation Plan, Digital Twin for <<FILL: process / asset>> |
| Document number | <<FILL: PLAN-ID, e.g. VP-TWIN-007>> |
| Version | <<FILL: version>> |
| Twin name / ID | <<FILL: TWIN NAME / ID>> |
| Physical asset bound to | <<FILL: specific vessel / unit, e.g. bioreactor BR-204>> |
| Model version | <<FILL: model version under validation>> |
2. Scope
This plan covers the verification and validation of the <<FILL: TWIN NAME>> digital twin, its model or models, its live data path from sensors to output, and the human or engineered controls around its use. It covers the twin as deployed for the intended use in section 4. It does not cover the underlying equipment qualification or the base control system, which are qualified separately under <<FILL: equipment / automation validation refs>>.
3. Approach and standards basis
The twin is validated risk-first: the effort scales to the consequence of the twin being wrong, sized under ICH Q9(R1). The plan reasons from 21 CFR Part 11 and EU GMP Annex 11 for the records and the computerized system, ICH Q8 for the process understanding the model encodes, and ICH Q10 for the quality system it operates inside. Where no guidance fits the twin cleanly, the plan documents the reasoning by analogy. The draft EU Annex 22 on artificial intelligence (published for consultation 7 July 2025, not in force) is treated as direction of travel: the twin’s data-driven component is locked for its GxP use so that it reads as a static, deterministic model, and any change runs through change control rather than continuous learning in place.
4. Intended-use statement (the anchor)
State, in one sentence, what the twin outputs, what action that output triggers, and who owns the consequence. Everything downstream is sized from this.
<<FILL: e.g. The twin estimates product 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.>>
5. Risk classification
Classify the use and record the rationale. The class justifies the depth of everything that follows.
| Use pattern | Selected? | Rationale |
|---|---|---|
| Development advisory (informs scientific judgment) | <<FILL>> | <<FILL>> |
| Scale-up prediction (shapes commercial design) | <<FILL>> | <<FILL>> |
| Advisory control (human decides on the twin’s estimate) | <<FILL>> | <<FILL>> |
| Closed-loop control (model drives the action) | <<FILL>> | <<FILL>> |
| Commercial monitoring (alerts or gates batch) | <<FILL>> | <<FILL>> |
Assigned risk class: <<FILL: e.g. High (advisory control)>>. ICH Q9(R1) rationale reference: <<FILL>>.
6. Model description
<<FILL: describe the model family (mechanistic, data-driven, or hybrid), what each part covers, and how the parts interact. For a hybrid, name the mechanistic backbone and the data-driven component and state which variables each estimates.>>
7. Verification approach (built right)
Confirm the model is implemented correctly, independent of whether it predicts well:
- The equations are the intended equations and unit conversions are correct.
- The numerical solver converges and is stable across the operating range.
- The code matches the specification.
- For the data-driven component, the training pipeline does what it claims and the training data is version-controlled and reproducible.
8. Validation approach (right model)
- Acceptance criteria set before testing. Define the accuracy metric and threshold, tied to the consequence of error, before any validation run. See section 9.
- Independent data. Validate predictions against real process data the model was never built or fitted on, ideally from batches run after the training data. Report performance on this held-out set only.
- Across the operating range. Include the edges where decisions are most consequential, not just the center.
- Boundary of validity. Document the ranges of inputs, scales, products, and conditions inside which accuracy was demonstrated (section 10).
- Integration, not just the model. Validate the whole path from sensor to output to decision (section 11).
9. Acceptance criteria
| Criterion | Metric | Threshold | Basis |
|---|---|---|---|
| Accuracy | <<FILL: RMSE or MAE in the variable's units>> | <<FILL: threshold>> | <<FILL: what the decision can tolerate>> |
| Bias | Mean error | <<FILL: allowed bias, directional>> | <<FILL: why a directional error matters>> |
| Uncertainty coverage | Prediction-interval coverage | <<FILL: e.g. a 95% interval contains truth ~95% of the time>> | Honest uncertainty |
| Range performance | Accuracy at the edges | <<FILL: threshold at the extremes>> | Edge decisions are consequential |
10. Boundary of validity
| Dimension | Validated range | Outside-range behavior |
|---|---|---|
| Inputs | <<FILL>> | Flag or refuse to predict |
| Scale | <<FILL>> | Not validated; do not use |
| Product(s) | <<FILL>> | Not validated; do not use |
| Process conditions | <<FILL>> | Flag |
The system must handle an out-of-range condition explicitly (flag the prediction as out of validated range or refuse it), never produce a confident number outside the boundary.
11. Data-path integration
Validate that the twin computes on correct, timely, correctly-attributed data:
- Sensor accuracy and calibration status feeding the twin.
- Time alignment of multi-source data and controlled latency.
- Defined handling of missing, late, or implausible inputs (flag, do not silently substitute).
- Traceable lineage from sensor to twin to output, so a prediction can be reconstructed.
- The displayed output is bound to the correct batch.
12. Human oversight and interlocks
| Use | Human control |
|---|---|
| Advisory | A qualified person stands between the twin and the action and owns the decision; guard against automation bias by watching the override rate. |
| Closed-loop | Deterministic safety interlocks, validated independently of the model, hold the process inside engineered limits regardless of the prediction; plus periodic human review of performance. |
13. Change control and predetermined change plan
Model and data-path changes run through change control. Classify anticipated changes in advance so routine maintenance is controlled rather than treated as an unplanned deviation. See the paired change-classification approach in the digital twin article and the change control for validated systems procedure.
14. Monitoring plan
A monitoring plan is live from day one: periodic comparison of the twin’s prediction against the actual measured outcome, tracking of error and bias over time, defined thresholds, and a defined response when a threshold is tripped (typically suspend the twin’s role and revert to the conventional measurement while investigating). A twin with no monitoring is not in a validated state.
15. Deliverables and roles
| Deliverable | Accountable |
|---|---|
| Intended-use statement and risk class | Process / System Owner |
| Verification evidence | Validation / CSV lead |
| Validation report against independent data | Validation lead + Process Science |
| Boundary-of-validity definition | Process Science + Data Science |
| Interlock validation (closed-loop) | Automation / Engineering |
| Monitoring plan and records | System Owner + Process Science |
| Final release for GxP use | Quality Assurance |
16. Acceptance (release gate)
The twin is released for GxP use only when the file evidences every line: approved intended-use statement, assigned risk class with rationale, verification evidence, a pre-specified accuracy specification met on independent data across the range, a documented boundary of validity with out-of-range handling, a validated data path, validated interlocks where the twin acts, and a live monitoring plan.
17. References
21 CFR Part 11; EU GMP Annex 11 (Computerised Systems, in-force 2011 version; track the draft revision of 7 July 2025 and the draft Annex 22 on artificial intelligence). ICH Q8 (Pharmaceutical Development), Q9(R1) (Quality Risk Management), Q10 (Pharmaceutical Quality System).
Confirm the current version of each reference before issue.
Filled specimen
The following shows the intended-use and risk sections completed for an example titer soft-sensor twin, so you can see the expected detail. The values are illustrative; replace them with your own.
Intended-use statement: The twin estimates product titer in real time for mammalian cell-culture bioreactor BR-204; the estimate informs the harvest-timing recommendation to the process engineer; the engineer confirms or overrides and owns the harvest decision. The offline titer assay continues to run and is the record of truth; the twin is not on the critical release path.
Risk class: High (advisory control). Rationale: the twin’s estimate influences harvest timing, which affects yield and can affect a quality attribute, but a qualified engineer stands between the estimate and the action and owns the decision, so it is advisory rather than closed-loop. ICH Q9(R1) rationale on file at QRA-TWIN-2026-003.
Acceptance criterion (accuracy): titer estimate 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.
In this example the intended-use statement names the output, the action, and the accountable person cleanly, which is what lets the rest of the plan be sized correctly. The risk rationale explains why the class is advisory and not closed-loop, and the acceptance criterion is tied to a specific, directional consequence of error rather than a generic “accurate enough.”
Common inspection findings this plan prevents
- A twin used outside its validated range because no boundary of validity was documented.
- Validation reported on the data the model was fitted to, so the headline number was flattering and the twin underperformed in production.
- Verification and validation conflated, so one of the two questions was never actually answered.
- A correct model fed by a mis-mapped or uncalibrated sensor, because only the model, not the data path, was validated.
- Deploy and forget: no monitoring, so there was no evidence the twin still predicted accurately months later.
How to adapt this plan
- Write the intended-use statement first and get it right; everything else is sized from it.
- Select the single risk class that matches the real use and record the ICH Q9(R1) rationale.
- Set the accuracy metric, threshold, and bias limit to values tied to what your decision can tolerate, before you validate.
- For a closed-loop use, specify the deterministic interlock and validate it independently of the model.
- Stand up the monitoring plan on day one, not after the first drift.
- Confirm every standard in section 17 against the current published version before issue.