Review by exception is an outcome, not a setting

Review by exception appears in almost every business case for a manufacturing execution project, usually as a percentage. Review time falls because reviewers stop reading every line of every record and look only at what the system flagged as outside expectation.

The mechanism is sound. What the business case tends to skip is that this is not a mode you enable — it is a consequence of the system being trustworthy enough that a regulator, and your own quality unit, will accept its judgement about what was normal.

What you are actually asking to be believed

Reviewing by exception is a claim: everything not shown to the reviewer was within its expected range, and the system determined that correctly. Three things have to hold for that claim to survive scrutiny.

1. The limits were right. Which means they came from the approved specification, are under change control, and their history is visible — not typed into a configuration screen by whoever set up the recipe.
2. The values were real. A value typed by an operator has already passed through a human before the system judged it. The judgement is then only as good as the transcription underneath it.
3. The judgement is evidenced. An audit trail has to show what was evaluated, against what, and when — otherwise "the system checked it" is an assertion rather than a record.

You are not asking a reviewer to read less. You are asking them to trust a classification — which has to be earned in the design, not claimed at go-live.

Why transcription undermines it more than people expect

The weakest link is usually the origin of the in-process value. If an operator reads a display and types the number, the record shows what was typed, at the time it was typed, by a person who is also the one confirming it is correct. The second-person verification exists precisely to compensate for that.

Reading the value from a process historian changes the shape of the problem: the record references a measurement that already exists, with the timestamp the device emitted and the quality code the protocol carried. The reviewer is no longer being asked to trust a transcription — they can follow the value back to the raw event.

This is the same requirement that data integrity and ALCOA+ impose for entirely separate reasons, which is a useful coincidence: the architecture that satisfies the regulator is the one that makes review by exception affordable.

The failure mode: exceptions that mean nothing

The other way this goes wrong is quieter. Limits set too tight, or configured without process input, generate flags on batches that were entirely fine. Reviewers learn that most exceptions are noise, start clearing them quickly, and the review becomes less rigorous than the exhaustive one it replaced.

The signals that this is happening are visible before anyone admits it:

• the same exception recurs on most batches and is always closed the same way
• closure comments are copied between records
• the time spent per exception falls steadily while the count stays high

The fix is not fewer checks — it is limits that reflect the actual process capability, revised through change control when the process teaches you something. An exception should be rare enough that seeing one changes what the reviewer does next.

What to settle before promising the number

If a project plan already contains a review-time reduction, these are the questions that decide whether it is achievable:

• Where does each in-process value come from — a device, or a keyboard?
• Are limits versioned and traceable to the specification they came from, or editable in place?
• Can the audit trail evidence a specific evaluation on a specific batch, or only that a change occurred?
• Has quality agreed, in writing, what an exception-free record entitles a reviewer to skip?

That last one is the one most often deferred, and the one that stalls go-live. It also belongs in the validation scope rather than in a separate discussion after the system is running.

Where it fits

Review by exception is a property of a well-designed electronic batch record, not a module to buy — our note on what an EBR actually changes covers the enforcement side. Both sit inside manufacturing execution and the broader digital compliance posture that makes the classification defensible in the first place.