plm

Product Lifecycle Management

Bench to BLA. One recipe.

For sponsors and CDMOs alike: recipe-driven development, one-click tech transfer, MSAT continuity, and CMC submissions rendered from the live spine. The line, the master batch record, and Module 3 say the same thing because they're views of the same object.

The recipe is the process
One structured graph drives the bioreactor, the harvest, the chromatography, the fill — every unit operation reads from the same versioned object. The CMC narrative, the master batch record, and the line are views, not copies.
mAb-Alpha · recipe v4.1 · campaign L240312
recipe v4.1
UO-01
Cell expansion
CPP · VCD · 4–6 ×10⁶/mL
CQA · viability
armed
UO-02
Bioreactor
CPP · feed glucose 3.5–5.5 g/L
CQA · G0F glycan
armed
UO-03
Harvest
CPP · depth filter ΔP ≤ 0.8 bar
CQA · turbidity
armed
UO-04
Protein A
CPP · load ≤ 38 g/L resin
CQA · HCP
armed
UO-05
Polish · IEX
CPP · elution conductivity 12 mS
CQA · charge variants
armed
UO-06
UF / DF · Fill
CPP · TMP ≤ 1.2 bar
CQA · aggregate
armed

Seal is the structural recipe spine for biologics operations — bench through commercial. PD, GMP, MSAT, and CMC work on the same versioned graph. We integrate with control systems, historians, instruments, and ERP through modern APIs; we do not replace them.

The Process That Drifted From Itself

A monoclonal antibody program. Process v3.2 was transferred to a CMO in March 2024 for commercial PPQ. The transfer package was thorough — master batch record, raw material specs, equipment matrix, validation plan. Forty-three documents. Eight Zoom workshops. Person-in-plant for the engineering runs. The CMO ran v3.2 on the engineering batch. Comparable to the sponsor's GMP material. Everyone signed off. Tech transfer complete.

Six months later, PPQ Lot 3 failed — protein A capture yield 18% below the expected range. The CMO's investigation pointed at column performance. The sponsor's MSAT team was confused; their internal process had been performing well. They opened the comparison.

The CMO was running v3.2. The sponsor's MSAT team had iterated to v3.5 to debottleneck the same protein A step. v3.3 added a dynamic load criterion. v3.4 changed the wash buffer molarity. v3.5 modified the elution gradient. None of these changes were "major." Each was approved internally as process-improvement work. None had been pushed to the CMO because the CMO was running clinical product, not commercial. Until they were.

Then it got worse. The CMC submission filed with FDA two months earlier described the v3.5 process. Because the regulatory team had pulled their narrative from MSAT's "current process" documents. The submission described one process. The CMO ran another. The clinical material referenced in the comparability section came from yet a third (v3.0, the GMP-pilot version).

Everyone had been working from the "current process." There were three current processes. The investigation took 14 months. The PPQ slipped a year. The 483 finding cited "inadequate procedures to ensure that the manufacturing process described in the application is the process used to manufacture clinical and commercial materials."

Three teams. Three sources of truth. All correct in their local frame. All incompatible the moment they met. Whether you read this story as the sponsor or as the CDMO, the failure mode is the same — and the fix is the same.

The three current processes problem
Three teams. Three sources of truth. All correct in their local frame. All incompatible the moment they meet — until the recipe becomes one structural object.
Before — document-package transfer · drift invisible until it breaks
Sponsor / MSAT
"current process"
v3.5
CMO
"current process"
v3.2
CMC submission
filed with FDA
v3.5
FDA 483 · investigation took 14 months
"Inadequate procedures to ensure that the manufacturing process described in the application is the process used to manufacture clinical and commercial materials."
After — structured recipe graph · divergence becomes impossible
Recipe graph
single versioned node · live
v3.5
Fig. 1 — Recipe Divergence

The many-recipes problem

Walk into any biologics company and ask a simple question: what's the current recipe for Product X? You'll get different answers depending on who you ask.

Process development shows you the bench recipe. Lab notebooks, scale-down model parameters, design-space data, the latest CPP ranges. The version they're optimizing now.

GMP manufacturing shows you the master batch record. The recipe approved when clinical campaign N was authorized. Frozen at campaign launch, with approved deviations stitched on top.

MSAT shows you the "current commercial recipe." The internal model that incorporates every learning since the campaign started — minor parameter shifts, raw material substitutions, troubleshooting changes that became permanent.

The CMO shows you the recipe they were transferred. Whatever version was current at handoff, with their own approved deviations layered on.

Regulatory shows you the process described in the IND, the BLA, or the most recent variation. A snapshot from when the submission went out.

Each lives in its own system — bench LIMS, MES master batch record, MSAT change-control workspace, CMO's own QMS, eCTD publishing tool. Each has the same name. Each says different things. The drift is invisible until something breaks.

The recipe as one graph

One recipe. Many views.
PD bench, master batch record, MSAT model, CMO record, and Module 3 are renderings of the same structured graph — not separate documents that drift.
Recipe graph
unit operations · CPPs · CQAs · raw materials
cell line lineage · validation · versioned · live
PD view
design space · ranges
scale-down model qualification
Master batch record
executable · approved limits
21 CFR 11 signatures
MSAT model
CPV trends · campaign learnings
deviation history · live
CMO batch record
inherited via transfer
site deltas explicit
Module 3 (CMC)
3.S.2.2 · 3.S.2.4 · 3.S.2.5
rendered, not assembled
Every team queries the same node
Fig. 2 — Recipe Spine

Seal collapses these into one structure. The recipe is a graph: unit operations linked in sequence, each unit operation linked to its CPPs and acceptance ranges, each CPP linked to the CQAs it controls, each unit operation linked to the raw materials, equipment, and consumables it consumes.

The bench recipe, the master batch record, the MSAT model, the CMO recipe, the CMC narrative — all views of that same graph. Process development sees the design space and the parameter ranges. Manufacturing sees the executable batch record with limits and acceptance criteria. MSAT sees the change history and the trend overlay. Regulatory sees the narrative formatted for Module 3.S.2.2 or 3.2.P.3.3.

When the bench iterates v3.3, the graph updates and every view updates. When MSAT pushes a tightening of a CPP based on commercial data, the graph updates and every view updates. When the CMO is on a specific version, the version is explicit and the diff against the sponsor's current version is computable in seconds.

There is no master document to forget to send. There is no shared-drive folder to find. The recipe is the structure. Documents are renderings.

Recipe-driven development

Most biologics programs treat process development as a document factory. Every campaign generates a study report that someone hopes to harvest later. CPPs are written into a Word document at the end of the program. Design space is captured in a series of DOE summaries that may or may not be linkable to the parameter ranges they justified. The master batch record is built by translating the development reports into procedure language, with someone hoping nothing was lost in translation.

Recipe-driven development inverts this. The recipe graph is the working artifact from the first PD experiment. When development runs an experiment, it runs against a draft recipe — a structured object with explicit unit operations, parameter ranges (wide initially), candidate CPPs, and intended CQAs. Each experiment links to the recipe version it tested and records which parameters it varied. The DOE result attaches to the parameter range it informed. The CPP justification is the chain of experiments that established it.

By the time the program enters GMP clinical, the recipe has accumulated its own rationale. The transition to GMP is a lock event — freeze the recipe at its current state, sign the master batch record. There is no "translation" step because the recipe and the master batch record are the same object viewed differently. The development reports are no longer the load-bearing artifact; the linked evidence on each recipe element is.

This compounds across programs. Platform recipes become reusable starting points. New programs branch from a platform recipe and customize the elements that need molecule-specific work. The institutional knowledge that took years to build for the first commercial product becomes structural in the system, available to the next program from day one.

One-click tech transfer

Tech transfer as cascade
The receiver inherits the sender's recipe graph as a structured object. Site deltas are explicit. The live link is preserved for the life of the product.
Sender · v3.5
Upstream UO · bioreactor
Harvest · depth filtration
Capture · Protein A
Polish · IEX, HIC
UF/DF · formulation
Fill · 50 mL vials
CPPs · CQAs · raw material AVL · cell line lineage · validation
Site deltas · declared · rationalized
column geometry
bed height 25 → 22 cm
to maintain residence time
fill volume
50 mL → 100 mL
commercial pack size
GMP-grade media
Source A → Source B (qualified)
animal-origin-free retained
site SOPs
site-specific cleaning, gowning
no impact on CPPs
Receiver · v3.5 + Δ
Upstream UO · bioreactor
Harvest · depth filtration
Capture · Protein AΔ bed height
Polish · IEX, HIC
UF/DF · formulation
Fill · 100 mL vialsΔ pack size
inherited CPPs · CQAs intact · comparability evidence linked
Fig. 3 — Tech Transfer Cascade

A traditional tech transfer is a packaging exercise. Assemble forty-three documents. Email them to the receiver. Hold workshops to translate. Run engineering batches. Compare results. Sign the transfer report. Then watch the recipe drift between the two sites for the rest of the product lifecycle.

One-click tech transfer collapses the packaging step. Click the recipe version. Select the receiving site. The system creates the receiver's recipe instance as a structured inheritance — every unit operation, every parameter, every CPP-to-CQA link, every raw material specification, every consumable transfers as one object. The receiver opens it, reviews each element, and declares site-specific deltas where the receiving site differs.

Every delta is logged with reason: "different chromatography column geometry — bed height adjusted from 25 cm to 22 cm to maintain residence time," "site-specific GMP grade media qualification — Lot N from approved Source B," "fill volume 100 mL replaces 50 mL per commercial pack size." The transfer comparability plan generates from the delta list. The engineering batch protocol generates from the inherited recipe. The transfer report renders from the executed comparability evidence.

What used to take six months of document assembly now takes weeks of meaningful technical work — because the meaningful technical work was never about the document assembly. The transfer is not "complete" the day engineering batches release. The link between sender and receiver recipe versions is preserved indefinitely. When the sender iterates, the system shows the receiver what's drifted. When the receiver runs into a deviation, it links back to the inherited unit operation and the sender's MSAT can see it.

This works whether the receiver is internal (PD → GMP pilot → commercial site) or external (sponsor → CDMO). For CDMOs running multiple sponsor programs in parallel, every program gets its own recipe spine with per-client isolation. The CDMO's MSAT works on N recipes for N sponsors without crossing wires, and each sponsor's live link sees only their program. Same structure. Same delta tracking. Same comparability evidence stitched into the recipe graph.

What Seal does not replace

A recipe spine is only useful if it composes cleanly with the systems that already run your operation. Seal is deliberately scoped:

  • Control systems and DCS run the loop. Seal reads from them and writes recipe target ranges into them through OPC UA or vendor APIs. We do not run the loop and we are never on the critical control path.
  • Historians and time-series infrastructure keep the high-frequency PV data. Seal pulls aggregates, excursion events, and CPV-relevant slices into the recipe context. The historian stays the historian.
  • Instruments and analyzers keep their own SDMS, drivers, and connectors. Seal's role is to attach the result to the recipe element — the unit operation, the CPP, the CQA — not to be the instrument data lake.
  • ERP owns the financials, the procurement, the inventory ledger. Seal carries the AVL relationship on the item and the recipe-side material requirements; ERP carries the receivables and the capacity plan.
  • eCTD publishing tools handle the regulatory packaging. Seal is the source of truth for the CMC content; your publisher handles assembly and transmission to the agency.

Modern APIs — REST, JSON, webhooks, OPC UA where applicable — make this composability real instead of aspirational. Bus architectures, unified namespaces (UNS), and in-flight contextualization layers compose cleanly above the recipe spine. Whatever your data-standards strategy looks like, the recipe element is the canonical anchor that every other system attaches to.

MSAT as the steward of the live process

Once published — process knowledge flows everywhere
The approved process definition is not a PDF that people "reference." It's a live record that downstream systems read directly.
Process definition
CPPs, CQAs, ranges · development rationale
Validation evidence · version controlled
Tech transfer
Parameters carry forward intact
to commercial site — no re-entry
Batch records
Every batch reads CPPs from
the source — not a copy of a copy
Investigations
Full dev rationale surfaced
when a CPP goes out of range
CPV (continued verification)
Trending connects current batches
to the assumptions they depend on
Change control
Evidence auto-compiled for every change.
Impacted batches + investigations identified.
When auditors ask "why?" — the answer is one click away
Fig. 4 — MSAT Connected

Manufacturing Science and Technology owns the process after launch. Every campaign generates data. Every deviation reveals something. Every raw material lot has a slightly different attribute profile. The process learns. The question is whether the learning lives anywhere structural.

In most companies, MSAT is a heroic activity that keeps a parallel knowledge base in spreadsheets, dashboards, and individual heads. The MSAT lead knows the process is "really" running with a tightened lower bound on Step 7 protein A load, but the master batch record still shows the wider range because tightening it would trigger a change control. The MSAT lead knows that Resin Lot 8472 had unusual fines content and the team adjusted the wash flow rate to compensate, but that's an institutional memory item.

In Seal, MSAT works on the live recipe graph. Every change MSAT proposes — whether it's the sponsor's MSAT or the CDMO's MSAT working on a transferred program — attaches to the unit operation, the CPP, the raw material, or the equipment it concerns. Every change runs through proper change control with cascade analysis: which CMC sections does this affect, which validated processes does this touch, which transfers need updating, which sponsor needs notification. Approved changes update the live graph. Rejected changes are archived with reason. The MSAT knowledge stops being a private dashboard and becomes part of the structural recipe record.

When MSAT receives a complaint trend, an OOT result, or a stability deviation, the investigation traces back through the same graph. The link between the field signal and the process state is structural. The CAPA that follows generates a process change with cascade impact already computed.

Continuous Process Verification (CPV) under ICH Q10 stops being a manual quarterly exercise. It runs against the live graph, with control limits attached to each CPP, and surfaces signals as they emerge.

Established conditions · Q12 lifecycle management

Established conditions · ICH Q12 · classification computes itself
Tag ECs on the recipe element. The cascade decides whether a change owes the agency a Prior Approval Supplement, a CBE-30, an Annual Report — or no submission at all.
Recipe graph · EC tags
UO-04 · Protein A capturePA
resin · sterilization · column packing limits
CPP · Day-7 glucose 3.5–5.5 g/LCBE-30
linked to G0F glycan CQA
Raw material · cell culture mediaCBE-30
animal-origin-free · approved Source A
UO-08 · UF/DF · TMP ≤ 1.2 barAR
scale-down qualified · routine monitoring
In-process control · pH read frequencynon-EC
supportive information · internal CC only
Site SOP · gowning procedurenon-EC
site-specific · no impact on CPPs
Prior Approval
CBE-30
Annual Report
non-EC
Proposed change · cascade output
"Replace Protein A resin vendor"
Equivalent ligand · same chemistry · qualified second source
Recipe elements touched
UO-04 · Protein A capture · resin lifetime & cyclingPA
CPP · Dynamic load capacity ≤ 38 g/L resinCBE-30
CQA · HCP residual ≤ 100 ng/mg · linked validationPA
Cleaning validation matrix · re-evaluationnon-EC
Regulatory category · computed
Prior Approval Supplement required
2 PA-tagged elements · highest classification governs · estimated 4-month review
PACMP coverage check
PACMP-08 applies · reduced reporting available
Pre-agreed protocol covers equivalent-ligand resin substitution · CBE-30 path
Fig. 5 — Established Conditions

ICH Q12 introduced the discipline most biologics companies still fake: separating the recipe elements you've committed to the agency (Established Conditions) from the elements you control internally (supportive information). When an EC changes, you owe a submission — a Prior Approval Supplement, a CBE-30, or an Annual Reportable depending on category. When supportive information changes, internal change control is enough.

Most companies maintain ECs as a list in a spreadsheet, decoupled from the master batch record and the change-control system. Six months after filing, the spreadsheet is stale. Twelve months later, it's fiction. The first time anyone discovers a change should have been filed is when an inspector asks why it wasn't.

Seal tags ECs on the recipe element itself. Each unit operation, CPP range, raw material specification, or analytical method carries its EC classification — Prior Approval, CBE-30, Annual Reportable, or non-EC. When a change is proposed, the cascade computes the regulatory category automatically: this change touches three ECs at the Prior Approval level and two at CBE-30, so the variation submission is required and the timing follows. A non-EC change runs through internal change control without a filing.

Post-Approval Change Management Protocols (PACMPs) attach to the EC they manage. When you've pre-agreed a protocol with the agency for a future change, the system routes the change through the PACMP path automatically — collecting the predefined evidence, generating the reduced-reporting documentation, executing under the pre-agreed conditions. The Q12 framework stops being a regulatory ambition and becomes how change actually flows.

The Product Lifecycle Management Strategy document Q12 expects — describing how you classify ECs, how you manage change, how PACMPs operate — generates from the live tagging on the recipe graph. The strategy and the operation cannot disagree because they're the same object viewed differently.

Raw material AVL where it actually matters

For biologics, the AVL isn't a procurement convenience. It's a regulatory commitment. Animal-origin component status, GMP grade qualification, single-source risk, change-notification agreements — all of these are filed with the agency.

Seal puts the AVL on the raw material item, with full qualification context. Master cell bank reagents qualified for cGMP biologics use. Cell-culture media with confirmed animal-origin-free status. Chromatography resins with extractables/leachables data. Single-use bags with film qualification. Each source carries its qualification status, audit history, and change-notification subscription.

When a supplier issues a change notification — a resin manufacturer modifies their ligand, a media manufacturer changes their soy peptone source, a single-use bag film vendor switches their plasticizer — the notification routes to the right items in the system. Where-used answers immediately: which processes consume this material, which active campaigns are running, which CMC sections describe it, which comparability evidence is on file. The change-control response is initiated with the impact already computed.

Single-source critical materials surface continuously. The system flags items where there is no qualified backup, weighted by criticality and current campaign demand. Sourcing risk becomes a queryable property of the process, not a tribal worry.

Cell line and bank lineage as a graph

The biological starting material has its own lifecycle. Research cell line, master cell bank, working cell bank, end-of-production cell line characterization. Every program has its lineage. Every lineage has provenance, characterization, and stability data.

In Seal, the cell line and bank lineage are first-class objects. The MCB record links to its source research cell line, its characterization studies, its stability program, and the process that uses it. Every WCB derives from a specific MCB with a recorded passage history. Every campaign batch records the WCB vial used, the passage age at inoculation, and the harvest performance.

When a regulatory question lands — "show us the WCB-to-MCB-to-RCB lineage for the lot referenced in your BLA Module 3.S.2.3" — the answer is one query. The lineage isn't a paragraph someone wrote in a submission. It's the live graph the process actually used.

For programs with multiple variants — research strain, GMP-banked strain, commercial-banked strain — the lineage tracks the variant relationships explicitly. The CMC submission describes the actual lineage in production, not the lineage someone remembered when they wrote the section.

CPP / CQA traceability that holds

CPP → CQA → clinical risk · QbD as a graph
Every parameter exists because it controls an attribute. Every attribute exists because it links to a clinical risk. The chain is structural, not a spreadsheet.
Unit operation
Critical process parameter
Critical quality attribute
Clinical risk
UO-01 · Bioreactor
2,000 L · fed-batch
Day-7 feed glucose
3.5 – 5.5 g/L
design space · DOE-217
G0F glycan ratio
≥ 42 % of total glycans
release spec · 3.S.4.1
ADCC potency
efficacy in target indication
linked to CER section 4.2
UO-04 · Protein A
capture · single-source resin
Dynamic load capacity
≤ 38 g/L resin
PV-3 lots · validated
HCP residual
≤ 100 ng/mg
release spec · 3.S.4.1
Immunogenicity
patient safety
CER section 5.1
UO-08 · UF/DF
final formulation · 30 kDa
TMP / shear stress
≤ 1.2 bar
scale-down qualified
High-MW aggregate
≤ 1.5 % by SEC
release spec · 3.S.4.1
Immunogenicity
patient safety
CER section 5.1
Fig. 6 — CPP CQA Chain

Every CPP exists because it controls a CQA. Every CQA exists because it links to a clinical risk. The QbD chain — process parameter → quality attribute → product safety/efficacy — is the regulator's framework. It is also the framework most companies maintain in disconnected Excel spreadsheets.

Seal makes the chain structural. Click any CQA — purity, potency, aggregate level, host cell protein, residual DNA, glycan profile. See every CPP linked to it across every unit operation. See the design-space evidence that established the link. See the validation evidence that proved it. See the post-launch CPV data that monitors it.

When a process change is proposed, the cascade computes which CQAs are potentially affected, which validation evidence may need refresh, which comparability studies are required. When a CQA result trends, the system surfaces the CPPs that historically drove similar shifts. When the CMC submission needs to justify a specification, the rationale renders from the linked design space and validation evidence — not assembled from documents.

Multi-site comparability without multi-effort

A successful biologic ends up running in multiple places. Sponsor's clinical site for early material, commercial site for launch, second site for capacity, CMO for surge. Every additional site multiplies the comparability burden. Or it would, if comparability were a document.

In Seal, comparability is structural. Each site runs the recipe as a versioned instance with explicit deltas from the master recipe graph. Comparability evidence — release testing, characterization, stability — links to the recipe versions it bridges. When you add a site, you inherit the master recipe, declare your site-specific deltas, and run comparability batches. The comparability dossier renders from the linked evidence. When the master recipe iterates, every site sees the change request and resolves whether to inherit or branch.

When inspectors compare what's in the BLA to what's running on the floor at any site, the answer matches by construction.

MSAT Changeset
Fig. 7 — MSAT Changeset

CMC submission from the live process

The Module 3 sections describing your manufacturing process — 3.2.S.2.2 (description of manufacturing process and process controls), 3.2.S.2.4 (controls of critical steps and intermediates), 3.2.S.2.5 (process validation and/or evaluation), 3.2.P.3.3 (description of manufacturing process and process controls for drug product) — are the most labor-intensive narrative sections of the dossier. They are also the sections most likely to drift from reality between filings.

In Seal, these sections render from the live recipe graph. Unit operations become process descriptions. CPP ranges become control parameter tables. Raw material specifications become control of materials sections. Validation evidence becomes the process validation summary. The narrative is generated from the structure, not assembled from archives.

Variations and supplements generate the same way, with the change relative to the prior submission already computed. The annual product review compiles itself from the campaign data and the process change history. The reviewer questions that follow filings get answered from queryable data, not from week-long document hunts.

Neil computes the cascade before you approve

Tell Neil what changed at the bench: "Move from Filter A to Filter B at the depth filtration step." Neil walks the recipe graph and prints the cascade before you submit the change request:

  • 7 unit operations downstream that interact with the filter output
  • 4 CPPs whose ranges were established under Filter A's flux profile
  • 2 CQAs (HCP residual, host cell DNA) with linked validation evidence that may need refresh
  • 3 sites running the recipe, including 1 CMO under live transfer link
  • 6 CMC sections that describe the depth filter — 2 currently classified as Established Conditions, requiring a CBE-30
  • 1 PACMP on file that covers depth filter changes within a defined design space — change qualifies, reduced reporting available
  • 5 in-flight campaign batches that will need disposition impact review

You see the regulatory work and the operational work in front of you, before approval. Then Neil drafts the change request, the comparability plan, the CBE-30 narrative, and the impacted-batch disposition memo. You review and decide.

Between changes, Neil watches the spine. Recipe versions diverging across sites without an open transfer flag. CPP control limits that have drifted since last validation. Raw materials with high consumption and a single qualified source. CQA trends crossing statistical threshold. The signals come to MSAT, instead of MSAT going looking.

The next inspection

Same molecule. Same site. Two years after the v3.2/v3.5 incident. An FDA pre-approval inspection arrives for the variation. The lead investigator opens with the standard question.

"Show me the manufacturing process described in the application."

Module 3.S.2.2 renders. Generated from recipe v4.1, the version locked at the time of submission. Every unit operation, every CPP, every raw material specification on screen.

"Show me the same process as currently run on the floor."

The CMO's batch record for the lot in process. Recipe v4.1 plus three site deltas, each with rationale and comparability evidence. The investigator compares to the application. Match.

"What changes have you made since filing?"

Six. Each opens to its cascade analysis with EC classification visible. Two went through CBE-30 — filing dates, FDA acknowledgment letters, comparability data attached. One ran under PACMP-08 — pre-agreed protocol, evidence package, reduced reporting filed. Three were non-EC — internal change control, no submission required, with the rationale linked to the EC tagging.

"How do you know the CMO is running the same recipe?"

The live link. Pull up the diff between sponsor v4.1 and the CMO's effective recipe. Three site deltas, all declared. No undeclared drift. The diff is computed from the structure, not reconstructed from documents.

"Why is the day-7 glucose range what it is?"

Click the CPP. Design space evidence attached, study DOE-217. Linked CQA: G0F glycan ratio. Linked clinical risk: ADCC potency. Validation data, three PV lots, all within range. CPV trend chart for the last 18 commercial campaigns. The justification is the chain.

The investigator moves on. No 483.

Getting started

The fix is not a forklift migration. It is establishing the recipe spine for one program — usually the next program entering tech transfer or PPQ.

Pull the current master batch record into the structured graph. Link CPPs and CQAs as objects, not table rows. Tag Established Conditions on the elements that carry regulatory commitments. Capture the raw material AVL with qualification context. Lift the cell line and bank lineage. Attach validation and comparability evidence as linked records, not folder contents.

The first program takes weeks. The next tech transfer runs against the spine instead of a document package. Programs already in commercial benefit from MSAT moving onto the spine without disturbing the GMP master batch record until the next change cycle. Pre-IND programs benefit from starting structured.

The companies that made this transition stopped having the recurring conversation about which version is current.

Capabilities

Tech transfer without the re-entry. Process definitions carry forward from development to GMP and across sites as structured, version-controlled assets.
Process knowledge across dev, transfer, and manufacturing. AI-extracted from historical batches. Unified with MES, LIMS, and QMS.
The development process becomes the GMP process. AI-configured promotion, not re-authoring. Unified with MES, LIMS, and QMS.
Specifications, processes, and stability data generated from structured operations. Not assembled from copies. One source across FDA, EMA, PMDA.
05Recipe as a Versioned Graph
Unit operations, CPPs, CQAs, raw materials, equipment — one structured graph from PD bench through commercial. Master batch record, MSAT model, and CMC narrative are views of the same object.
06Recipe-Driven Development
PD runs experiments against a draft recipe from day one. Every DOE result attaches to the parameter range it informed. The CPP justification is the chain of experiments that established it. No more end-of-program translation into a master batch record.
07One-Click Tech Transfer
Click the recipe version, select the receiving site. The receiver inherits the structure as one object. Site deltas declared with rationale. Comparability plan and engineering batch protocol generate from the delta list. Months of document assembly collapse to weeks of technical work.
08Established Conditions · ICH Q12
Tag ECs on the recipe element itself. Change classification (Prior Approval, CBE-30, Annual Reportable, non-EC) computes from the cascade. PACMPs route reduced-reporting changes automatically.
09MSAT Continuity & CPV
Every campaign learning attaches to the unit operation, CPP, raw material, or equipment it concerns. ICH Q10 CPV runs against the live graph. Knowledge stops being tribal.
10CPP / CQA / QbD Traceability
Every CPP linked to the CQA it impacts and the design-space evidence behind it. Click any CQA, see the parameter chain that controls it and the clinical risk it links to.
11Cell Line & Bank Lineage
Research cell line, MCB, WCB, EOPCL — linked objects with characterization, stability, and passage history. The lineage your BLA describes is the lineage in the freezer.
12Raw Material AVL & Single-Source Risk
Approved sources on the item with animal-origin status, GMP-grade qualification, audit history, and change-notification subscription. Sole-source critical materials surface continuously.
13Multi-Site Comparability
Each site runs the recipe as a versioned instance with declared deltas. Comparability evidence links to the versions it bridges. Adding a site stops being a six-month documentation exercise.
14CMC Submission Generation
Module 3.S.2.2, 3.S.2.4, 3.S.2.5, 3.P.3.3 render from the live recipe graph. Variations compute the diff against the prior submission. Annual product review compiles itself.
15Recipe Change Cascade
A proposed change runs cascade analysis before approval — affected sites, transfers, CMC sections, validation evidence, comparability scope, EC classification. Approve with the implications in front of you.
16AI Cascade Prediction · Neil
Neil prints the cascade before submission: every BOM, parameter, validation, EC tag, in-flight batch the change touches. Flags silent site divergence, drifted CPPs, and single-source raw material risk continuously.
01 / 16
Tech Transfer
Tech Transfer

Entities

Entity
Description
Blueprint
Kind
Product
The biologic. mAb, fusion protein, AAV, cell therapy, vaccine. Or the device for combination products. The center of the lifecycle.
Product Lifecycle Management
type
mAb-Alpha
Anti-cytokine monoclonal antibody. Phase 3 commercial-launch program. Multi-site, sponsor + CMO.
Product Lifecycle Management
instance
Process
The manufacturing process as a graph. Unit operations, parameters, materials, equipment — versioned and cascadable across sites.
Product Lifecycle Management
type
GMP Process
The development process, promoted. Same data structure. Validated parameters. No re-authoring.
Process Development
instance
PD Process
Bench-scale process under design. Wide ranges, design-space exploration, scale-down model qualification.
Product Lifecycle Management
template
GMP Clinical Process
Process locked for clinical campaign. Master batch record approved. CPP ranges established. Validated for clinical use.
Product Lifecycle Management
template
Process v3.2
Version transferred to the CMO in March 2024. Source for the CMO's master batch record. Did not see the v3.3-v3.5 iterations.
Product Lifecycle Management
instance
PPQ / Validation Process
Commercial-scale process running PPQ. Three consecutive validation lots. Comparability to clinical material established.
Product Lifecycle Management
template
Commercial Process
Approved commercial process. CPV in place. MSAT actively stewarding. Subject to change control with regulatory cascade.
Product Lifecycle Management
template
Process v3.5
MSAT-iterated version. Tightened CPP ranges from internal commercial data. Described in the CMC submission. Never pushed to the CMO.
Product Lifecycle Management
instance
Tech Transfer Package
Not a PDF bundle. A promotable process definition with all context intact.
Process Development
template
Equipment Equivalency
Justification for equipment substitution across sites.
Manufacturing Science & Technology
instance
Site Readiness
Assessment of facility capability for process execution.
Manufacturing Science & Technology
instance
Unit Operation
Cell culture, harvest, capture, polish, UF/DF, formulation, fill. Each linked to its CPPs, materials, equipment, and the CQAs it controls.
Product Lifecycle Management
type
Upstream Unit Op
Cell expansion, bioreactor, harvest. CPPs include feed strategy, DO, pH, temperature, harvest criteria.
Product Lifecycle Management
template
Downstream Unit Op
Capture chromatography, polish, viral inactivation, UF/DF. CPPs include load criteria, gradient, residence time.
Product Lifecycle Management
template
Fill / Finish Unit Op
Formulation, sterile filtration, fill, lyophilization, inspection. CPPs include fill volume, lyo cycle, container closure.
Product Lifecycle Management
template
Critical Process Parameter
Parameter with a controlled range. Linked to the CQA it impacts and the design-space evidence that established the link.
Product Lifecycle Management
type
Operating Range
Proven acceptable range with development rationale.
Tech Transfer
instance
Critical Quality Attribute
Purity, potency, aggregates, HCP, residual DNA, glycans. Linked back through CPPs to clinical risk.
Product Lifecycle Management
type

FAQ

Those tools were built for discrete-manufacturing BOMs — assemblies of physical components. They model parts and revisions well. They do not model a biologics process: unit operations linked to CPPs, CPPs linked to CQAs, raw materials with animal-origin status, cell line lineage, multi-site comparability, CMC submission rendering. Seal models the process the way biologics manufacturing actually works, and it's the operational system, not a sync target. The CMC submission, the master batch record, and the line are views of the same object.
The vendors in this space are largely consultancies that built software around their domain expertise. The simple version of recipe management — flow diagrams, parameter tables, version control — is straightforward to build, which is why many tools look superficially similar. The differentiator is connection: whether the recipe is linked to PD experiment data, MSAT campaign data, validation evidence, EC tagging, and CMC submissions on the same operational graph, or whether it sits in a separate tool that synchronizes with the systems that hold those records. Seal is the operational system, not a sync target — that's the architectural choice. We integrate with extensible APIs and modern data structures (REST, JSON, OPC UA), so existing tools that have a well-defined job stay where they are.
Control systems and DCS, time-series historians, instruments and their SDMS, ERP, and eCTD publishing tools. Seal is the structural recipe spine that sits above and adjacent to those systems. We do not run the control loop, we are not on the critical control path, and we do not become the time-series store. Modern APIs make the integration boundary clean.
The CDMO inherits the sponsor's process as a structured graph, not a document package. Site-specific deltas are explicit and rationalized. The live link between sponsor and CDMO recipe versions is preserved — when the sponsor iterates, the CDMO sees the change request and decides explicitly whether to inherit. Branching is recorded. The sponsor cannot silently get ahead of the CDMO, and the CDMO cannot silently lag behind. Comparability evidence between the sponsor's clinical material and the CDMO's commercial material attaches to the version pair it bridges.
Yes — and the value is amplified. Every sponsor program lives on its own recipe spine with per-client data isolation. Your MSAT team works across N programs for N sponsors without cross-contamination of records, audit trails, or change-control workflows. Each sponsor's live link surfaces only their program. The audit-readiness benefit is per-client: when sponsor A's auditor arrives, they see sponsor A's complete chain — recipe, comparability, deviations, CPV — without your team running a quarterly assembly exercise. See the CDMO blueprint for multi-tenant client-portal capabilities that compose on top of this spine.
It means PD scientists work directly on the recipe graph from the first experiment, not a separate set of lab notebooks that get translated later. Every experiment runs against a draft recipe version. DOE results attach to the parameter ranges they informed. CPP justifications are the chain of experiments that established them. Platform recipes become reusable starting points for new programs. The transition to GMP is a lock event — sign the master batch record — not a translation exercise. The recipe and the master batch record are the same object viewed differently from day one.
Click the recipe version, select the receiving site, and the system creates the receiver's recipe instance as a structured inheritance. The receiver reviews each element and declares site-specific deltas where their site differs (column geometry, fill volume, GMP-grade media qualification, site SOPs). The transfer comparability plan and engineering batch protocol generate from the delta list. The packaging step that used to take months collapses. The meaningful technical work — process fit assessment, comparability execution, site qualification — is what remains.
No. Seal generates the CMC narrative content — 3.2.S.2.2, 3.2.S.2.4, 3.2.S.2.5, 3.2.P.3.3, and related sections — from the live recipe graph. The output integrates with your eCTD publishing tool for final assembly and transmission. Seal is the source of truth for CMC content. Your publishing tool handles the regulatory packaging.
Those blueprints describe specific functions. PLM is the spine they all share. The recipe graph is what MSAT iterates on, what Tech Transfer cascades, what Process Development matures, and what CMC renders for submission. If you adopt PLM as your structural backbone, the function-specific workflows compose on top of it without separate sources of truth.
ECs are tags on the recipe element itself, not a list in a separate document. When you propose a change, the cascade walks the affected elements, reads their EC classifications, and computes the regulatory category — Prior Approval, CBE-30, Annual Report, or no filing. PACMPs attach to the ECs they manage, and qualifying changes route through reduced reporting automatically. The Product Lifecycle Management Strategy document Q12 expects renders from the live tagging. Strategy and operation cannot disagree because they're the same object.
Analytical methods are first-class objects in the same graph, with method-specific CMAs (critical method attributes), validation evidence, and the CQAs they measure. Q14's enhanced approach — design space for methods, lifecycle management, post-approval changes — runs the same cascade as the manufacturing process. When a method changes, the system shows which release specs depend on it, which stability studies use it, and what regulatory category the change carries.
Yes — and the model is especially valuable for CGT because the process is the product. Vector lineage, donor material chain of custody, autologous batch genealogy, dynamic batch sizing, and the tight CMC linkage between process and clinical lot all map to first-class objects in the same graph. See the Cell & Gene Therapy blueprint for CGT-specific workflows that compose on top of this spine.
Scale-down models are versioned process instances with explicit relationships to their parent commercial process. Qualification studies link the SDM to the commercial process and identify which CPPs the model is qualified to predict. Design-space evidence attaches to the CPP it establishes. When the commercial process changes, the system flags whether the SDM qualification still holds.
Combination products structure as a single product with biologic and device constituents, each with their own process and BOM, plus an interaction layer. The biologic side runs on the recipe graph described here. The device side runs on a discrete BOM with revisions, AVL, and ECO cascade. The submission view renders the right format for each constituent — Module 3 for the biologic, DMR or design dossier for the device — from the same underlying objects.
Most teams start with one program — usually the next one entering tech transfer or PPQ. Pull the master batch record into the structured graph. Lift CPPs, CQAs, raw material AVL, and cell line lineage as objects. Attach validation and comparability evidence as linked records. The first program takes weeks. The next tech transfer runs against the spine instead of a document package. Programs already commercial benefit from MSAT moving onto the spine without disturbing the GMP master batch record until a normal change cycle.
Yes — including off paper-based systems, shared-drive change control, traditional eQMS, and low-code build-it-yourself platforms. The pattern is the same: structured import of the master batch record, item master, AVL relationships, and historical change records, then operational cutover at the next planned campaign or change cycle. Recent migrations have included teams that adopted a low-code platform expecting to build on top of it, then concluded that without a structural data model the build was effectively writing their own software inside someone else's tool.
If you adopt Seal's MES, the master batch record is the same object as the recipe graph — execution becomes a direct rendering with no sync. If you keep an existing MES, Seal exposes the recipe graph and the change cascade via API, and your MES remains the execution system. Either way, the divergence between 'the process MSAT thinks is current' and 'the process the line is running' becomes structurally observable instead of invisible.
Neil reads the sender's recipe graph and the receiver's site context, then drafts the transfer comparability plan, the parameter delta table, and the site-specific change requests. During execution, Neil compares incoming CMO batch records against the current process version and flags discrepancies before they become campaign issues. After transfer, Neil monitors for silent divergence and surfaces it to MSAT.
Every CMC commitment — animal-origin-free media, single-source resin, MCB lineage, characterization battery — attaches to the object it concerns as a structural commitment, not a paragraph in a document. When a supplier change notification arrives, when a cell bank approaches expiry, when a raw material is being reconsidered, the affected commitments surface immediately with the submission sections that depend on them.

Go live in 48 hours.