This is a ready-to-use investigation form for the moment a digital twin’s prediction and the measured outcome disagree beyond the monitoring log’s action limit. The instinct in the room is almost always to blame the model first, and the model is usually the least likely cause. This form works a fixed suspect order, sensor, data pipeline, boundary of validity, model drift, then the real process, cheapest to check first, so the investigation does not burn a revalidation cycle on a problem a calibration check would have found. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. Verify each cited standard against the current source before you rely on it.
Form control
| Field | Entry |
|---|---|
| Form title | Digital Twin Versus Reality Discrepancy Investigation |
| Document number | <<FILL: FORM-ID, e.g. FRM-TWIN-014>> |
| Twin name / ID | <<FILL>> |
| Batch / interval affected | <<FILL>> |
| Linked monitoring log reference | <<FILL: LOG-ID and row>> |
| Opened by / date | <<FILL>> |
1. What triggered this investigation
| Field | Entry |
|---|---|
| Predicted value | <<FILL: value and units>> |
| Actual (reference method) value | <<FILL: value and units>> |
| Error | <<FILL: value>> |
| Action limit tripped | <<FILL: value>> |
| Is this a single-batch spike or part of a trend? | <<FILL: reference the monitoring log's trend window>> |
2. Suspect sequence
Work the rows in order. Do not skip to Suspect 4 or 5 without recording why Suspects 1 through 3 were ruled out; an inspector will ask for that trail.
| # | Suspect | Check performed | Evidence | Ruled in / out |
|---|---|---|---|---|
| 1 | Sensor or instrument fault | Calibration record and raw-signal plausibility for the affected input(s) | <<FILL>> | <<FILL>> |
| 2 | Time misalignment or data-pipeline break | Timestamp alignment, latency, and pipeline logs for the affected window | <<FILL>> | <<FILL>> |
| 3 | Input outside the boundary of validity | Batch’s actual conditions against the documented boundary of validity | <<FILL>> | <<FILL>> |
| 4 | Model degradation (drift) | Monitoring log trend window for a sustained, one-directional bias across recent batches | <<FILL>> | <<FILL>> |
| 5 | Genuine process shift | Batch record review for a material, equipment, or biological change once 1 through 4 are ruled out | <<FILL>> | <<FILL>> |
3. Root cause and closure
| Field | Entry |
|---|---|
| Closing suspect (1 through 5) | <<FILL>> |
| Root cause statement | <<FILL: plain-language cause, tied to the evidence in section 2>> |
| Was the twin’s output used in a decision before this was caught? | <<FILL: Yes/No; if Yes, describe the decision and its disposition>> |
| Is this a repeat of a prior finding (same suspect, same twin)? | <<FILL: Yes/No; if Yes, reference the prior investigation>> |
4. Corrective and preventive action
| Field | Entry |
|---|---|
| Immediate action | <<FILL: e.g. sensor replaced, pipeline fixed, twin's role suspended>> |
| Was a change record opened? | <<FILL: Yes/No; if Yes, reference the change-control record>> |
| Preventive action (if this could recur) | <<FILL: e.g. add the seed-train hold duration as a monitored input>> |
| Effectiveness check planned | <<FILL: what will be watched, and for how long>> |
5. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Investigator | <<FILL>> | ||
| Process Science | <<FILL>> | ||
| Data Science | <<FILL>> | ||
| QA | <<FILL>> |
6. 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).
Confirm the current version of each reference before issue.
Filled specimen
The following shows the form completed for the titer soft-sensor twin used in the paired article’s worked example, so you can see the expected level of detail. The values are illustrative; replace them with your own.
| Field | Entry |
|---|---|
| Twin name / ID | Titer soft-sensor, bioreactor BR-204 |
| Batch affected | BR204-2609-041 |
| Predicted value | 3.9 g/L |
| Actual value | 4.2 g/L |
| Error | -0.3 g/L (limit 0.15) |
| # | Suspect | Check performed | Evidence | Ruled in / out |
|---|---|---|---|---|
| 1 | Sensor fault | Probe calibration due date and raw-signal review | Calibration current, signal physically plausible across the run | Out |
| 2 | Time/pipeline | Timestamp alignment and pipeline log for the batch window | No gaps, no restart events, alignment confirmed | Out |
| 3 | Boundary of validity | Batch conditions vs. documented ranges | All inputs inside the validated ranges | Out |
| 4 | Model drift | Monitoring log trend, prior five batches | All five within limit, no directional bias | Out |
| 5 | Real process shift | Batch record review | Seed-train hold ran 6 hours longer than typical, not itself a deviation | In |
Root cause statement: the extended seed-train hold shifted the cell population’s physiological state in a way the twin’s mechanistic backbone does not represent, producing a real but twin-invisible change to titer trajectory. Not a twin failure.
Was the twin’s output used before this was caught? No. The action limit tripped on the offline assay comparison before the estimate was used for the harvest-timing recommendation; the offline assay drove the harvest decision per the monitoring log’s defined response.
Preventive action: seed-train hold duration added as a monitored input candidate for the next scheduled model review; not an immediate model change, since a single occurrence does not justify a structural revalidation.
In this example the fixed suspect order did the work: four cheap checks closed clean in under an hour, and the fifth, the one that actually required judgment and a batch-record review, found a real and previously unmonitored source of variation. That is a better outcome than either extreme, assuming the model was broken and refitting it for no reason, or assuming the process was fine and letting the estimate keep informing harvest timing without understanding why it was off.
Common inspection findings this form prevents
- The model blamed and refit before the sensor, timestamps, or boundary of validity were checked, so a routine instrument issue triggered an unnecessary revalidation.
- A discrepancy closed as “resolved” with no stated root cause and no suspect ruled in or out on record.
- A repeat of the same suspect across multiple investigations that nobody connected, because each investigation was a standalone form with no reference back.
- A twin’s output used in a real decision before or during an open discrepancy investigation, with no record of whether that decision needs review.
How to adapt this form
- Keep the suspect order fixed. It exists specifically so cheap checks happen before expensive ones, and reordering it defeats the purpose.
- Link every investigation back to its monitoring log row and, if one exists, any prior investigation with the same closing suspect.
- Route any finding that closes as a model or data-path cause into the digital twin change-control procedure, not into a silent fix.
- Confirm every standard in section 6 against the current published version before issue.