Master Recipe

ISA-88 defines four recipe levels: General → Site → Master → Control. The Master Recipe is where abstraction stops and execution begins. It binds the product-and-process intent (from the site recipe) to one specific physical line: this reactor, this drier, this packaging cell, with this PLC phase library and this set of validated IPCs.

• Header — product, strength, presentation, target batch size, allowable bracket.
• Equipment requirements — specific unit class (e.g. 2,000 L jacketed reactor) and any required attributes (CIP-capable, low-shear impeller, vent filter rating).
• Procedure — the procedural-control hierarchy (procedure → unit procedure → operation → phase) wired to the chosen units.
• Formula — the bill of materials with component roles (active, excipient, processing aid), tolerances, and substitution rules.
• Process parameters — setpoints, ramp rates, hold times, agitation profiles.
• IPCs — sampling plan, methods, acceptance criteria, hold/release logic on failure.
• Required signatures — preparer + independent reviewer; QA approval before status moves to Active.

The Master Recipe is the bridge. Above it sits product/site knowledge; below it sits per-batch execution. It is the artefact a regulator audits when they ask "show me how this product is made on this line".

• Draft — author drafts from a site-recipe template or existing master recipe.
• In Review — independent reviewer challenges every parameter, IPC, equipment assignment.
• QA Approval — QA reviews change-control record, validation linkage, training implications.
• Active — released for use; new work orders can clone control recipes from this version.
• Superseded — replaced by a newer Active version; historical batches still trace back.
• Obsolete — product discontinued or line decommissioned; read-only forever.

When a work order is released, the entire Master Recipe (every step, every component, every IPC, every signature requirement) is copied into the work order as a JSONB snapshot. From that moment the control recipe runs against the snapshot, not the live master.

• If the master is revised mid-run, the in-flight batch continues against the snapshot.
• If the master is revised between WO release and start, the WO still runs against the snapshot taken at release.
• The BMR / batch record renders from the snapshot, so the regulator sees what the operator saw.
• Forensic queries ("what version produced lot X?") return the snapshot, not the current master.

Tech transfer (sending site → receiving site, or scale-up from pilot) is where the Master Recipe earns its keep. The general recipe and site recipe travel with the product; the receiving site authors its own Master Recipe against its own equipment. The PPQ (process performance qualification) batches run against that Master Recipe, and only after PPQ is approved does the master move to Active for commercial production.

• Equipment-train mapping — receiving-site unit classes mapped to sending-site units.
• Scale adjustment — agitation, heat transfer, mass transfer adjusted for new geometry.
• IPC re-qualification — methods transferred and verified at the receiving lab.
• PPQ batches — three or more consecutive batches against the new master; data feeds CPV.

• Treating the Master Recipe as a Word document — no versioning, no snapshot, no audit trail.
• Editing Active in place to "correct a typo" instead of revising.
• Master Recipe references unit class generically; the control recipe later runs on an unqualified unit.
• IPC acceptance criteria authored as "per current SOP" — SOP changes silently invalidate the recipe.
• No linkage from Master Recipe to validation evidence (cleaning, sterilisation, IPCs); auditor cannot trace.
• Multiple Active versions for the same product/line — execution layer picks the wrong one.
• Master Recipe not snapshotted at release; BMR rendered from live master after a mid-run revision.
• Substitution rules buried in operator headnotes instead of formula attributes; operator decides on the floor.