Batch Recipe Execution (BRE) – ISA‑88 Based Batch Orchestration

This topic is part of the SG Systems Global regulatory & operations glossary.

Updated November 2025 • ISA‑88, Batch Control, MES, PAT • Pharma, Biologics, Food, Chemicals

Batch Recipe Execution (BRE) is the automation layer that turns process recipes into repeatable, step‑by‑step equipment actions under the ISA‑88 batch‑control model. It orchestrates unit procedures, operations, phases and interlocks, drives equipment modules and captures detailed execution data into electronic batch records. In regulated manufacturing, BRE is where written instructions, automation, in‑process controls and data integrity all collide—if it is weak, no amount of documentation will save you from inconsistent execution.

“BRE is where the master recipe stops being theory and starts moving valves, starting agitators and writing to the batch record.”

1) What Batch Recipe Execution Actually Does

BRE is the runtime engine that reads a control recipe, sequences its steps and commands equipment modules to perform actions—charge, heat, agitate, hold, sample, transfer—while checking conditions and recording results. It sits between high‑level recipes and low‑level control logic, usually in a batch‑enabled MES or batch server integrated with PLCs/DCS and SCADA/HMI.

Without BRE, operators manually interpret procedures and type setpoints or open valves directly, which is fragile and hard to document. With BRE, the system enforces the intended sequence, prompts for manual actions at the right time, logs events and data automatically, and applies interlocks consistently. In GxP settings BRE is the primary mechanism to ensure that what was approved in the master batch record is actually what happens on the shop floor.

2) ISA‑88 Foundations – Procedural and Physical Models

Most BRE implementations are grounded in ISA‑88 (S88). The physical model (process cells, units, equipment modules) describes how assets are structured and shared. The procedural model (process, unit procedures, operations, phases) describes how work is broken down into manageable segments. BRE engines execute these phases on specific units, coordinating resources and managingstates.

Standards‑aligned BRE means that recipes are portable across like equipment, equipment modules can be reused across recipes, and capacity or scheduling decisions can be made more flexibly. It also means that validation, training and troubleshooting can be structured around a well‑understood reference, rather than home‑grown terminology and ad‑hoc logic buried in PLC code.

3) Master Recipes, Control Recipes and BRE

ISA‑88 distinguishes between master recipes (the approved template), control recipes (the instance for a specific batch) and recipe procedure (the ordered steps). A master recipe usually lives in recipe management; when a batch is planned, a control recipe is instantiated with batch‑specific parameters such as size, setpoints or potency adjustment factors.

BRE consumes the control recipe, binds its abstract operations to concrete units and equipment modules, and drives execution. In GxP environments, this chain must be fully traceable: the control recipe must be linked to the approved MBR/MMR, and the BRE log must feed back into the BMR or eBR as evidence of exactly what was executed, when and by whom.

4) Equipment Modules, Phases and Control Logic

Within BRE, equipment modules encapsulate the control capabilities of physical assets: a reactor’s jacket temperature loop, a transfer line, a dosing skid, a CIP module. Phases are the smallest executable steps: “Charge solvent from tank A to reactor R1”, “Heat to 70 °C”, “Hold for 45 minutes”, “Start agitator at 150 rpm”. The phase logic typically resides in PLC/DCS code, while BRE sequences phases and provides parameters.

Standards‑based design using S88 and concepts described in ISA‑88 phases & equipment modules simplifies validation and change control. When a phase is re‑used across many recipes, you validate its logic once and then verify correct parameterisation per recipe, instead of reinventing the wheel in every batch script or PLC program.

5) BRE, MES and SCADA/Batch Servers

Architecturally, BRE can live inside an MES, a dedicated batch server, or an integrated SCADA platform. The key is how it interacts with the rest of the stack. ERP sends orders and lot information; MES derives control recipes and allocates units; BRE coordinates execution across units; PLC/DCS executes closed‑loop control; historians and eBR capture data and events.

In GxP environments, each interface—orders, parameters, commands, acknowledgments and data—must be well understood and documented. Diagrams in the Validation Master Plan (VMP) and system‑lifecycle docs should show clearly where BRE sits, which records are primary, and how failures or communication loss are handled without compromising batch integrity.

6) Parameters, Scaling and Potency Adjustments

One of BRE’s most valuable roles is managing parameters: recipe setpoints, equipment limits, and batch‑specific adjustments. It must handle recipe scaling bases, batch size changes, dynamic recipe scaling, and compensation for active potency or solvent content as defined in concepts like potency assay adjustment and LOD adjustment.

In a robust design, BRE enforces parameter ranges, flags out‑of‑tolerance entries, and passes only validated values to the control system. Parameters are version‑controlled with the recipe, and any changes follow change‑control and QRM. This prevents silent drift in setpoints between batches and creates a clean, inspectable link between development intent, approved recipe and executed batch.

7) In‑Process Controls, PAT and Hard Gating

Modern BRE environments increasingly embed in‑process controls (IPC), process analytical technology (PAT) and hard electronic gates. For example, a phase might wait for an in‑line NIR assay to be within range before allowing a charge, or require dual verification of a critical calculation before moving to the next step.

These controls transform BRE from a simple sequencer into an enforceable quality gate. However, they also move quality decisions into the automation layer. That means PAT models, IPC limits, sample workflows and gating logic must be described in the control strategy, validated, and included in impact assessments and ongoing continued process verification. Poorly documented hard gates are a classic source of confusion in inspections and deviations.

8) Data Capture and Electronic Batch Records

BRE is a primary source of data for eBR, eMMR and, in device contexts, eDHR. It records phase start/stop times, parameters, operator acknowledgements, exceptions, alarms and status changes. Ideally, much of the GxP‑critical information is captured automatically from equipment and systems, with operators only entering information that cannot be sensed.

To meet 21 CFR Part 11, Annex 11 and data‑integrity expectations, BRE must enforce user authentication, role‑based permissions, secure time stamps and audit trails on recipe changes and manual interventions. The eBR or eDHR then acts as the legal record, with BRE providing the granular event log behind key steps and decisions.

9) Exceptions, Deviations and Quality Integration

No matter how well designed, batch execution will encounter exceptions: equipment failures, out‑of‑range measurements, missing materials, or operator errors. BRE defines how these are handled: pause and prompt, retry, require supervisor override, abort a unit procedure, or hold the entire batch. Each path has quality implications.

Strong designs integrate BRE with deviation and non‑conformance workflows, linking significant exceptions directly to NCR, CAPA and QRM records in the QMS. Procedures must explain which exceptions are “expected and controlled” within BRE and which require formal deviation, to avoid both over‑reporting noise and under‑reporting genuine quality events.

10) Validation and GAMP‑Aligned Lifecycle

Because BRE directly affects product quality, it is firmly within CSV scope. The BRE engine, its configuration tools, and representative recipes must be covered by URS, functional specifications, risk assessments, configuration specifications, testing and controlled deployment, following principles from GAMP 5 and the site’s V‑model.

Validation strategies typically combine platform qualification (the BRE/MES/batch server itself) with recipe‑level verification. Where recipes are created via controlled configuration, many organisations treat new recipes as validated configurations rather than custom software, with targeted testing and documented review. Either way, the logic that BRE executes—phase sequences, conditions, interlocks—must be demonstrably correct, traceable to requirements, and maintained under change control.

11) Recipe Versioning and Change Control

Changes to recipes—new steps, altered parameters, different equipment allocations—are unavoidable. Without discipline, they quickly create a zoo of near‑duplicate recipes, obscure differences between batches and confuse investigations. That is why recipe versioning and change control are core to BRE governance.

Good practice includes a single, controlled repository for master recipes; explicit version numbers linked to each batch; documented rationales and impact assessments for changes; and clear rules about when new versions require process validation or PPQ updates. BRE tooling should support these practices rather than fighting them—if it is easier to clone and tweak than to manage versions correctly, people will take shortcuts.

12) Capacity, Scheduling and Parallel Batches

In multi‑unit or multi‑product plants, BRE also has a capacity dimension. When several batches compete for the same units, transfer lines or utilities, the order and timing of BRE steps drive throughput, changeover effectiveness and OEE. BRE may work hand‑in‑hand with production scheduling and finite‑capacity job scheduling tools to allocate units and sequence campaigns.

This introduces additional complexity for validation and risk: for example, ensuring that campaigns respect cleaning and cross‑contamination control rules, allergen segregation and line‑clearance requirements. BRE must not allow “clever” optimisations to bypass constraints encoded in procedures and risk assessments. Scheduling logic that affects these constraints should be documented, justified and, where GxP‑relevant, validated like any other decision rule.

13) Implementation Steps and Brownfield Realities

Implementing BRE in an existing plant usually starts with an honest inventory of equipment, control systems, recipes and documentation. Legacy batch scripts, paper instructions and PLC code are mapped into the S88 model: which assets become units or equipment modules, which steps become phases, how existing interlocks and alarms are represented. Pilot recipes are selected for early implementation—ideally high‑value, high‑frequency products where benefits are clear.

From there, organisations iterate: stabilise the architecture, establish recipe‑governance processes, migrate more recipes, and gradually integrate BRE with eBR, historians and QMS. Brownfield plants often need compromises—some manual steps remain outside BRE, or older equipment cannot be fully automated initially—but the goal is consistent: to move critical actions and records into a controlled, auditable, centrally managed batch‑execution environment over time.

14) Roles, Training and Daily Use

In daily operation, BRE touches many roles. Operators interact with BRE screens and HMIs, acknowledging steps, entering manual readings, and responding to prompts. Process engineers design and maintain recipes. Automation engineers manage equipment modules and phase logic. Quality reviews exceptions, changes and batch records. Planners coordinate with BRE to schedule campaigns.

Training must therefore cover both the how and the why: how to run, pause and resume batches; how to respond to alarms and exceptions; when to escalate to a deviation; and why certain fields or steps are mandatory. As with any powerful system, misuse—skipping prompts, using “dummy” values, or manually bypassing interlocks—can erode control. A mature BRE culture treats the system as part of the quality architecture, not just a convenience for operations.

15) FAQ

Q1. How is BRE different from MES or SCADA?
BRE is a functional slice, not a product category. It may live inside an MES, a SCADA/batch server or a dedicated platform. Its job is to execute batch recipes using S88 concepts, orchestrating equipment and logging events. MES typically covers broader functions such as order management, genealogy and performance reporting; SCADA focuses on real‑time monitoring and control. BRE sits at their intersection.

Q2. Do we need full ISA‑88 compliance to benefit from BRE?
No, but the closer you align to ISA‑88, the easier it becomes to scale, validate and maintain recipes. Partial adoption—using units, equipment modules and phases without a perfect model—is still better than ad‑hoc batch scripts. Over‑time, most organisations move toward cleaner S88 structures as they feel the pain of inconsistent designs.

Q3. How should recipe changes in BRE be controlled?
Treat recipe changes like any other GxP‑relevant configuration change. Use formal change‑control processes, impact assessments, documented approvals, testing proportional to risk, and clear versioning tied to batches. Link significant changes to risk assessments, validation files and, where appropriate, process‑validation or CPV updates.

Q4. Can AI or optimisation tools automatically change BRE parameters?
Not without governance. Algorithms that directly adjust critical parameters or steps effectively become part of the control strategy and must be validated and controlled. In most GxP settings, AI and analytics are used to recommend changes, with humans reviewing and approving updates to recipes or setpoints within the BRE framework.

Q5. What is a pragmatic first step toward BRE in a legacy plant?
A practical starting point is to select one process cell or product family and map its existing instructions and control into an S88 model. Implement BRE for that scope, integrate with eBR and historians, and prove value and robustness. Use the lessons learned to define standards for recipes, equipment modules and governance before rolling out to the rest of the site.

Related Reading
• Batch Standards & Design: ISA‑88 Batch Control | Phases & Equipment Modules | Batch Reactor Control | Recipe Management | Recipe Versioning
• Execution & Records: MES | eBR | eMMR | eDHR | IPC | Hard Gating
• Quality, Risk & Validation: CSV | GAMP 5 | QRM | Deviation/NC | CAPA | VMP