Review by exception: if nobody read the batch record, what did the release signature attest to?
Review by exception is good engineering and good quality practice. Automating the confirmation of four thousand in-specification entries frees a reviewer to think about the twelve that are not. The unresolved question is what the resulting signature means, because it looks exactly like the signature that used to mean something much larger.
If nobody read the batch record, what did the release signature attest to?
Review by exception is a legitimate approach: the system flags deviations and the reviewer examines those. The signature, however, is worded as though the whole record was reviewed, and nothing in it states the scope the reviewer actually applied.
- The signature is applied to a batch identifier, not to a scope statement. The object of the attestation is invisible in the record.
- Exception rules live in configuration that changes over time and is not hashed into the release. Two years later, nobody can reconstruct what counted as an exception on that day.
- A Scope-of-Review Statement makes the attestation legible: rule-set version, records auto-dispositioned, exceptions surfaced, exceptions examined.
Part of Pharma and GxP identity
The base rate this replaced
Start with the historical anchor. Paper batch record review meant a QA reviewer turning pages, initialling entries and checking arithmetic — typically several hours per batch, occasionally days for a complex product. The dominant failure mode was not missed exceptions; it was reviewer fatigue producing missed exceptions in the last third of the document.
Review by exception attacks that directly and it works. Vendors publish 40–60% reductions in review cycle time, and those figures are plausible because the underlying mechanism is sound: automate the confirmation of the conforming majority and direct human attention at the non-conforming remainder.
So this is not an argument against the practice. It is an argument about what the signature at the end of it says.
The attestation-scope problem
Under full review, a release signature meant: I examined this record. Under review by exception it means: I examined the entries that a rule set, configured at some point by someone, classified as requiring examination.
Both produce the same artefact — a signature against a batch identifier. An inspector reading the release two years later cannot distinguish them, and cannot determine which rule set was in force. That is the gap.
| What changed | Under paper review | Under review by exception |
|---|---|---|
| What the human examined | The document | A subset defined by configuration |
| Where the scope is recorded | Implicit — the whole record | Nowhere in the release |
| What governs the subset | Reviewer judgement | A rule set under change control, separately |
| Reconstructability at inspection | High | Requires correlating release date against configuration history |
The rule-set drift problem
Exception rules are not static. They are tuned: thresholds widen when a process stabilises, new parameters are added when equipment changes, rules are suppressed when a known nuisance alarm generates noise. Each change goes through change control, which is correct.
But change control records the change; it does not bind the rule-set version to the batches released under it. Reconstructing which rules applied to a batch released eighteen months ago requires a manual correlation between release timestamps and configuration change history, performed by someone who understands both systems. That reconstruction is exactly the kind of exercise that goes badly during an inspection.
The Scope-of-Review Statement
Four fields, hashed into the release signature. Nothing else about the workflow changes.
| Field | Content | Why it is load-bearing |
|---|---|---|
ruleset_hash | Hash of the exception rule set as configured at release time | Makes the governing configuration reconstructible from the release alone |
auto_dispositioned | Count and hash of entries the system cleared without human view | States plainly what the human did not examine |
exceptions_surfaced | The exception list presented to the reviewer | What the human was shown |
exceptions_examined | Which of those the reviewer opened, with dwell | The difference between presented and examined |
Now the signature says something precise: I examined these eleven exceptions, drawn from four thousand entries by this rule set, and I release the batch on that basis. That is a defensible attestation and it is also, importantly, the true one.
The reconstruction test
Run this before deciding whether the problem is real at your site. It takes an afternoon and produces an unambiguous answer.
- Pick a batch released eighteen to twenty-four months ago — far enough back that at least one rule-set change has intervened.
- Ask QA to determine, from the release record alone, which exception rules were in force.
- Time how long it takes and how many systems are consulted.
- If the answer requires anyone to open a change-control system, the release record is not self-describing.
Most sites fail this test, and most fail it in a way that is recoverable with effort — which is precisely why it is worth fixing before the effort has to be spent under inspection conditions.
What this does not require
It does not require reverting to full review, reducing automation, or changing the rule sets. It does not require the reviewer to open exceptions they have correctly judged not to need opening — the statement records what they did, not what someone thinks they should have done.
It requires the release record to describe its own scope. That is a data-model change in the MES release step, not a process change on the floor.
Why stating the scope helps everyone
| Party | Benefit |
|---|---|
| The reviewer | Their signature says what they actually did |
| Quality | The exception criteria become an auditable artefact |
| The inspector | A clear account rather than an implication |
| The company | No gap between the signature and the practice |
Review by exception is not the problem. An unstated scope is. A signature that says ‘I reviewed the flagged exceptions under criteria version 4.2, and the system verified the remainder’ is both accurate and stronger than one that implies more than was done.
Objections and honest limits
“Stating the scope invites challenge.” It invites a challenge to the exception criteria, which is the right place for one. The alternative is a challenge to the reviewer's personal diligence, which is worse for them and for the company.
“The procedure documents the approach.” At the procedure level. The signature is per batch, and it is the per-batch artefact that gets examined.
Adding a scope statement
- Record the exception criteria version. Inside the signed statement.
- Record what was flagged and reviewed. Counts and categories, not a narrative.
- Record what the system verified. So the division of labour is explicit.
- Keep the reviewer's wording accurate. Their signature should describe their act.
Terms used here
- Review by exception
- Reviewing only records the system flags as deviating, relying on automated verification for the remainder.
- Exception criteria
- The rules determining what gets flagged — the artefact the whole approach rests on.
- Batch record review
- The examination preceding release, which the release signature attests to.
Frequently asked questions
Does this imply review by exception is unsafe? No. The practice is sound and the cycle-time benefit is real. The argument is that the release record should state what the reviewer examined, which is currently invisible.
Would inspectors actually ask for this? They already ask what the reviewer examined and how exceptions are defined. The difference is whether the answer comes from the release record or from a reconstruction exercise.
How large is the implementation? It is a change at the release step: compute four hashes, include them in the signed statement. The rule engine and the review interface are untouched.
What about sites that still do full review? The same statement applies with auto_dispositioned set to zero, which is itself worth recording because it documents the stricter practice.
Is review by exception acceptable? It is a legitimate and widely used approach. The gap is that the signature implies a full review while the practice is narrower.
What should the signature state? The exception criteria version, what was flagged and reviewed, and what the system verified.
Does stating the scope weaken the record? It strengthens it. It moves any challenge to the exception criteria, which is where a challenge belongs.
Where this fits in Manav
Manav binds the signer to the exact record being certified, on a credential under their sole control, and produces a receipt an inspector can verify years later without access to the manufacturing system.
Sources and further reading
- 21 CFR 211.188 — Batch production and control records
- EudraLex Volume 4 — EU GMP guidelines
- Manufacturing execution system vendor documentation on review by exception methodology and published cycle-time reductions.
- RFC 8785 — JSON Canonicalization Scheme
- 21 CFR Part 11 — electronic records and signatures