control recipe: Batch-Specific Recipe Instructions

A control recipe is the batch-specific set of processing instructions and parameters derived from a master recipe for execution of one identified batch. This definition reflects industry practice in recipe management; it is neither a quotation from a standard nor a legal definition.

Operationally, it connects a reusable manufacturing definition to a particular batch. Its batch-specific content typically identifies:

• Source master revision: the version from which the instructions derive.
• Batch identity: the batch to which those instructions apply.
• Planned quantity: the intended batch size, with units.
• Applicable processing sequence: the operations and their intended order.
• Parameter values: the targets or settings selected for execution.
• Equipment context: the intended equipment or applicable equipment class.

The boundary is intent versus evidence. A target temperature belongs to the instructions; an observed temperature belongs to the batch execution history. Likewise, an instruction to charge material is not proof that the charge occurred. Instructions and observations may appear together on the same screen or paper form without becoming the same information.

In batch manufacturing, this concept can support manual work, automated processing, or a mixture of both. It does not depend on a particular software architecture or a document literally named control recipe. The useful question is whether the batch-specific instruction set is identifiable, rather than what the site calls its screen, file, or packet.

In industry practice, a master recipe is the reusable processing definition; a control recipe is its batch-specific execution instance. The neighboring objects answer different questions: what to make, how to process it, what the machine does, and what actually happened. They may share information without being interchangeable.

Apart from the explicitly identified US drug record row, these are operational descriptions, not legal definitions. A work order commonly references processing instructions rather than containing them all. A batch record can bring together dispensing, processing, packaging, and review evidence; an equipment program addresses machine behavior, not that complete documentary scope.

A useful design check is to trace one instruction from its reusable source through the batch instance to the recorded result. Matching names alone does not establish that relationship. The next section maps the recipe concept to US drug record provisions without assuming a one-to-one equivalence between software objects and legally named records.

This mapping concerns US human drugs under 21 CFR 211. For supplements, food, medical devices, chemicals, and other jurisdictions, use the applicable product and jurisdiction rules rather than transferring this mapping. Separate starting points include the supplement master manufacturing record and 21 CFR 117 for food.

Binding requirements: master instructions and batch evidence

• For US human drugs under 21 CFR 211.186(a), master production and control records must be prepared, dated, and signed (full signature, handwritten) by one person and independently checked, dated, and signed by a second person.
• For US human drugs under 21 CFR 211.186(b)(9), master production and control records must include complete manufacturing and control instructions, sampling and testing procedures, specifications, special notations, and precautions to be followed.
• For US human drugs under 21 CFR 211.188, batch production and control records must be prepared for each batch and include complete information relating to its production and control.
• For US human drugs under 21 CFR 211.188(a), batch production and control records must include an accurate reproduction of the appropriate master production or control record, checked for accuracy, dated, and signed.
• For US human drugs under 21 CFR 211.188(b), batch production and control records must document that each significant manufacturing, processing, packing, or holding step was accomplished.

Operational mapping, not a prescribed architecture

In industry practice, a control recipe can connect reusable instructions to a particular batch. Treat that connection as a design aid, not proof that the recipe alone constitutes the complete batch record. A practical review asks where the master instructions reside, how the batch-specific copy retains its basis, and where execution evidence is collected.

The proposed recipe lifecycle and database model are operational practice—not official agency guidance or a prescribed compliance architecture. Work order release is a suggested implementation point, not a legal trigger asserted by this mapping. Optional software support, such as an electronic batch record, should be evaluated against the site's record responsibilities; adopting a software category does not establish compliance. Keep review, approval, and release decisions with responsible people.

One practical operating pattern is to generate the control recipe when a work order is released. This is an industry-practice workflow, not a universal regulatory trigger. Keep instruction preparation distinct from authorization to begin production and subsequent product disposition: creating the instance does not itself authorize either production or product release. Those decisions remain with authorized people.

Before preparation, resolve the product identity, applicable approved master revision, intended batch size, processing route, and equipment eligibility. Assign an instance identifier and link it to the work order and batch identifier. Equipment eligibility means suitability for the selected instructions, not merely availability on the schedule.

Parameter binding turns reusable instructions into batch-specific values. Distinguish values inherited unchanged from the master, selections made within permitted options, calculated values with their inputs and units, and entries awaiting resolution. For each pending entry, identify who resolves it and the point before which it is needed. A deliberately deferred entry is different from an unnoticed blank.

Preserve the selected revision and resolved instruction content as a snapshot or an equivalent immutable version reference. The reference should retrieve exactly the instructions prepared for that instance, including bound parameters—not whichever master happens to be current when someone later opens the record.

A practical readiness check flags unresolved placeholders, incompatible quantity units, missing prerequisites, and equipment substitutions outside the established eligibility criteria. Record the resolution or retain an explicit pending status; avoid silently supplying defaults. A unit class library can help structure equipment eligibility checks.

Keep material allocations and actual lot genealogy linked to the instance. Reservations may remain in inventory or planning records rather than inside the recipe definition; preserve the relationship without confusing reserved stock with material actually consumed.

Building on the instruction-versus-evidence boundary above, a practical execution model links each step to its instruction version, expected material and equipment inputs, observations, results, responsible person, and completion status. The reference to an electronic work instruction identifies the intended action; the linked execution entries preserve its batch-specific context.

For US human drugs under 21 CFR 211.100(b), written production and process control procedures must be followed, and execution must be documented at the time of performance.

As an operational practice, define sequencing and hold points around the particular process, not merely the equipment's ability to advance. A hold before charging might depend on a manual material-label check or inspection of a transfer connection. Where those checks are not instrumented, an equipment controller cannot establish their outcome by itself. Record the observation and the person making it before allowing the dependent action.

Attach each in-process check and batch yield observation to the relevant operation, with its time, units, and applicable acceptance basis. This practical association lets a reviewer distinguish a mixing result from a later transfer result rather than interpret an unstructured collection of readings.

In the site's execution model, distinguish a controller acknowledgement of a command, an operator's observation, and completion of the process step. Define which acknowledgement means receipt or equipment action, which observation supplies a manual check, and which conditions permit completion. For example, receipt of a charge command need not mean material transfer has finished. Preserve these separate events and their relationships in the batch execution history, rather than letting one status overwrite the others.

The accompanying entity diagram illustrates a design for recipe management and batch review. It is an industry-practice model, not a prescribed regulatory database schema. Its central relationship is a control recipe instance linked to the specific master revision from which it was generated.

Use master_recipe_id for the reusable recipe identity and master_revision_id for its fixed revision. Assign control_recipe_id to the execution instance and link it to batch_id. Scope step_id to the relevant instruction version; attach each event_id to that step and instance. A recipe amendment identified by change_id links the prior and revised instruction states, its authorization, and its effective execution boundary. A review record references the instruction states and events actually reviewed, rather than an evolving display.

Useful evidence fields include value, unit, material_lot_id, equipment_id, occurred_at, received_at, actor_id, actor_role, and evidence_ref. Separate event occurrence time from receiving-system time so delayed transmission remains visible. Evidence references should resolve to retained records, not merely filenames. These relationships give a batch execution history usable context.

An audit trail can preserve prior values, actors, reasons, and change timing. Combined with checks for missing references, duplicate events, inconsistent units, and timestamp anomalies, it supports reconstruction of instructions and events at a selected execution point. Include that reconstruction in the audit trail review workflow.

Keep record identity separate from editable display names. An external work order number alone may collide across sites or source systems. Production context tagging can retain source-system and site identifiers alongside the external number and its internal mapping.

These cases illustrate practical recipe reasoning, not universal regulatory rules. Each starts with explicit assumptions and ends with an instruction decision supported by retained evidence.

Case: resizing a homogeneous premix

Assume a homogeneous premix with unchanged composition, a process definition that permits proportional scaling of the selected component, and all relevant masses expressed in kg. The calculation is:

planned component mass = reference component mass × planned batch mass ÷ reference batch mass

Reference component mass is the selected component quantity in the reference formulation; reference batch mass is that formulation’s total batch mass. Planned batch mass is the intended total for this instance; planned component mass is the resulting component instruction. The batch-mass ratio is dimensionless because kg divides by kg, leaving the calculated component quantity in kg.

A larger planned batch therefore increases this component quantity proportionally; a smaller batch decreases it. A mixing duration expressed in minutes does not change unless its own process rule defines that dependence. Mass scaling alone establishes no relationship between batch size and mixing time.

Retain the selected master revision, source quantities and units, calculation basis, resolved instruction values, and responsible review decision. This makes the weighing and dispensing instructions traceable to their calculation rather than leaving only an unexplained final quantity.

Case: communication interruption during a material charge

Assume the planned charge and reconciled delivered mass use kg, their measurement basis is consistent, and any loss or rework has already been addressed. After reconciling delivery:

remaining planned charge = planned charge − reconciled delivered mass

Planned charge is the instructed material quantity; reconciled delivered mass is the quantity established as physically delivered; remaining planned charge is the balance still intended for delivery. The relationship is unusable for deciding continuation while delivered mass remains uncertain or exceeds the planned charge.

A missing acknowledgement does not establish that no material moved. First compare the physical event with weighing records, equipment events, and operator observations through in-process reconciliation. Then choose continuation for an established remaining quantity, a duplicate-message acknowledgement when the same completed delivery is confirmed, or an exception hold when evidence is unresolved or delivery exceeds the plan.

Retain the original charge instruction, event identity, reconciled measurement evidence, calculated balance, and the person’s decision with its rationale.

In operational practice, selecting a value within an already defined operating option executes the instruction; changing that option’s limits, conditions, or permitted choices changes the governing instruction. A selectable field alone does not establish permission.

US human drug production and process-control procedures, including changes to them, require defined drafting, review, and quality-unit approval before use; see 21 CFR 211.100(a) for that requirement. A control recipe instance should trace back to a procedure version that cleared that approval, not to a locally edited copy.

A practical change-control pattern preserves the earlier instruction state, identifies affected unfinished work, documents the reason, assesses impact, and associates the decision with the revised execution state. Treat step status explicitly:

• Completed: retain the instruction version that governed performance and assess whether the change affects acceptance of the result.
• In progress: identify the last completed action and document whether to continue, pause, or restart under the applicable site procedure.
• Not yet started: identify which revised instructions apply and the decision authorizing their use before execution.

For US human drugs under 21 CFR 211.100(b), deviations from written procedures must be recorded and justified.

Editing instructions after an event does not change which instructions governed that event. Operationally, link the departure to its deviation handling rather than rewriting the earlier basis. An audit trail supports this distinction by preserving who changed what and when; it does not replace the documented impact assessment or human approval decision.

A possible site-specific design assigns orders and quantities to planning, batch instructions and execution records to the recipe execution system, machine actions and interlocks to equipment controllers, sample results to laboratory systems, and exception assessment and disposition to quality workflows. Define ownership at each handoff; MES–ERP integration does not mean both systems can independently revise the same batch instruction.

A practical interface contract identifies the control-recipe instance, master revision, unique message identity, schema version, equipment mapping, units, event time, and processing status. Specify which system originates each field, how revisions are checked, and how rejected messages are reported.

Track message delivery, application acceptance, physical execution, and evidence recording separately. A received command is not proof of a completed charge; a completed charge may still lack its recorded confirmation. Retries should reconcile these states rather than repeat a physical action.

• Duplicates: retain message identities and return the prior processing result without re-execution.
• Out-of-order events: check sequence and dependencies before applying updates.
• Stale payloads: reject mismatched instance revisions or obsolete state assumptions.
• Partial imports: stage and validate complete instruction sets before activation.
• Temporary disconnection: buffer events durably where designed, define permitted local operation, and reconcile before resuming coordinated execution.

For recovery, first establish actual equipment and material state. Next reconcile accepted events against controller records and the process event log, identify unresolved gaps, and obtain authorization for the next action through the applicable local process. In the interrupted-charge case above, this means resolving what physically transferred before deciding whether to resume—not simply resending the command.

As noted above, this coordination supports traceability; it does not substitute for the human review and release decisions described earlier.

A control recipe can look complete while losing meaning in export, calculation, or status handling. The following are practice-based review controls, not a separate set of regulatory requirements. Test content and decision logic, not just page appearance.

Include these scenarios in paperless validation. Use edge-of-failure mapping to select boundary cases rather than relying solely on nominal examples.

Use this practical checklist to assess a representative control recipe instance and its review package. It builds on the generation, evidence, modification, and recovery sections above; it is an acceptance aid, not an additional regulatory standard. Record findings, owners, and dispositions rather than only pass/fail marks.

1. Local terminology and ownership: Do site procedures identify which object is the control recipe and who owns its preparation, execution, and review? Are responsibilities clear when planning, production, automation, and quality use different names for the same instance?
2. Generation readiness: Can the instance be traced to its master revision and intended batch context? Are unresolved parameters visible before use? Does the complete instruction content, including referenced instructions and conditional branches, remain accessible and readable after export or system transfer?
3. Execution evidence: Can completed events be related to steps, actors, material lots, equipment, and supporting observations through stable identifiers rather than ambiguous display names? Can a reviewer follow the batch execution history and distinguish missing evidence from an operation that was not performed?
4. Exception resolution: Do change and deviation decisions remain connected to the instruction state they affected? Does the recipe redline history preserve that context? Are unresolved exceptions visible to reviewers, with an owner and a clear disposition status rather than an unexplained closed flag?
5. Interface recovery and testing: Do tests exercise unavailable equipment, interrupted interfaces, conflicting statuses, malformed messages, calculation boundaries, and incomplete evidence? Do expected results address duplicate or delayed events and identify who decides whether execution can resume? Retain observed results and unresolved findings with the test record.
6. Final review: Can the reviewer navigate from each significant finding to its supporting evidence and decision? Does the audit trail review workflow leave a recorded outcome? Are remaining issues explicitly dispositioned or visibly pending rather than hidden by a summary status?

An illustrative review deliverable is a traceable instance with accessible instructions, execution evidence, change history, exception decisions, and a recorded human review outcome, consistent with the accountability boundary described earlier.