A computed result is acceptable in a GxP lab under the same condition as an instrument result: a reviewer who was not there can reconstruct what was done, with what, by whom, and see whether anything changed afterwards. For an instrument that means raw data, method, audit trail and a second-person review. For a model-based result it means the same four things plus two more that instruments do not have: the version of the model and the version of the input data, both pinned to the moment the result was produced. Everything else in this article follows from that.
What belongs in the record
A defensible record of one computed result holds:
| Field | Why a reviewer needs it |
|---|---|
| Input data, unaltered, with a checksum | The result cannot be reproduced without the exact input, and the checksum shows the input did not change afterwards |
| Input provenance | Which instrument, file, system or person the input came from, and when |
| Model or algorithm identifier and version | A different version is a different method |
| Parameters and options used | The same model with other settings is a different procedure |
| Software environment version | Library versions change numerical results |
| Output, complete | Not only the headline number: intervals, flags, warnings, all endpoints computed |
| Timestamp and user | Who triggered the run, in a traceable time reference |
| Review record | Who reviewed, when, with what verdict, and the reasoning for any deviation accepted |
| Any reprocessing | Every repeat run with its reason, visible next to the original, never replacing it |
The last row is where data integrity cases usually start. A second run that overwrites the first, with no record of the first, is the computational equivalent of a discarded injection.
Versioning: the part that is genuinely new
Instruments drift and get recalibrated; models get retrained. The difference matters because a retrained model can change a result without anything visible changing in the procedure.
Three rules keep that under control:
1. Immutable versions. A model version, once used for a GxP result, is never modified. A change produces a new version with a new identifier. The old version stays available for as long as the records refer to it. 2. Pin, do not follow. A validated procedure names a specific version. It does not say "the current model". Updating to a new version is a change, assessed through change control, with a documented decision on whether revalidation or a comparability study is needed. 3. Keep the lineage. For each version: what changed, the data it was built from, the qualification evidence and the date it entered and left use. This is the document a reviewer or inspector will ask for first.
Reproducibility and its limits
"Same input, same result" is the expectation. Several things break it legitimately, and each needs handling rather than hiding:
- Non-deterministic computation. Parallel reductions, GPU kernels and sampling methods can give slightly different numbers between runs. Fix the random seed where one exists, record it, and state a numerical tolerance within which results count as identical.
- Library and hardware changes. A different numerical library version shifts digits. Pin the environment, for example as a container image with a digest, and treat an environment change as a change.
- Generative or sampling-based steps. Where the method is inherently stochastic, reproducibility of the exact output is not achievable. Then the record must hold the complete output of the run that was used, and the procedure must define how the result is judged, not re-derived.
State in the validation documentation which category your procedure is in. Claiming bit-identical reproducibility and failing to deliver it in an inspection is worse than defining a tolerance up front.
Review by exception, applied to computed results
Reviewing every computed result line by line does not scale and is not what data integrity guidance asks for. The workable pattern mirrors chromatographic review by exception:
- Define in advance which conditions require human attention: a flag that the input is outside the range the method was qualified for, an interval wider than a stated threshold, a reprocessing event, a result crossing a specification or action limit.
- Let the system record everything and surface the exceptions.
- Review all exceptions, document the reasoning, and keep a periodic sampled review of the non-exceptions to show the exception logic works.
This only holds if the flags themselves are qualified. A domain or confidence flag that is part of the review logic is part of the validated procedure and needs its own evidence.
Where this sits in the regulatory landscape
The underlying requirements are not new: EU GMP Annex 11 for computerised systems, 21 CFR Part 11 for electronic records and signatures, the MHRA and PIC/S data integrity guidance for ALCOA+ attributes, and GAMP 5 second edition for a risk-based approach, extended by the FDA's computer software assurance guidance in 2025. For AI specifically, EU GMP Annex 22 addresses the use of artificial intelligence in GMP, and ICH Q14 covers analytical procedure development including computational elements. Check the current status and text of each before you design your approach; the direction of all of them is the same, which is that the burden of proof sits with the user of the model, not with its supplier.
What this means practically: a supplier audit and a certificate do not transfer validation. The user qualifies the procedure for their intended use, on their data, with their acceptance criteria.
Limits of the statement
- An audit trail proves what was done, not that the result is correct. Scientific qualification of the method is a separate exercise.
- Record retention for model versions can exceed the lifetime of the software that ran them. Plan for how a result will be reconstructable in ten years, which usually means archiving the environment, not just the code.
- Data integrity requirements differ by jurisdiction and by application. The table above is a working baseline, not a substitute for the applicable regulations and your own quality system.
Frequently asked questions
What does a GxP audit trail for a computed result have to contain?
Input data with a checksum and provenance, the model or algorithm with its version, the parameters, the software environment version, the complete output including intervals and flags, timestamp and user, the review record, and every reprocessing with its reason.
Can a model be updated during the lifetime of a validated procedure?
Yes, through change control. The procedure pins a specific version; moving to a new version is assessed for impact, with a documented decision on revalidation or a comparability study, and the old version stays available while records refer to it.
How do you handle a method that is not bit-reproducible?
Define it as such in the validation documentation: record the seed where one exists, pin the environment, state a numerical tolerance within which two runs count as the same, and keep the complete output of the run actually used.
Does a supplier certificate replace validation?
No. Supplier evidence can reduce the user's effort, but qualification for the intended use, on the user's data and against the user's acceptance criteria, remains with the user.
Can review by exception be used for computed results?
Yes, if the exception conditions are defined in advance, the flags that trigger them are themselves qualified, all exceptions are reviewed and documented, and a periodic sampled review of the remainder demonstrates the logic works.