This is a ready-to-use SOP for the change that a validated digital twin will eventually need: a parameter refit, a sensor swap, a new input, a structural change to the model, or a request to use the twin somewhere its validation never covered. A twin’s validated state is not “the model that was released”; it is a defined boundary plus a defined process for changing what sits inside it. Without a predetermined classification, every refit looks like either an unplanned deviation or a rubber stamp, and neither is defensible. Replace every <<FILL: ...>> placeholder with your own specifics and route it through your normal document control. A filled specimen follows. This is educational reference to adapt to your own quality system; verify each cited standard against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Document title | Digital Twin Model and Data-Path Change Control |
| Document number | <<FILL: SOP-ID, e.g. SOP-TWIN-011>> |
| Version | <<FILL: version>> |
| Effective date | <<FILL>> |
| Supersedes | <<FILL: prior version or "New">> |
| Document owner | <<FILL: role, e.g. Head of Digital Quality>> |
| Applies to | <<FILL: sites / twins in scope>> |
1. Purpose
This procedure defines how a change to a digital twin, its model, its live data path, or the scope it is used for, is classified, tested, approved, and recorded, so that the twin’s validated state is a controlled and traceable thing rather than an assumption. It applies once a twin has completed the validation described in its validation plan and is in its released GxP use.
2. Scope
This procedure covers changes to any digital twin whose output informs a GxP decision at the sites listed in the header: changes to model parameters, the data-driven component’s training, the mechanistic equations or model architecture, the sensors or data sources feeding the twin, and requests to extend the twin’s use into a new scale, product, or condition. It does not cover the initial validation of a new twin, which is governed by <<FILL: validation-plan SOP or reference>>, and it does not replace the base equipment or automation system’s own change control, which continues to apply in parallel.
3. Responsibilities
| Role | Responsibility |
|---|---|
| System owner | Receives the change request, performs the initial classification, and coordinates the required testing. |
| Data Science | Executes model-side changes (refit, retrain, architecture change) and the associated technical verification. |
| Process Science | Assesses whether the change affects the process understanding the twin encodes and whether the boundary of validity is affected. |
| Automation / Engineering | Executes and verifies changes to sensors, data paths, or the live integration. |
| Quality Assurance | Confirms the classification is correct, approves the change record, and confirms the twin is not returned to GxP use until its class’s requirements are met. |
4. Definitions
- Validated state: the combination of model version, training data version, boundary of validity, and data-path configuration that was shown to meet the twin’s acceptance criteria at release or at the last approved change.
- Confirmatory check: a targeted test against the existing locked validation data or acceptance criteria, used to show a routine change did not move the twin outside its validated state.
- Revalidation: a full or partial repeat of the validation activities in the twin’s validation plan, required when a change is structural or extends the boundary of validity.
- Boundary of validity: the documented range of inputs, scale, product, and process conditions inside which the twin’s accuracy was demonstrated, defined in the twin’s intended-use and risk classification record.
5. Procedure
5.1 Log the change request
Record what is changing, why, and who requested it, before classifying it. A change with no stated reason cannot be classified correctly. <<FILL: change-request log or system reference>>.
5.2 Classify the change
Classify the request against the table below. Select the row that matches; if a change spans more than one row, classify at the highest applicable level.
| Change type | Example | Required action | Who approves |
|---|---|---|---|
| Routine parameter refit, same structure, in-range data | Re-estimate kinetic constants on new campaign data | Confirmatory check against locked validation data; must meet the original acceptance specification; documented record | System Owner + QA |
| Recalibration or replacement after a sensor change | New probe model or vendor feeding an existing input | Re-verify the input path (units, range, timing); confirm twin accuracy unchanged on a confirmatory check | Automation/Engineering + System Owner |
| New input or data source | Add an online measurement to the model | Targeted revalidation of the affected accuracy; data-integrity review of the new source; update the data-path validation | Data Science + QA |
| Structural model change | Replace or add mechanistic equations, change the model architecture, change the data-driven component’s algorithm | Full revalidation against the acceptance criteria; reassess the boundary of validity and the intended-use statement | Validation lead + QA |
| Boundary-of-validity extension | Use the twin at a new scale, on a new product, or outside a previously documented condition | Validate in the new region before use; do not extrapolate on trust; update the boundary-of-validity record | Process Science + Validation lead + QA |
| Platform or vendor-side change (cloud/hosted twins) | Vendor pushes a platform or shared-model update | Confirm via the supplier change-notification agreement; treat as the equivalent row above based on what actually changed | System Owner + QA |
5.3 Execute the required testing
- For a confirmatory check, run the twin against the locked validation data or the current monitoring reference and confirm the result meets the original acceptance specification. Do not create a new, looser threshold to pass a change.
- For a targeted or full revalidation, follow the applicable sections of the twin’s validation plan, using independent data the change was not built or fitted on.
- Record the model version and training-data version before and after the change, so the change is reconstructable.
5.4 Hold the twin’s GxP role during the change
The twin’s GxP role (advisory or closed-loop) is suspended for the affected use from the moment a change is executed until the required testing in section 5.3 passes and QA approves. The prior validated version remains in force for any decision made during that window, or the conventional measurement is used, per the twin’s monitoring log defined response.
5.5 Approve and release the change
- Complete the change record (section 8) including the classification, the testing performed, the result, and the versions affected.
- QA reviews and approves before the twin returns to its GxP role.
- Update the intended-use and risk classification record and the boundary-of-validity record if either was affected.
- Communicate the new model version to anyone relying on the monitoring log or the twin’s output.
5.6 Handle a failed confirmatory check or failed revalidation
If the testing in section 5.3 does not meet the acceptance specification, the change does not proceed. Investigate whether the intended change itself was flawed, whether the underlying model needs more than a refit, or whether the acceptance specification needs a documented, QA-approved review (not a quiet loosening). The twin stays out of its GxP role until a change passes.
6. Acceptance criteria
A change is acceptable for release when all of the following are true:
- The change was classified using section 5.2 before testing began, and the classification is on record.
- The testing required for that classification was completed and met the pre-existing acceptance specification.
- The twin’s GxP role was suspended for the duration of the change and testing.
- The model version, training-data version, and (where affected) the boundary of validity and intended-use statement were updated.
- QA approved the change record before the twin returned to its GxP role.
7. References
ICH Q9(R1), Quality Risk Management; ICH Q10, Pharmaceutical Quality System. 21 CFR Part 11; EU GMP Annex 11 (Computerised Systems, in-force 2011 version; track the draft revision published 7 July 2025, not in force). Draft EU Annex 22 on artificial intelligence (published for consultation 7 July 2025, not in force as of this writing); treat as direction of travel, not a binding requirement.
Confirm the current version of each reference before issue.
8. Record generated: digital twin change record
| Field | Entry |
|---|---|
| Twin name / ID | <<FILL>> |
| Change description | <<FILL>> |
| Requested by / date | <<FILL>> |
| Classification (from 5.2) | <<FILL>> |
| Testing performed | <<FILL>> |
| Result vs. acceptance specification | <<FILL: pass/fail with values>> |
| Model version before / after | <<FILL>> |
| Training-data version before / after | <<FILL>> |
| Boundary of validity affected? | <<FILL: Yes/No, detail>> |
| GxP role suspended from / to | <<FILL>> |
| QA approval (name, signature, date) | <<FILL>> |
9. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
10. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Reviewer (Data Science) | <<FILL>> | ||
| Reviewer (Process Science) | <<FILL>> | ||
| Approver (QA) | <<FILL>> |
Filled specimen
The following shows a change record completed for the example titer soft-sensor twin used throughout the paired validation plan and article, so you can see the expected detail. The values are illustrative; replace them with your own.
| Field | Entry |
|---|---|
| Twin name / ID | Titer soft-sensor, bioreactor BR-204 |
| Change description | New raw-material supplier qualified for the primary nutrient feed, shifting the nutrient profile slightly |
| Requested by / date | Process Science, 03 September 2026 |
| Classification | New input characteristics, treated under the “recalibration or replacement” row since the existing input is retained but its composition shifted |
| Testing performed | Confirmatory check: twin accuracy assessed on the first three batches run with the new material against the original acceptance specification |
| Result vs. acceptance specification | Pass. Error within the pre-specified limit on all three batches; no directional bias observed |
| Model version before / after | 2.1 / 2.1 (unchanged, no refit required) |
| Training-data version before / after | v14 / v14 (unchanged) |
| Boundary of validity affected? | No |
| GxP role suspended from / to | 03-Sep-2026 to 09-Sep-2026 (three-batch confirmatory window) |
| QA approval | R. Gomez, signed, 10-Sep-2026 |
In this example the change looked, at first glance, like it might need a full refit, since the nutrient supplier changed. The classification exercise avoided that assumption: because the input itself was retained and only its composition shifted modestly, a confirmatory check against the existing specification was the right-sized response, and it passed. Had the error exceeded the specification, the classification would have escalated to a targeted revalidation before the twin could resume its advisory role.
Common inspection findings this SOP prevents
- A model refit performed with no classification, no predetermined criteria, and no QA visibility before the twin resumed its GxP role.
- “Update the twin” treated as one undifferentiated activity, so a structural model change gets the same light-touch confirmatory check as a routine parameter refit.
- A vendor-pushed platform update that changed the model’s behavior with no record that the site even knew it happened.
- A failed confirmatory check quietly resolved by loosening the acceptance threshold instead of investigating the change or escalating to revalidation.
- No suspension of the twin’s GxP role during a change, so a decision was made on a model mid-change.
How to adapt this SOP
- Set your document number, owner, and effective date in the header.
- Point section 2’s cross-reference to your actual validation-plan SOP or reference for new twins.
- If your twin platform is vendor-hosted or cloud-deployed, confirm the supplier agreement actually obligates the vendor to notify you of a platform or shared-model change before you rely on the last row of the classification table.
- Keep the acceptance specification in section 6 identical to the one in the twin’s validation plan; a change SOP that quietly uses a different bar than validation used is a gap an inspector will find.
- Confirm every standard in section 7 against the current published version before issue.