Start in development. Grow into manufacturing.
A biotech changes shape as its science progresses: exploratory experiments become a selected process, a CDMO transfer and a clinical manufacturing operation. Seal gives that work a shared ontology, so the programme can add capabilities without rebuilding the history behind its decisions.
Process definition
Process v04
- Instructions
- Unit operations and required steps
- Structure
- Materials, samples, parameters and methods
- Controls
- Required references and review points
Used by separately identifiable executions
PD-031
- Process
- v04
- Scale
- 2 L
- Assay
- v03
ENG-004
- Process
- v04
- Scale
- 200 L
- Assay
- v04
Each run keeps its actual materials, conditions, samples, results and review history.
An ontology your team can build on
Define the objects that carry meaning across disciplines: a construct or cell line, material lot, process candidate, experiment, sample, analytical method and quality attribute. Configure their relationships and the fields the work requires. A result belongs to a sample; the sample belongs to a run; the run preserves the process version and actual conditions. Those relationships let scientists and Neil follow a conclusion back to the work that produced it.
Keep definitions separate from their use. A material specification differs from a received lot. A method definition differs from an assay execution. A process candidate differs from the batches run using it. A potency result retains its value, units, reference standard, method revision and source data; the interpretation is a reviewed conclusion linked to those observations.
Build around the systems you already use
Your ELN, laboratory systems and partner repositories can remain sources. Agree which system owns each record and preserve its identifier, version and original reference when connecting it to Seal. Define how corrected results and superseding reports enter the programme, so an old extract does not remain the basis for a current decision.
Start with the workflows the team needs now. As the intended use matures, add controlled versions, required fields, signatures, qualification checks and formal review through assessed changes. Earlier studies keep their original context. A development protocol can become the basis for manufacturing while the organisation retains how and why it arrived there.
Make the next experiment build on the last.
A promising result needs its operating conditions. Build upstream, downstream and analytical protocols that capture actual equipment, material lots, interventions, sampling times and calculations. Compare the runs from that context, then use Neil to prepare the next study or process revision.
Capture the process as it runs
Scientists can investigate different conditions while preserving which version and actual execution produced each observation. Record planned conditions separately from measured values and departures from the plan. A higher response is a starting observation; assess confounding changes, missing replicates, method differences and the limits of the scale model before it informs the next experiment.
Develop the method alongside the process
Analytical development belongs in the same assessment. A programme can appear to improve because its measurement changed. Keep sample preparation, method revision, reference-standard lot, fitting procedure and review state with the result. When an assay evolves, record the change rationale and comparison evidence with both versions.
In the transfer example below, three development runs use assay v03 and the engineering batch uses v04. Neil identifies the missing bridge. The analytical team can define the comparison, locate suitable retained samples and document the evidence needed before the results support a transfer decision.
Carry the rationale into manufacturing
As characterisation progresses, link proposed parameter ranges to supporting studies and the quality attributes they affect. Record the product, equipment, scale, method and process version covered by each conclusion. Apply the same structure to method qualification, validation and transfer: intended use, protocol, acceptance criteria, source data, deviations and reviewed conclusion. MSAT receives the reasoning behind the range, including where it still needs to be tested.
Transfer a working process, with its reasoning intact.
Transfer the selected process with its unit operations, material requirements, parameter rationale, sampling strategy and analytical methods. A configured process in Seal can be copied, with permission, into a separate receiving draft. Neil helps compare the source and destination and prepare the work needed to resolve their differences.
Development evidence
2 L- Process
- v04
- Assay
- v03
- Relative potency
- 87% / 89% / 91%
Receiving-site evidence
200 L- Process
- v04
- Assay
- v04 · changed
- Relative potency
- 94%
Neil identifies a missing assay bridge. Analytical development owns the comparison; the transfer lead retains the acceptance decision.
Copy the definition. Resolve the site differences.
The receiving team assesses equipment assignments, scale, material grades and methods for the intended manufacturing operation. Keep each difference linked to its affected step, responsible owner, requested studies and receiving version. A delivered report contributes evidence; technical acceptance and authorisation to manufacture are recorded decisions with their own basis.
The receiving draft retains the selected process content, fields and configuration that the destination is permitted to use. Review referenced records, site equipment, roles, units and local procedures. Completed executions and checkpoint signoffs belong to their original records. The source and receiving versions remain separately identifiable.
Give Neil the source process and receiving plan. It can prepare a structured difference assessment, identify supporting studies and propose configuration changes with verification cases. The result is work the receiving team can act on: an equipment assessment, a method comparison or an adapted workflow. Assess and approve that work before the new version governs manufacturing.
Own the programme, even when partners run the work.
A virtual biotech still needs an operating view of its programme. Bring the CDMO’s manufacturing work, the testing laboratory’s results and your own decisions into the same project context. Know which version each partner is using, what is due next and who can resolve an open dependency.
| Programme records | Your team | CDMO | Testing lab |
|---|---|---|---|
| In the agreed sharing scope | Outside the agreed sharing scope | Outside the agreed sharing scope | |
| In the agreed sharing scope | In the agreed sharing scope | Outside the agreed sharing scope | |
| In the agreed sharing scope | In the agreed sharing scope | In the agreed sharing scope | |
| In the agreed sharing scope | In the agreed sharing scope | Outside the agreed sharing scope |
Make the handoffs part of the workflow
Model each partner’s scope, deliverables and dependencies. A sample shipment connects to its testing request; the result connects to the method and batch; a transfer question connects to its owner and evidence. Source timestamps and review states distinguish a received update from confirmed completion. Teams can work through a configured portal or exchange records from their existing systems.
Share the work each partner needs
Give each partner access to the selected records and actions its work requires. An analytical laboratory may need sample identities and the agreed method; a CDMO may need the receiving process and approved transfer package. Internal candidates, commercial information and unrelated programmes can stay outside that scope. Configure and verify access to the underlying records, linked files, search and exports as well as the visible portal.
Prepare updates from the programme record
Ask Neil to assemble the current milestones, missing records and unresolved commitments from permitted sources. Keep the source references with the update and let the programme lead review its content and audience. The same underlying work can support a scientific review, an operational meeting or an agreed partner update without rebuilding each report from scratch.
Build the CMC package as the programme progresses.
A chemistry, manufacturing and controls claim draws on product, process, analytical and stability evidence. Link it to the exact studies, methods and manufacturing versions that support it. The programme should show both the available observations and the work still needed to support a conclusion.
| Batch | 9 months | 12 months |
|---|---|---|
| DP-201 | 99.1 | 98.7 |
| DP-202 | 98.8 | 98.4 |
| DP-203 | 99.2 | Pending |
Two reviewed 12-month results are available. DP-203 remains pending in the proposed refresh.
Keep every conclusion attached to its evidence
For a proposed process change, follow the affected material specifications, parameter ranges, analytical methods and control strategy. Identify studies and documentation that need assessment. Retain the earlier evidence set and assemble the revised package around the proposed version, with its limitations, open commitments and review decisions.
Neil can gather permitted evidence, draft the narrative and flag an assertion whose supporting record is absent or inconsistent. Scientific and regulatory reviewers decide what the evidence supports and what goes into a submission. Each accepted conclusion should remain traceable to the underlying work and the scope for which it was assessed.
Evolve the operation through controlled versions
Changes to the operating system need evidence too. Identify affected instructions, fields, calculations, review paths, access and integrations. Verify normal execution and meaningful failure cases, then approve the configuration for its intended use. Earlier executions retain the instructions and calculations they used; a new effective version governs subsequent work in its approved scope.
This lets the organisation increase rigour as a candidate moves towards the clinic. Exploratory work remains recognisable as exploratory work. A reviewed development conclusion can support a controlled process, and an unresolved question stays visible until the evidence is sufficient. The history survives the transition.
Turn your team’s experience into AI capability.
Experience becomes more valuable when the team can apply it again. In Seal, build a library of study structures, calculations, sampling workflows and review methods. Neil’s persistent memory supplies relevant context; versioned skills describe repeatable ways to perform the work. Teams can refine both from reviewed outcomes.
Stays within the programme
- Product-specific assay and reference standard
- Development and engineering results
- Partner’s transfer decisions
Access follows the authorised scope for the job.
Method to review for reuse
- Identify the source and receiving versions
- Compare scale, materials and methods
- Name missing evidence and its owner
Give specialists a repeatable way to work
Create specialists for development, transfer assessment, validation or CMC preparation, with the instructions and permitted sources their jobs require. A transfer skill can require source and receiving versions, compare equipment and analytical methods, identify missing evidence and prepare the assessment in the team’s format. Review its output and test revisions against representative cases before wider use.
Reuse expertise within the right boundaries
Separate the reusable method from restricted programme evidence. A reviewed procedure for checking assay comparability can be shared; a partner’s proprietary assay, sequence or unpublished result remains within its authorised scope. Include remembered context, skill examples and attachments in the review. Set the memory, source access and sharing scope for each specialist; verify that restricted context stays within the intended boundary.
Improve the process that people actually run
The same learning can improve execution. Give Neil a recurring problem: inconsistent sample identifiers, a calculation rebuilt in every spreadsheet or a transfer assessment repeatedly missing the same evidence. It can prepare required references, calculations, review steps and verification cases in Seal. Your team assesses, tests and approves the proposed version.
A reviewed investigation can become a required check. An accepted reporting method can become a skill. A useful study design can become a reusable protocol. Record the component’s owner, applicability and adoption requirements so another programme can assess it in context. The next job begins with a better method while drawing its evidence from the records permitted for that job.
Start with the work that is holding the programme back.
Choose a decision or handover that currently takes too much effort to assemble. Bring the process, its evidence and the scientists or operational team who rely on it. Agree the objects, identifiers, source systems, access and outcome before configuring the workflow.
Prove the workflow with its users
Exercise the difficult cases: a changed assay, a missing source file, an inaccessible partner record and a conclusion contradicted by later evidence. Check whether reviewers can reproduce the answer, identify its limitations and find the next work. For a migration, reconcile identities, relationships, attachments and the history required for the new intended use.
Measure time spent assembling a decision, unresolved evidence requests, repeated transcription and the effort to configure the next workflow. Expand from the foundation that proves useful, adding quality and manufacturing controls as the programme requires them.
AQuestions and answers
Can we keep Benchling and our specialist analysis tools?
Yes. Scope the records needed for the programme decision and use configured connections or supplied files. Preserve the original acquisition and analysis context in its source system; link the selected evidence to the assessment and follow-up in Seal.
Is this only useful once we manufacture under GMP?
No. Run development protocols, capture material and sample context, compare experiments and prepare the next process with Neil. Add version control, qualification, signatures and formal release requirements as the intended use matures. Earlier development work retains its original context.
What does Neil produce for a transfer?
A source-backed gap assessment, proposed follow-up and, where useful, a draft process definition or workflow. Scientists and process owners confirm the interpretation and verify the proposed configuration before operational use.
Can our team build and change its own workflows?
Yes. Give Neil a protocol, a procedure or a description of the work. It can help prepare the process steps, fields, calculations and review paths in Seal. Your team checks the proposed configuration, tests it for the intended use and approves it. Earlier executions keep the version they used.
How does this work with a CDMO?
Configure the partner’s project, deliverables, records and permitted actions. Teams can work through a scoped portal or exchange records with existing systems. Connect the receiving process, batch evidence, testing and open transfer work to the programme. Review the access to linked records and files as well as the portal itself.
Can we reuse expertise across programmes?
Yes. A reviewed study structure, calculation, process component or agent skill can become part of a reusable library. Configure Neil’s instructions, memory and permitted sources for its work. Review skill examples, remembered context and attachments before sharing them: proprietary results and partner information remain within their authorised scope. A project name alone does not establish that separation.
What should our first project be?
Start with a development protocol, a sponsor-to-CDMO transfer or a recurring programme review. Bring the people who do the work, representative records and a concrete outcome. Configure the workflow, exercise its difficult cases and measure the time to prepare a decision or carry a process into its next use.