Insights & Research · ⟨Pilar : MES / PAS-X⟩
Review by exception: what design decides, and what it does not
The exception volume a site lives with after an MES go-live is not a fact of the process. Most of it is written into master data and batch record structure before the first batch runs. But not all of it, and confusing the two shares is how sites lose the benefit of review by exception
By Adam, Senior Consultant MES · ⟨01-10-2026⟩ · 8 min read
Picture a site three months after go-live. Operators are trained, the confusion of the first weeks is behind them, and the exception rate has stopped falling. Two readings compete: the process is what it is and the system is showing it, or the design is producing noise and the process has little to do with it.
In my experience the second is right far more often. Telling them apart requires knowing what an exception is made of, and which decisions, taken months earlier, determine how many a site will see.
What review by exception actually covers
Review by exception moves the batch review from every recorded value to what the system has flagged as a departure. Everything else is covered by the system’s validation and by the checks enforced during execution.
That second point is the one that matters. On paper, completeness is verified after the fact: an empty field, a missing signature, a skipped step are found at review, sometimes weeks later. In an MES, completeness is enforced while the batch runs: the operator cannot move on until the step is closed. This transfer of control from reviewer to execution engine is what makes review by exception possible, not the screen replacing the binder.
Which is why an electronic batch record and review by exception are not the same thing. An EBR can be executed electronically and still be read page by page at release. Review by exception needs a documented risk justification for what is not reviewed, an exception report a reviewer can work from, and a review procedure rewritten around it.
What is still reviewed systematically: exceptions and their resolution, overrides and their justification, data corrections, free-text comments, data from systems outside the MES scope, the audit trail on a risk basis, open quality events. The reviewer’s attention is concentrated, not removed, and the release responsibility stays where the site’s quality system places it.
What creates an exception
An exception is a comparison that fails. The system compares a value, acquired or entered, to an expectation declared in master data: type, unit, format, limits. It compares an execution event to a rule declared in the recipe: step order, prerequisites, equipment status, material status, operator qualification. Any gap creates an exception.
That gives two families: value exceptions, where a measurement is out of limits, and process exceptions, where a step was forced out of sequence, equipment was not released, a material was in the wrong status, an operator was not qualified. On the sites I have worked on, process exceptions were more numerous and generated more discussion than value exceptions. Yet design effort concentrates almost entirely on the second family. The first is where most avoidable volume hides.
For each parameter, the behaviour on departure is configurable. In the systems I have seen configured and discussed, PAS-X among them, four behaviours cover most cases: a simple warning; a warning requiring a signature; a blocking deviation with mandatory correction before the batch can proceed; and an override, allowed with a comment and an electronic signature, generally restricted to production supervisor or quality profiles and traced. Naming, rights and the content of the exception report vary with site and version. What does not vary is that every one of them is a decision, taken by someone, at design time.
The decisions that determine the avoidable volume
Four decisions carry most of the weight. None is a system setting. All are taken before the recipe is built, and each becomes expensive to revisit past a certain point.
Parameters and limits in master data
Which parameters are critical, and which type of check applies to each. This is decided when master data is specified, before any recipe exists. A parameter declared blocking generates an exception on every batch where it departs, for the life of the product. The question to ask is not “should we check this?” but “what happens on every batch when this check fires, and who deals with it?”
Granularity of phases and operations
How finely the procedural model cuts the process. A fine cut means more control points and signatures, so more exceptions, but each one precisely located and diagnosable. A coarse cut means few exceptions, but unreadable ones, and the shop floor compensates with paper notes on the side, the very outcome the MES was meant to remove. It is also the costliest to correct afterwards, for a reason developed below.
Blocking policy
Whether a departure blocks, or alerts. The first-implementation reflex is to declare everything blocking, out of caution. It is the largest single generator of avoidable volume. Every non-critical departure becomes a blocking event, then an override, then a standard comment typed without reading. Control is not strengthened, it is diluted: when every exception looks the same, the ones that matter are lost among the ones that do not. The design work is to separate alert limit from action limit, and reserve blocking for critical attributes.
Global template and local adaptation
On a multi-site programme, a harmonised model brings consistency and a shared validation base. It also brings limits set somewhere else. A template whose limits ignore a site’s capability leaves that site with structural exceptions it cannot correct alone. The question to settle before local design is one of governance: who may change a limit, the site or the programme, and through which route. Left open, it gets answered by default in the worst way: nobody can.
One practical point runs through all four. The conversation that produces workable rules starts with the production supervisor, who knows whether a rule can be held at the station, and ends with quality assurance, which arbitrates. Reverse the order and you get rules that are right and unworkable. I have seen both; the difference shows within a month.
Two traps I have seen more than once
Trap 1
Copying the paper procedure instead of specifying
What the team thinks it is doing:
Transcribing existing practice faithfully.
What actually happens:
Every operating instruction, including the informal ones nobody ever enforced, becomes a check the system will enforce on every batch.
The lesson:
The paper procedure was tolerant by nature. The system is not
Trap 2
Not specifying the exception report
What the team thinks it is doing:
Relying on a standard report. Nobody on the shop floor asks for it, because nobody there uses it.
What actually happens:
It surfaces at the first review, when reviewers find it doesn’t show what they need and rebuild the review by hand.
The lesson:
The exception report is a design object, like the recipe. It deserves a specification, a user and a test.
What design does not decide
Not every exception is noise.
A parameter whose real spread sits close to its limit will produce exceptions under any configuration. So will a measurement chain that drifts, or a process step whose variability was accepted on paper and is now visible on every batch. These exceptions are the signal: what the system was installed to show. They belong to the process, not the design.
The distinction matters because the corrective action differs. Noise goes back to master data and structure. Signal goes to the process, the instrumentation, or a conversation with quality assurance about whether the limit reflects reality. Sending either to the wrong team wastes both.
Two readings help separate them. The first is time: the exception rate in the first weeks measures how fast operators are learning the system, the rate three months later measures the design. Judging a configuration on the go-live month is a reading error, in both directions.
The second is shape. Noise repeats: same parameter, same step, same override comment, batch after batch, on product released conforming. Signal moves: it follows a raw material lot, a piece of equipment, a shift. When the exception log looks like a stamp, the design is talking. When it looks like a curve, the process is. And when it is empty, nothing is being checked.
What cannot be fixed after go-live
Each of the four decisions above can, in principle, be changed in production. In practice the cost splits into two groups, and the line between them is not where project teams expect it.
Any correction in production goes through the site’s change control: impact assessment, targeted revalidation, a new recipe version. Hypercare handles the first group well: outright configuration errors, wrong master data, a screen operators cannot use. These changes are localised: the impact assessment bounds the effort, the retest covers what was touched plus a regression set, and the change goes through.
The second group is different: a granularity that does not fit, a blocking policy set too wide, a harmonised model that ignores site capability. What makes them expensive is not the size of the change but the burden of proof. For a structural change to a generic master batch record (gMBR), demonstrating that the rest of the record is unaffected becomes harder than retesting all of it. A full retest is then not a regulatory requirement, no text mandates it. It is simply the cheapest way left to produce the evidence.
This is why granularity is the decision whose correction costs the most afterwards: it is the one whose non-regression is hardest to prove. And it is why the cost is invisible at initial design, when there is nothing to prove yet. The proof obligation appears once the record has run in production, exactly when the decision can no longer be changed cheaply.
Sites that discover this in month three rarely reopen the design. They wait for the next upgrade and live with the noise.
KEY TAKEAWAY
An exception rate that has stopped falling three months after go-live is rarely a shop floor problem. It is an audit to send back to design: master data, granularity, blocking policy. The process has its share, but it only becomes visible once the design noise is removed. The time to remove it is before the first batch, when there is nothing yet to prove.
A note on the regulatory ground
No GMP text names review by exception. The texts frame the ground it stands on: validation, data integrity, review responsibility. EU GMP Annex 11 states the principle in one sentence: “Where a computerised system replaces a manual operation, there should be no resultant decrease in product quality, process control or quality assurance.” It adds that “there should be no increase in the overall risk of the process.” Clause 6 asks for an additional accuracy check on critical data entered manually, which validated electronic means may provide; clause 9 asks for audit trails that are “regularly reviewed”.
Reading review by exception as something Annex 11 authorises is interpretation, not text. What the text asks is that the overall risk of the process does not go up. A design that fills the exception report with noise, and trains reviewers to override without reading, is the most direct way to make it go up. None of this is regulatory advice; it is how I read the ground.
Where this leaves you
Deciding what the system checks, and what it does when the check fails, is the part of an MES project hardest to see from a project plan, and the one the site lives with afterwards. It is where Adelka spends most of its time on MES and digital manufacturing engagements, with validation and compliance as the frame rather than the afterthought.
One question to leave you with: When a value goes out of limits with no quality impact, does your system block, or alert?
Author
Adam El Kafi leads Adelka, a Life Sciences consultancy focused on PAS-X MES and electronic batch records in European GMP environments.
He brings seven years in pharmaceutical manufacturing, across sterile prefilled syringes, oral solid dosage and packaging.
On PAS-X, he works on the design side: master data, generic master batch records and equipment specifications, and he has owned several gMBRs from design through to execution in production.
He writes about the design choices that shape how an MES behaves long after go-live: exception volume, batch record review effort and validation workload.
