Deliver more. Evolve with AI.

1Each handover rewrites the process. Seal carries it through.

In a typical CDMO each stage has its own tool: a page-based ELN for development, a document package for transfer, a traditional MES or a paper record for manufacturing, a LIMS for QC, an eQMS for quality, and email for the client. Each handover asks someone to translate the process again, and the instructions, parameter ranges and studies behind them separate as the work moves between teams.

In Seal, development, transfer, manufacturing, quality and the client’s view work from the same configured process. Development records become transfer evidence; the receiving process becomes manufacturing work; the resulting records support quality review and the client’s view of delivery.

Every new client brings a different process, so the foundation has to be one your team owns and can adapt: development protocols, manufacturing workflows, quality controls and client portals. Knowledge carries from one stage to the next. With Neil working across that context, your experts can build new capabilities and turn what they learn into better ways to deliver.

Ingenza’s CEO, Ian Fotheringham MBE, on its process development and biomanufacturing operations:

“We have been delighted with the rigour and agility shown by Seal in providing Ingenza with a robust GxP system that fully supports our process development and biomanufacturing operations.”

You can start with one development workflow, transfer or client project, alongside the ELN, LIMS, ERP or QMS you already run.

2Make your process knowledge executable.

In Seal, configure a shared ontology for the objects your operation works with: products, unit operations, materials, equipment, samples, methods and process versions. Three linked records then do three different jobs.

2.1An ontology for the operation

A result belongs to a sample; the sample belongs to a run; the run records the process version and actual conditions. Those relationships give people and Neil the context to follow a result back to the work that produced it.

The process definition holds the unit operations, inputs, parameter ranges, calculations, samples and control logic, with the evidence behind its requirements. A site configuration holds the equipment assignments, local material references, scale, methods and approved adaptations, and keeps its relationship to the source process and the decisions behind each local difference. An execution record holds the batch or development run, with actual values, material lots, results, exceptions and signatures: what happened using that version, even after the process changes.

2.2Use the definition to govern execution

The process definition also governs execution. Required fields, calculations, permitted branches and review steps become part of the workflow. Your team can refine the same foundation as a project moves from exploratory development into controlled manufacturing.

3Make every development run useful to the next.

Build upstream, downstream and analytical protocols around the shared ontology, and keep each instrument result linked to the run and process version that produced it. Ask Neil to compare conditions, investigate an unexpected result or prepare the next study.

Configure the fields, calculations and checks the work needs: your process steps, materials, samples, methods and their relationships, while giving scientists room to explore. In the example, PD-024 recorded the highest titre, but feed and temperature both changed from the reference run, and PD-023 also moved to a larger vessel. One run per condition does not establish a cause or an operating range, so Neil says what changed and the scientists design the controlled comparison.

The selected process then travels towards scale-up with the evidence behind its operating ranges. The process development blueprint follows that work in more detail.

4Transfer the process. Keep the knowledge.

Start with a client’s documents, move a development process into GMP manufacturing, or transfer production between sites. Neil structures the incoming requirements, compares the source and destination and prepares the receiving workflow; your transfer team decides what is ready for use.

Technology transfer moves product and process knowledge between development and manufacturing, and between sites, and that knowledge becomes the basis for the manufacturing process, control strategy and validation approach.¹ For a CDMO, the agreement with each client also says who undertakes each step, including knowledge management and technology transfer.² Seal keeps that knowledge as the configured process and its evidence, rather than as documents to re-enter.

A client procedure that says “Record the material lot and pH. Transfer within 45 minutes of completing the mix” becomes a link to the material used, a numeric pH at the mixing step, a hold time calculated from mix completion to transfer, and a 45-minute limit with an exception path. The source stays beside the proposed configuration, and the team reviews the extracted requirements, time definitions and checks before using the workflow.

Equipment, scale, material grades and methods may change. Make those differences explicit, give each assessment an owner and keep the supporting studies with the decision. MSAT, engineering and quality can see what carries forward and what still needs to be established.

Resolve a longer hold in the schedule or assess it as a proposed change; do not extend the limit silently. A larger vessel needs its geometry, mixing and transfer arrangements compared against the process. A different method revision needs both versions, their change history and the agreed method-transfer work before use.

5The path to one-click technology transfer.

The destination is one-click preparation of a receiving process: select an approved source version and destination, then generate a manufacturing draft using established mappings. The engineering work is in the process library, the destination model and the rules for differences. Once that foundation exists, each transfer can reuse more of the work already done.

5.1What your team can do today

A permitted copy in Seal can retain the configured process content, fields, references and related rows as a separate draft. Completed checkpoints are cleared. Neil can compare source and receiving records and prepare a gap assessment. Your team establishes the site-specific configuration and approves it for use.

5.2Make the differences explicit

Treat the transfer as a set of explicit technical decisions. A larger vessel changes the scale question. A different material grade changes the material assessment. A method revision can change what two results mean. Keep each difference linked to the affected process step, its owner, the evidence requested and the receiving version it supports.

5.3Reusable process actions

Define activities such as buffer preparation, inoculation, harvest, column packing and sampling with their inputs, outputs and checks. Keep the activity definition separate from the local equipment assignment so it can be assessed for use at another site.

5.4Destination mappings

Record local equipment capabilities, working volumes, automation interfaces, material specifications and analytical methods. A matching name is only a mapping candidate; the receiving team records the suitability assessment and any supporting studies.

5.5Parameter rationale

Link the proposed set point or range to development runs, characterisation studies and scale assumptions. When a local change affects that rationale, the transfer package identifies the question and the evidence needed to answer it.

5.6A receiving version ready for review

Assemble the adapted instructions, requirements, assessments, test results and open actions around the draft. The click prepares a process for the receiving team; scientific assessment, qualification and release remain recorded decisions. The technology transfer blueprint shows a receiving-site draft in detail.

6Keep every batch moving.

Run production, sampling, testing and quality review against the same batch. Neil assembles the review package and finds missing evidence, so your team can act on what is holding work up.

Configure material checks, equipment readiness, sampling plans and review steps for the client’s process. Operators record the work as it happens; QC results and quality events stay linked to the batch they affect. The review team can follow an exception back to its source and see what remains open.

In the example, B-081 has completed manufacturing and QC testing, but its package is missing the original chromatography acquisition reference. “Testing complete” and “package ready” are different milestones, and the QC reviewer links and reviews the reference before package review can finish. B-082 is in QC testing and B-083 is in manufacturing. No release decision is recorded.

Across client projects, keep changeover and line-clearance evidence with the equipment and batches it governs. Shared equipment and materials can support several projects, with their use linked to the relevant work. Authorised reviewers retain the disposition decision; see batch review and release and manufacturing execution.

7Make visibility part of the service.

Give each client a portal for its project: milestones, selected results, shared documents and review work. The portal draws on the same records your team uses to run the work, so the client sees progress without your team rebuilding the story for every email.

Define which information is shared as work progresses, which needs review first, and which actions belong to the client. Clients can comment in context, with access configured for their project and role. Verify both permitted and denied access before opening the portal.

The client’s right to the records is part of the contract. EU GMP expects the records of outsourced manufacturing and analysis to be kept by, or available to, the contract giver,² and a quality agreement sets which activities each party performs.³ A portal on the working records makes that availability part of the service; the agreement still decides what is shared, with whom and when.

Neil can prepare a client update from the permitted evidence. In the example, the draft says B-081’s package review remains open, leaves internal investigation notes out under the agreed exchange scope and says that it does not represent batch release. Your project lead checks the sources, the selection and the recipients before anything is sent.

8Keep client work separate. Build a stronger platform process.

A CDMO needs to protect each client’s process and results while becoming better at the work it performs repeatedly. In Seal, client projects hold their products, specifications, runs, deliverables and decisions; your platform library holds the reusable methods and components your organisation is entitled to use across projects.

8.1Scope access to the underlying records

Configure access around the project, system and role. A scientist may work on several programmes; a client reviewer should see only the records and actions agreed for theirs. Include linked records, attachments, search, reports and exports in that design. A filtered dashboard is a view of the work; the underlying permissions determine access. Ingenza’s Head of Quality, Nicola Barnes:

“We can now easily share data and documents internally – with full control over access and editing!”

8.2Improve a shared method once

Figure 1 shows the pattern. Ask Neil to build your sampling method into a reusable component, keeping each client’s methods, results and limits in its own project. It proposes library v03, which requires the original result reference and leaves sampling points, method and limits to the project that adopts it.

Before adoption, the change is verified against the cases that matter. When Client B prepares a sample, the component uses Client B’s method and limits. When the original result reference is missing, the handover stays incomplete and names the missing evidence. When the library is revised, Client A’s existing executions keep v02, and adopting v03 is a separate change reviewed against Client A’s own process and access requirements.

8.3Turn a finding into authorised shared expertise

Learning across projects requires an explicit step from a finding to an authorised, reusable method. A team can improve its method for checking analytical-version compatibility without sharing the client’s assay, measurements or product conclusions. Review intellectual-property rights, remove restricted context and test the generalised method before adding it to the platform library.

9Neil prepares the work. Your team decides.

Neil is Seal’s AI agent. It works across the same records your team does, within the permissions of the person asking, and what it produces is work in the system: a comparison, a configured draft or an assembled package.

Everything in the middle column is preparation. Nothing Neil produces takes effect until a qualified person has reviewed it, and required people and signatures still control the decisions.

In line with the EU’s draft GMP Annex 22 on AI, Neil is not used in GMP execution. It helps set up configuration, which your team verifies and releases under change control. Customer data is not used to train AI models, and Neil reads only what the person asking may read, so the access you configure for each client applies to Neil too. See how Neil fits Annex 22 and more about Neil.

Give Neil the process you want to improve. It can build a new workflow, automate a calculation or report, and prepare the changes for review. Your specialists can put their knowledge directly into the system that runs the work. Your team tests and approves each new version before use; earlier batches retain theirs, while future work benefits from the improvement. See how changes are validated.

10Give your agents experience they can build on.

An experienced team retains useful precedent and develops better ways to do recurring work. With Neil, those two forms of knowledge can become persistent memory and reusable skills. Memory can preserve relevant context and past decisions. A skill describes how to perform a task, with instructions and supporting material that can be revised as the method improves.

10.1Specialists for the work you repeat

Create specialists for process development, transfer assessment, validation or client delivery. A transfer skill can ask for source and receiving versions, compare equipment and methods, identify missing evidence and prepare an assessment in your team’s format. User-authored skills are versioned, so the team can inspect and refine the method. Memory supplies precedent; the specialist must still check the current sources and process version.

10.2Give learned context an explicit scope

Define who may use the knowledge as carefully as who may read the source. Personal learned context and system review history have different access scopes. Review memories, skill examples, attachments and connected sources when setting up a specialist for client work. Only authorised material belongs in a shared skill; changing a project label or removing a client name does not establish that permission.

10.3Improve from reviewed outcomes

Inspect the completed work, capture an authorised lesson, then revise the skill or process component. Exercise known cases, missing inputs and exceptions against agreed criteria. A useful improvement can become a reusable calculation, sampling step or review path, with each client project adopting the appropriate version and supplying its own product values. The next project starts with better methods and controls while client evidence stays in its permitted scope.

11Connect the evidence at its source.

A shared process model can include work that stays in an existing instrument system, ELN, LIMS, ERP or MES. For each connection, agree which system owns the record, which identifier links it to the project, and whether Seal reads information, creates work or receives an approved result.

Available APIs, files and source permissions determine the implementation. You do not need to replace these systems to start; each can remain the source for its records while Seal runs the workflow and connects the evidence to review and follow-up. See all integrations.

11.1Preserve the meaning of an imported record

For an analytical result, preserve the sample and batch identifiers, method revision, units, acquisition reference and review state. For materials, distinguish the material definition from the supplier lot and its status. For equipment, distinguish the asset from the qualification, maintenance or calibration evidence relevant to its intended use.

11.2Reconcile exceptions at the boundary

Design the exception path as carefully as the successful import. An unknown sample, duplicate file, changed unit or revised result needs a defined reconciliation step. Keep the source reference and import context so the team can investigate a discrepancy without reconstructing how the record arrived.

11.3Report from the same source relationships

This gives reporting a stable basis. A client milestone, a batch-review package and a cross-project operational report can each use the appropriate permitted records and counting rules. Neil can assemble the evidence and explain gaps while the authoritative source remains identifiable.

12Start with one workflow. Build a lasting capability.

Bring a development workflow, a transfer package or a client project with a concrete problem to solve, and agree an outcome such as a useful run comparison, a receiving-site gap assessment or a client view of progress.

That might be a PD team assembling results by hand, a transfer held up by missing process knowledge, or a client project that needs better visibility. Map the workflow with its users, configure the records and integrations, and agree how you will judge the result.

For a legacy-system transition, plan the records, relationships, history and access that need to move. Reconcile the migration and verify the new workflow before cutover. Your team learns to build and maintain the process, so expansion to the next project builds on what is already working.