In batch manufacturing, the same reactor might make a dozen different products in a week, and what changes between them is not the steel but the recipe. Recipe management is the discipline of authoring, storing, versioning, and dispatching those recipes so that every batch of a product is made the same way. This guide builds on the ISA-88 batch-control model to explain the recipe hierarchy that standard defines, how a recipe deliberately stays independent of the physical equipment, and why centralizing recipe management pays off in consistency and faster changeovers.
Recipe Management in one line: Recipe management is the practice of creating, versioning, and controlling the recipes that tell a batch process what to make and how. Under ISA-88, a recipe carries the product formula, the procedure, and the operating conditions - but not the specific equipment - and it exists at four levels of abstraction: general, site, master, and control. Managing these centrally means one approved definition of each product drives every batch, so results are repeatable and changes are tracked.
ISA-88 defines a recipe as a set of information that uniquely identifies a product and the way it is produced, and it separates that information into four levels so the same knowledge can travel from a corporate lab down to a specific reactor. A general recipe is equipment-independent and site-independent: it captures the product knowledge - the raw materials, the chemistry, the target conditions - the way a research or product-development group would express it, without reference to any plant. It is the enterprise's definitive statement of what the product is.
A site recipe narrows the general recipe to a particular plant, substituting local raw-material designations, site-specific constraints, and any regional regulatory requirements, while still not committing to individual pieces of equipment. From there a master recipe binds the recipe to a class of equipment at that site - it is the version that references a specific train or unit type and can actually be scheduled and executed. Finally, a control recipe is a working copy of the master recipe created for one specific batch, populated with that batch's order size, lot numbers, and the exact equipment allocated to it. Understanding these levels matters because a change made at the general level is meant to cascade down, while a control recipe is a transient, batch-specific instance.
The value of this layering is that product knowledge is authored once at the top and specialized as it descends, rather than being re-entered plant by plant. A reformulation approved as a general recipe can be pushed to every site that makes the product, and each site adapts only the parts that are genuinely local. Without the hierarchy, the same formula tends to get copied and quietly diverge across sites, which is exactly the drift that recipe management exists to prevent.
The defining idea of ISA-88 recipe design is that the recipe describes the procedure and formula in terms of what needs to happen, while the equipment provides the capability to make it happen through separately defined equipment control. A recipe procedure calls for an action such as heat to a target temperature, hold, and then transfer, expressed against generic equipment roles; the physical control system knows how a particular jacketed reactor or a specific pump accomplishes that. Keeping the two apart is what lets one recipe run on any suitable train and one train run any suitable recipe.
This separation is more than tidiness. When the recipe carries only the product formula and procedure, the same recipe can move to a different reactor during a maintenance outage without being rewritten, and a new product can be introduced by authoring a recipe rather than reprogramming the controllers. It also keeps engineering changes to the equipment - a replaced valve, a re-tuned loop - from silently altering product definitions, because the equipment-level logic is versioned independently from the recipe.
In practice the boundary is drawn at the parameters a recipe supplies: setpoints, durations, target masses, and sequencing choices flow from the recipe into equipment phases that already exist in the control system. The recipe author thinks in product terms, the controls engineer thinks in equipment terms, and the batch engine reconciles them at run time. Getting that boundary right is the single biggest factor in whether recipes stay portable or become tangled with a specific machine.
When recipes live in a controlled central store rather than scattered across individual controllers and spreadsheets, an operation gains three things that directly affect the plant floor. The first is consistency: there is one approved version of each product, so every batch draws from the same setpoints and the same procedure, and batch-to-batch variation shrinks. The second is versioning and traceability: every change to a recipe is recorded with who changed it, when, and why, so a quality investigation can tie a given batch to the exact recipe version that produced it. The third is changeover speed, because switching a train to a new product becomes a matter of selecting and downloading the right recipe rather than manually reconfiguring the process.
For teams that watch operations remotely, recipe management connects naturally to the monitoring layer. A cloud SCADA platform such as Merobix reads the live tags a batch produces - active step, phase state, temperatures, and quantities - and presents them beside the recipe and version that is running, so a supervisor away from the site can confirm the correct recipe was loaded and see how the batch is progressing against it. Recipe management defines the intent, and the monitoring layer shows the execution, which is the pairing operators rely on to catch a wrong recipe or a stalled phase early.
Beyond a single site, centralized recipes are what make multi-plant consistency achievable. In industries where the same product is produced at several facilities, a governed recipe hierarchy lets an organization push a validated formula everywhere and trend the results side by side, spotting a plant whose batches drift even though the recipe is nominally identical. That comparison is only meaningful when the recipe management system guarantees the recipes really are the same version, which is precisely the guarantee a disciplined recipe store provides.
A master recipe is the approved, reusable version bound to a class of equipment at a site - it is what you schedule and validate. A control recipe is a working copy of that master recipe created for one specific batch, filled in with that batch's order size, lot numbers, and allocated equipment. The master recipe persists; the control recipe is a transient instance that exists for the duration of a single batch.
So that one recipe can run on any suitable equipment and any equipment can run many recipes. The recipe describes the product formula and the procedure in generic terms, while the control system holds the equipment-specific logic that actually executes each step. This separation makes recipes portable across trains, lets new products be added without reprogramming controllers, and keeps equipment changes from silently altering product definitions.
It ensures there is a single approved version of each product's recipe that drives every batch, instead of setpoints being re-entered by hand or copied between controllers where they can drift. Because every batch pulls the same formula and procedure from a controlled store, batch-to-batch variation shrinks, and any change is versioned so investigators can tie a specific batch to the exact recipe that produced it.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.