This is a ready-to-use SOP for the human step that sits between an advisory digital twin’s output and the action it informs. The intended-use and risk classification record establishes who is accountable; the validation plan and monitoring log establish that the twin performs; neither one tells the accountable person, in the moment, what to actually check before confirming or overriding a specific output. This procedure fills that gap. It applies to advisory uses; for closed-loop control the equivalent control is the deterministic safety interlock and periodic performance review, not a per-output human check. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows.
Document control header
| Field | Entry |
|---|---|
| Document title | Reviewing a Digital Twin’s Output Before a GxP Decision |
| Document number | <<FILL: SOP-ID, e.g. SOP-TWIN-016>> |
| Version | <<FILL: version>> |
| Effective date | <<FILL>> |
| Document owner | <<FILL: role>> |
| Applies to | <<FILL: twin(s) and site(s) in scope>> |
1. Purpose
This procedure defines how the accountable role reviews a digital twin’s advisory output before using it to confirm, adjust, or override a GxP decision, so that the human control point required by the twin’s risk classification is real and demonstrable, not a formality.
2. Scope
Applies to every advisory-use digital twin output that feeds a GxP decision, as named in the twin’s intended-use and risk classification record. Does not apply to closed-loop uses, which are governed by the twin’s interlock validation and monitoring plan instead.
3. Responsibilities
| Role | Responsibility |
|---|---|
| Accountable role (named in the intended-use record) | Performs the review in section 5 before acting on the twin’s output; documents the decision. |
| System owner | Confirms the twin is in its validated state (correct model version, no open change or discrepancy investigation) and available for review. |
| Quality Assurance | Periodically reviews override rates and review-record quality per section 6; escalates a pattern consistent with automation bias. |
4. Definitions
- Confirm: the accountable role reviewed the twin’s output against the checks in section 5 and acted consistent with it.
- Override: the accountable role reviewed the twin’s output and acted differently from what it recommended, based on stated reasoning.
- Automation bias: the tendency to stop meaningfully reviewing a model’s output because it has usually been right, so that “confirm” becomes reflexive rather than a real check.
5. Procedure
5.1 Confirm the twin is fit to rely on right now
Before reviewing the specific output, confirm:
- The model version matches the currently approved version (no open, unapproved change per the twin’s change-control record).
- There is no open discrepancy investigation for this twin that has not yet been dispositioned.
- The most recent monitoring log entries are within the defined error and bias thresholds.
If any of these is not true, do not treat the output as validated evidence; fall back to the conventional measurement or escalate per <<FILL: escalation path>>.
5.2 Check the output against the boundary of validity
Confirm the batch or interval’s actual conditions fall inside the twin’s documented boundary of validity (inputs, scale, product, process conditions). If any input is outside that boundary, the output is not validated for this case regardless of how plausible it looks; treat it as out of range and fall back to the conventional measurement.
5.3 Sanity-check the output itself
- Compare the output to the expected trajectory or range for this point in the batch, using process knowledge, not only the twin’s own confidence.
- If the twin provides an uncertainty band, confirm the current output’s uncertainty is consistent with prior, similarly-behaved batches; a suddenly wide or suddenly overconfident band is itself a signal.
- Where available, compare against any partial or early conventional measurement as a cross-check.
5.4 Decide: confirm or override
- If sections 5.1 through 5.3 raise no concern, confirm and act on the twin’s recommendation.
- If any concern was raised, either resolve it against documented evidence before confirming, or override, acting on independent judgment instead, and state the reason.
- An override is not a failure to document quietly; it is exactly the control this procedure exists to produce evidence of.
5.5 Document the review
Record, for every output reviewed under this procedure: the output, the checks performed, the decision (confirm or override), and the reasoning if overridden. <<FILL: where this is recorded, e.g. the batch record or a dedicated review log>>.
6. Watching for automation bias
- Track the override rate over a rolling period.
<<FILL: e.g. rolling 90 days>>. - A persistently near-zero override rate is a prompt to investigate, not a mark of a well-performing twin; sample a set of “confirmed” reviews and confirm the checks in section 5 were actually performed, not just recorded.
- A sudden shift in the override rate, up or down, without a stated cause (a known process change, a twin change, a training refresh) is itself worth investigating.
- Report the override rate and any findings to QA per the cadence in
<<FILL>>.
7. Acceptance criteria
A review is acceptable when all of the following are true:
- The reviewer named is the accountable role from the twin’s intended-use record, or a documented delegate.
- Sections 5.1 through 5.3 were performed and are evidenced, not only the final confirm/override decision.
- Any override states its reasoning.
- The review is documented in the record named in section 5.5, complete and timely.
8. 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.
9. Record generated: output review record
| Field | Entry |
|---|---|
| Twin name / ID | <<FILL>> |
| Batch / interval | <<FILL>> |
| Twin output reviewed | <<FILL>> |
| 5.1 checks (version, open investigation, monitoring status) | <<FILL>> |
| 5.2 boundary of validity check | <<FILL>> |
| 5.3 sanity check | <<FILL>> |
| Decision | <<FILL: Confirm / Override>> |
| Reasoning (if override) | <<FILL>> |
| Reviewer / date | <<FILL>> |
10. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
11. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Reviewer (Process Science) | <<FILL>> | ||
| Approver (QA) | <<FILL>> |
Filled specimen
The following shows an output review record completed for the titer soft-sensor twin used in the paired article’s worked example, so you can see the expected detail. The values are illustrative.
| Field | Entry |
|---|---|
| Twin name / ID | Titer soft-sensor, bioreactor BR-204 |
| Batch / interval | BR204-2609-042, harvest decision point |
| Twin output reviewed | Titer estimate 4.4 g/L, harvest recommended now |
| 5.1 checks | Model version 2.1 matches approved; no open discrepancy investigation; last five monitoring entries within threshold |
| 5.2 boundary of validity check | All inputs within the documented ranges |
| 5.3 sanity check | Estimate consistent with the batch’s trajectory to this point; uncertainty band consistent with recent, similarly behaved batches; a partial in-line check corroborates the direction |
| Decision | Confirm |
| Reasoning | Not applicable (confirmed) |
| Reviewer / date | J. Alvarez, process engineer, 12-Sep-2026 |
A second, contrasting example from the same period shows an override: on batch BR204-2609-044 the twin recommended harvest at the estimated peak, but the sanity check in 5.3 found the uncertainty band unusually wide for this stage, wider than any of the prior ten batches at the same point, with no known process change to explain it. The engineer overrode, held the batch for the offline assay result before deciding, and logged the reasoning. The assay confirmed titer had not yet peaked; the override avoided an early harvest. The wide uncertainty band was later traced to a data-pipeline issue caught by the paired data-fidelity checklist, not a real biological signal, which is exactly the kind of catch this review procedure exists to produce.
Common inspection findings this SOP prevents
- “Confirm” recorded for every single review with no evidence any of the actual checks in section 5 were performed, indistinguishable from never reviewing at all.
- An override rate near zero over a long period, never investigated, with no way to tell whether the human control point is real or decorative.
- A decision made on a twin output with an open, undispositioned discrepancy investigation or a monitoring threshold already tripped.
- Overrides that happened but were never documented, so the review record cannot show the human control was actually exercised.
How to adapt this SOP
- Name the accountable role directly from the twin’s intended-use and risk classification record; do not leave this generic.
- Set the override-rate tracking cadence and threshold for what counts as “persistently near-zero” based on how often the twin is actually used.
- Point section 5.1’s fallback and section 6’s escalation path to your real conventional-measurement procedure and your real QA escalation route.
- Sample actual “confirm” records periodically and re-perform the checks independently; a review procedure that is never itself checked degrades the same way an unmonitored twin does.
- Confirm every standard in section 8 against the current published version before issue.