Skip to main content

Modeling the Recipe and Tech Transfer: Portable Process Knowledge

📍 Where we are: Part II · Discovery and Development, modeled — Chapter 9. Development has produced a molecule, a controlled process, and validated methods. This chapter models the package that carries all of it to the plant — and confronts what the model cannot guarantee about the move.

Everything Part II built — the molecule, the cell line, the design space, the analytical methods — must now be packaged and handed to manufacturing. That package is the recipe, and tech transfer is the act of moving it from the lab or the originating site to the plant that will run it at scale. Modeling the recipe well is what makes process knowledge portable instead of trapped in the heads of the development team; modeling it honestly means admitting what a recipe cannot carry across the gap between a development bench and a 2,000-liter bioreactor at a different site.

The simple version

A recipe card lets a dish travel: anyone with the card and a kitchen can, in principle, make it. But "bake until golden" assumes an oven like the one it was written for, and a recipe scaled from one cake to a thousand does not just multiply — timing and heat behave differently. Tech transfer is handing the recipe card to a new kitchen, and scale-up is making a thousand cakes instead of one. This chapter models the recipe card precisely — its steps, its required equipment, its critical settings — and is honest that a perfect card does not guarantee the new kitchen's first batch comes out right.

What this chapter covers​

We model the recipe as an information artifact realized in a production process, structured by the ISA-88 batch standard, and we model equipment requirements as roles distinct from the physical equipment that fills them. We dissect a recipe's hierarchy, show how the same model lets one recipe run on different sites' equipment, and close on the genuinely unsolved part: scale-up effects and site differences that a structural model can flag but not predict.

The recipe is information that gets realized​

A recipe is the same kind of thing as the product concept and the analytical method: a generically dependent continuant, an information artifact, copyable across sites without loss. It is not the batch and not the run — it is the prescription that a production process realizes. This distinction, which Part I's spine made available, is what lets the graph say that one recipe was realized in many batches, that two sites ran the same recipe, or that a recipe was revised between two campaigns — the recipe persists as information while each run is a distinct occurrent. The master batch record (MBR) is the recipe in its as-issued, controlled form; each executed batch record is the as-run evidence that a specific process realized it.

The international vocabulary for structuring that prescription already exists: ISA-88 (IEC 61512), the batch-control standard, models a recipe as a hierarchy — a procedure made of unit procedures, made of operations, made of phases — and separates the recipe from the physical equipment that executes it [1]. Its companion ISA-95 (IEC 62264) models the equipment and the enterprise context the recipe runs in [2], and B2MML provides an XML serialization the data book's architecture chapter leaned on [3]. Modeling the recipe as an ISA-88 hierarchy aligned to the manufacturing ontology means each step can carry the CPPs and CQAs from process development on exactly the phase they apply to — the control strategy, attached to the recipe structure rather than floating beside it. As loadable triples, the recipe is information aligned to the IOF mid-level and realized by the run, distinct from the spec it sits beside:

# align.ttl + instances.ttl — the recipe as portable information, realized by the run.
bp:MasterBatchRecord rdfs:subClassOf iof:MasterRecipe .  # IOF biopharma 'master recipe' (Released, Release_202602); a directive ICE
bp:Recipe-mAb-A a bp:MasterBatchRecord ;     # the master recipe — information, copyable across sites
    bp:hasRecipeElement bp:RP-production .   # ISA-88 composition: the recipe has recipe phases as parts
bp:RP-production a bp:RecipePhase ;          # the production-phase recipe element (prescription, not the run)
    bp:prescribesParameter bp:FeedRate , bp:Temperature ;
    bp:requiresEquipment bp:REQ-2000L .      # the equipment requirement this phase places on its vessel
bp:CCP-001 bp:realizes bp:Recipe-mAb-A .     # the production run *realizes* the recipe (not identical to it)
bp:Spec-DS-mAb-A a bp:Specification .        # the release spec — an IOF requirement specification, a different artifact

Identity card dissecting a recipe entity structured by ISA-88: a top type row marking it a generically dependent continuant (information) with its master-batch-record identity and version; a hierarchy block showing the recipe as a procedure containing unit procedures (seed expansion, production, capture), each containing operations and phases, drawn as a nested tree; per-phase rows attaching the critical process parameters and their ranges from process development and the analytical checks from the control strategy; an equipment-requirements row listing the roles each step needs (a production bioreactor of a given class and scale) marked as distinct from any specific vessel; and a realizes pointer showing the recipe is realized by a production process, not identical to it. One recipe, fully unpacked: an ISA-88 hierarchy of procedures, operations, and phases, each carrying the critical parameters and checks that apply to it, plus the equipment roles it requires — all as information that a production run later realizes. Original diagram by the authors, created with AI assistance.

Equipment requirements are roles, not equipment​

The move that makes a recipe portable is modeling what each step needs separately from what any one site has. A recipe does not require "vessel BR-101"; it requires a production bioreactor of a certain class and scale, capable of certain control — an equipment requirement, which in BFO terms is a specification a real vessel can fill by playing a role. Site A's BR-101 and Site B's BR-204 are different material entities that can both bear the role the recipe specifies. Because the recipe binds to the requirement and the requirement is filled by a role, the same recipe runs on different sites' equipment without rewriting, and the graph can check, mechanically, whether a candidate vessel qualifies for a step — does it meet the class, scale, and capability the requirement names? This is the identity discipline applied to capability: the recipe references what is needed, and reconciliation to what exists happens through roles, not by hard-coding a vessel into the prescription.

In the running example this is no longer a sketch: the two sites, the receiving vessel's qualification, and the transfer with its engineering and confirmation runs are loadable individuals. The recipe phase requires REQ-2000L; the receiving-site vessel BR-204 declares qualifiesFor that requirement; and the TechTransfer carries the recipe from the originating site to the receiving one, where the engineering and PPQ confirmation runs occur in the qualified vessel:

# instances.ttl — two sites, one recipe, a vessel that qualifies for the requirement.
bp:SITE-A a bp:ManufacturingSite .       # originating site (BR-101 is located here)
bp:SITE-B a bp:ManufacturingSite .       # receiving site
bp:BR-204 a bp:ProductionBioreactor ;    # the receiving-site vessel — a different material entity
    bp:locatedAt bp:SITE-B ; bp:qualifiesFor bp:REQ-2000L .  # it qualifies for the recipe's requirement
bp:TT-001 a bp:TechTransfer ;
    bp:transferredFrom bp:SITE-A ; bp:transferredTo bp:SITE-B ; bp:isAbout bp:Recipe-mAb-A .
bp:ENGRUN-001 a bp:EngineeringRun ; bp:occursIn bp:BR-204 .   # probes the move
bp:CONFRUN-001 a bp:ConfirmationRun ; bp:occursIn bp:BR-204 . # PPQ confirmation at the new site

A tech-transfer diagram showing one recipe realized at two sites: in the center a single recipe information artifact lists its equipment requirements as role specifications (a production bioreactor of a given class and scale); to the left Site A binds BR-101 to that role and realizes the recipe as a production process; to the right Site B binds a different vessel BR-204 to the same role and realizes the same recipe; both production processes feed into batch nodes, and a caption notes the recipe is unchanged because it references the requirement, not the vessel, while a dashed warning band underneath marks scale-up and site differences as effects the model flags but cannot predict. Portability by design: the recipe names equipment roles, so two sites fill them with different vessels and realize the same prescription unchanged — while the warning band marks what the model can flag but not guarantee about the move. Original diagram by the authors, created with AI assistance.

The unsolved part: a portable model is not a portable process​

Here is the gap the tidy diagram hides, and it is the honest heart of tech transfer. The model makes the recipe portable — the same information, bound to roles, runnable anywhere the roles can be filled. It does not make the process portable, because a biological process does not simply scale or relocate. A culture at 2,000 liters mixes, transfers oxygen, and shears differently than one at 2 liters; a new site's water, raw-material lots, and equipment behave subtly differently. These scale-up and site effects can shift a CQA even when every modeled parameter is held identical — the move itself is a variable the recipe cannot encode. The graph can flag that a transfer happened, link the engineering and confirmation runs that probe it, and compare the new site's results to the old; it cannot predict the shift. That prediction is what process models and hybrid soft sensors attempt, and it is exactly where a structural model hands off to a computational one.

A second, quieter difficulty is the maturity of the mapping itself. ISA-88 and ISA-95 are decades-old, widely-implemented standards, but they grew up as control and integration models, not as BFO-grounded ontologies — so aligning an ISA-88 recipe to the IOF manufacturing ontology is real modeling work with no single canonical answer, the same standards-convergence gap that runs through the series. A recipe modeled cleanly in B2MML and a recipe modeled cleanly in an IOF-aligned graph are not automatically the same recipe; someone authors the crosswalk. So the standard this chapter sets is, again, sober: the recipe's structure and requirements model beautifully and port cleanly, while the behavior of the process under transfer remains an empirical, run-it-and-see reality the ontology documents rather than removes.

Why it matters​

Tech transfer is where programs lose time and knowledge, and a modeled recipe is the antidote to both. When the recipe carries its ISA-88 structure, its per-phase CPPs and CQAs, and its equipment requirements as queryable facts, the receiving site inherits process understanding rather than a stack of documents to re-interpret — and the graph can check that the new site's equipment qualifies and that its confirmation batches meet every CQA the control strategy names. When the recipe is a pile of prose and spreadsheets, the receiving site re-derives what the originator already knew, and the genealogy thread frays at exactly the handoff where traceability matters most. Modeling the recipe is how the knowledge built across all of Part II survives the wall between development and manufacturing intact.

From the wire to the graph​

This chapter has named B2MML three times and shown the recipe triples it produces, but never the wire format those triples come from. The companion repo closes that gap. examples/platform/ontology/b2mml/master-recipe.xml is a real, trimmed ISA-88 master recipe serialized in B2MML (MESA, http://www.mesa.org/xml/B2MML) — the shape an MES or batch-execution layer actually exchanges. ISA-88/95 and B2MML are production-grade standards, implemented in the control systems every plant runs, so this is the format on the wire, not a pilot artifact:

<MasterRecipe xmlns="http://www.mesa.org/xml/B2MML">
  <ID>Recipe-mAb-A</ID>
  <RecipeElement>
    <ID>RP-production</ID>
    <RecipeElementType>Phase</RecipeElementType>
    <Parameter>
      <ID>Temperature</ID>
      <Value><ValueString>36.5</ValueString><DataType>real</DataType><UnitOfMeasure>Cel</UnitOfMeasure></Value>
    </Parameter>
    <Parameter>
      <ID>FeedRate</ID>
      <Value><ValueString>0.40</ValueString><DataType>real</DataType><UnitOfMeasure>/d</UnitOfMeasure></Value>
    </Parameter>
    <EquipmentRequirement>
      <ID>REQ-2000L</ID>
    </EquipmentRequirement>
  </RecipeElement>
</MasterRecipe>

examples/platform/ontology/b2mml_to_rdf.py walks this element by element. The MasterRecipe ID becomes bp:Recipe-mAb-A a bp:MasterBatchRecord — and bp:MasterBatchRecord is rdfs:subClassOf iof:MasterRecipe, so the recipe lands aligned to the IOF mid-level exactly as the loadable triples earlier in this chapter assert. The RecipeElement of type Phase becomes bp:RP-production a bp:RecipePhase, reached by bp:hasRecipeElement. Each Parameter becomes a bp:prescribesParameter edge — to bp:Temperature and bp:FeedRate. The EquipmentRequirement becomes bp:REQ-2000L a bp:EquipmentRequirement, reached by bp:requiresEquipment. The script reports B2MML -> RDF: 8 triples from the master recipe — exactly the recipe triples this chapter already asserts. The "someone authors the crosswalk" caveat above is, here, the exhibited crosswalk: a real B2MML document in, the IOF-aligned recipe graph out, with nothing invented in between. The next part traces the standards bodies that build biopharma's shared vocabulary.

In the real world​

ISA-88 and ISA-95 are the lingua franca of batch manufacturing and enterprise integration, implemented in the MES and control systems every plant runs, and B2MML is their established interchange format [1][2][3]. Tech transfer and lifecycle management are explicit concerns of the pharmaceutical quality-system guidance, which treats process knowledge as an asset to be transferred, not re-created, and frames post-approval changes around maintaining that knowledge across sites [4][5]. The frontier is binding those established control standards to a BFO-grounded manufacturing ontology so that a recipe is not just executable on a control system but queryable and checkable as knowledge — and the open-source batch-and-equipment chapter shows the relational shape of exactly that ISA-88/95 model the graph builds on. Part VII returns to these bodies directly: the standards-and-consortia chapter traces who governs ISA-88/95 and B2MML and tracks the Pistoia Alliance’s ISA-88-aligned CMC Process Ontology, while the shop-floor chapter measures how far that binding has actually reached production plants.

The ontology that target is the Industrial Ontologies Foundry (IOF), and it is layered in exactly the way this recipe model uses it. IOF Core is the domain-neutral mid-level — the manufacturing-agnostic backbone that the running example reuses for iof:ManufacturingProcess (which every unit operation specializes), iof:RequirementSpecification (the parent of the release spec and acceptance criteria), iof:MaterialArtifact/iof:MaterialProduct, iof:PieceOfEquipment, and iof:InformationContentEntity. Above Core sit the IOF biopharma modules, the domain extensions that name the things a generic factory ontology cannot: iof:MasterRecipe from the biopharma Recipe module (the parent of this chapter's bp:MasterBatchRecord), iof:Bioreactor and iof:ChromatographyColumn from BiopharmaEquipment, the cell line and its clone from BiopharmaMaterial, the unit-operation classes (iof:CaptureStep, iof:ViralClearance, iof:PolishingProcess, and the rest) from BiopharmaManufacturingExecution, and the QbD parameters from BiopharmaParameter. The honest caveat the alignment carries is no longer about maturity — these biopharma terms are all Released in the published Release_202602 — but about mechanism: the alignment is lexical, so align.ttl asserts rdfs:subClassOf up to those real, dereferenceable IRIs but imports nothing, so a downstream tool that actually owl:imports Core (which transitively pulls BFO 2020) and the biopharma modules is what turns the shared IRIs into reasoned cross-ontology inference. The most active effort to mature exactly these biopharma modules is the OAGi/NIIMBL collaboration, which contributed NIIMBL's Big Data Program ontologies to the Open Applications Group to build BFO- and IOF-Core-aligned biomanufacturing ontologies drawing on ISA-88 and ISA-95 — the work Part VII's shop-floor chapter singles out as the reference effort most directly continuous with the model this book built.

Key terms​

  • Recipe — the prescription for making a batch, modeled as a generically dependent continuant (information) that a production process realizes; the master batch record is its as-issued form.
  • ISA-88 (IEC 61512) — the batch-control standard structuring a recipe as a procedure → unit procedure → operation → phase hierarchy, separate from the equipment that executes it.
  • ISA-95 (IEC 62264) / B2MML — the standard for equipment and enterprise context, and its XML serialization.
  • Equipment requirement — what a recipe step needs (a vessel of a given class, scale, capability), modeled as a specification filled by a real vessel playing a role — distinct from the vessel itself.
  • Tech transfer — moving the recipe and its process knowledge to a new site; portable as a model, empirical as a process.
  • Scale-up / site effects — the physical and biological shifts a process can show under larger scale or a new site, even with every modeled parameter held constant; the graph flags them but cannot predict them.

Where this leads​

Part II is complete: the program's knowledge is modeled and packaged as a portable recipe. Part III follows that recipe onto the plant floor, where information becomes action and the genealogy of a specific campaign is laid down edge by edge. The next chapter, Modeling the Seed Train and the Start of Genealogy, thaws a vial of WCB-CHO-001, grows the cells through expansion stages, and models each scale-up as a process that consumes one material and produces the next — the first concrete derivedFrom edges of the batch this book has been pointing toward all along.