Ask ten MES administrators what “review by exception” means and you’ll get ten versions of the same shrug: “it’s the thing where the system only flags problems.” True, as far as it goes. But that definition is exactly why so many implementations of it are weak. Review by exception isn’t a feature you switch on. It’s a rule design problem, and if you don’t do the design work, you’ve just built a slower, more expensive way to review everything anyway — or worse, a fast way to miss something a regulator will ask about later.
This piece walks through how to build the ruleset properly: what counts as an exception, how e-signature triggers should be scoped, how escalation paths need to work, and where the whole approach breaks if you’re sloppy about it. We’ll use a discrete-to-batch hybrid line as the running example, because that’s where the logic gets genuinely interesting — you’re not just watching a reactor temperature, you’re reconciling a PLC-driven assembly step with a batch-process step in the same genealogy record.
What “exception” actually means in an EBR
An electronic batch record (EBR) captures every parameter, action, and confirmation tied to a batch: material lots consumed, process values logged, operator confirmations, in-process checks, equipment IDs. Full manual review means a quality reviewer reads through all of it, batch after batch, looking for anything abnormal. That’s slow, and it’s also not a great use of a trained reviewer’s attention — most of what they’re reading is unremarkable by design, because the process is in control.
Review by exception flips the model: the system pre-screens the record against a defined ruleset, and the human reviewer only sees the parameters, deviations, or workflow steps that failed to conform. Everything that stayed inside spec, on time, and correctly signed gets summarized rather than re-reviewed line by line.
The part people skip is that this only works if you can prove, structurally, that “no exception raised” really does mean “in control.” That’s a design claim, not a feature claim. If your rule engine can’t see a parameter, or your escalation path silently swallows a flag, you don’t have review by exception — you have review by omission, and that’s the thing that gets cited in a data integrity finding.
Step one: classify every parameter before you write a single rule
Before touching rule logic, you need a parameter classification exercise, and this is where most projects go wrong by rushing straight to configuration. Every parameter captured in the batch record falls into roughly three buckets:
- Critical Process Parameters (CPPs): values that directly affect product quality or safety if they go out of range — reactor temperature during a hold step, fill weight tolerance, torque on a safety-critical fastener. These almost always warrant a hard limit check and, on deviation, a mandatory e-signature and disposition decision.
- Critical Quality Attributes tied to in-process checks: things like pH, viscosity, or dimensional measurements taken mid-process, where an out-of-spec reading needs investigation before the batch proceeds, not just at final release.
- Non-critical or informational parameters: ambient conditions, non-critical timestamps, operator ID confirmations that succeeded on the first attempt. These generate data, but a deviation in them (a five-second timing variance, say) shouldn’t ever reach a human reviewer.
This classification should come out of your existing process risk assessment — the same FMEA or hazard analysis work that underpins your control strategy — not out of what the historian happens to log. If a parameter is critical enough to control, it’s critical enough to justify a review-by-exception rule. If it isn’t, don’t build a rule for it, because every unnecessary rule is a future false positive, and false positives are what kill reviewer trust in the system.
Step two: define the exception, not just the limit
A limit check (“temperature exceeded 85°C”) is not the same thing as an exception rule. A real exception rule specifies: the parameter, the limit or condition, the duration or frequency threshold, the required response, and who gets notified. For example: “Reactor jacket temperature exceeding 85°C for more than 30 continuous seconds during Hold Step 3 requires operator acknowledgment within 5 minutes and triggers mandatory QA review before batch disposition.” That’s a rule. “Temperature > 85°C” is just a number with no workflow attached.
You also need rules for things that aren’t out-of-spec values at all: a required e-signature that wasn’t captured, a step performed out of sequence, a material lot substitution, an operator override of an interlock, a manual data entry where automated capture was expected. In a lot of EBR systems, these workflow deviations cause more real compliance exposure than a parameter drifting slightly out of range — and they’re exactly the kind of thing a naive “just flag out-of-spec numbers” configuration misses entirely.
The discrete-to-batch hybrid wrinkle
On a hybrid line — say, a line where a discrete robotic assembly cell feeds into a batch chemical treatment step — the exception ruleset has to bridge ISA-88 batch phases and ISA-95/discrete execution events in one genealogy. A torque reading from the assembly cell (discrete, PLC-sourced, often reported as pass/fail) and a bath temperature profile from the treatment step (batch, continuous, trend-based) don’t fail the same way, and they shouldn’t be scored by the same rule logic. Trying to force both into one generic “deviation” table is a common mistake: you end up either drowning the batch-process rules in discrete pass/fail noise, or missing the fact that ten consecutive “marginal pass” torque readings on the discrete side is itself a trend worth escalating, even though no single reading breached a limit. Build separate rule families for discrete-sourced and batch-sourced data, then define a small number of cross-domain rules — genealogy mismatches, timing gaps between the two systems, missing handoff confirmations — as their own category.
Step three: scope e-signature triggers deliberately
Under 21 CFR Part 11 and equivalent EU Annex 11 expectations, e-signatures need to mean something specific: an accountable person attesting to a specific fact at a specific point in time. The mistake plants make is either over-triggering signatures (every minor deviation demands one, so reviewers start signing on autopilot) or under-scoping them (a single blanket signature at final release supposedly covers every deviation that occurred upstream, which won’t hold up under scrutiny).
The design principle: an e-signature trigger should map to a decision, not an event. A CPP excursion should trigger a signature from the person making the disposition call — accept, reject, or investigate — not a signature that just says “I saw this.” If your rule fires a signature request for something the reviewer has no actual decision authority over, you’re generating signature fatigue, and signature fatigue is a direct path to the kind of rubber-stamping that data integrity audits are specifically designed to catch.
Step four: build escalation paths that can’t fail silently
An exception is only useful if it reaches someone who can act on it, in a timeframe that matters. Escalation design needs three things most configurations skip: a defined timeout (if the first-line reviewer doesn’t act within a set window, it escalates automatically — it doesn’t just sit in a queue), a defined escalation target that’s a role, not a named person (so it survives shift changes and turnover), and an audit trail entry for the escalation itself, not just the original exception. If your system can generate an exception that nobody acknowledges and nothing logs that fact, you have a gap that will surface eventually, usually during an audit rather than during normal operations, which is the worst possible time to find it.
It’s also worth deciding, explicitly, what happens to the batch while an exception is unresolved. Does the line hold? Does the batch proceed under a documented risk acceptance? Different exception classes should have different answers, and that mapping needs to be in the rule design, not left to whoever’s on shift that day.
Why this pays off — and where it doesn’t
Done well, review by exception genuinely cuts batch release time, because reviewers spend their attention on the small number of records that actually need judgment instead of re-reading records that were fine. It also improves review quality, somewhat counterintuitively — a reviewer looking at three real exceptions gives each one more attention than a reviewer skimming page forty of a routine record.
Done poorly, it creates a documentation gap dressed up as efficiency. Regulators evaluating electronic batch records increasingly ask not just “did you catch the deviation” but “can you show us why your system was designed to catch it, and what happens when it doesn’t.” A checkbox implementation has no good answer to that question. A designed ruleset — with documented parameter classification, explicit exception logic, deliberate signature scoping, and escalation paths that log their own failures — does.
As MES vendors roll AI-assisted anomaly detection into review-by-exception modules, that documentation burden doesn’t go away — it moves. An AI model flagging “unusual” patterns still needs a human-reviewable rationale for why something wasn’t flagged, and plants adopting these tools during renewal cycles should expect to spend at least as much time on validation and rule justification as they did designing the rules by hand in the first place.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
