QC connected to the whole batch.

1A traditional LIMS reports the result. Seal connects it to the batch.

A traditional LIMS is a system of record for the laboratory. It registers samples, runs tests and reports results, and it sits beside manufacturing and quality rather than sharing their records. But an analytical result is only part of a release decision. The reviewer also needs the sample identity, method, specification, original instrument data and any investigation, and when these live in separate systems, a finished test becomes the start of another search.

Seal’s shared ontology defines the record types and relationships across laboratory, manufacturing and quality work. The sample links to the manufacturing step it informs, the result to its specification and the investigation to the affected sample and batch, so a reviewer can follow a result to the work that produced it, with its preparation, source data and investigation in view. Earlier results retain the method and specification they used, and the same platform supports development, routine testing and the changes between them.

You can start with one release test, alongside the LIMS you already run. Seal reads samples and results from LabWare, LabVantage and SampleManager without writing to them, so a batch review can draw on laboratory evidence that stays where it is. See all integrations. The advantage grows as laboratory, manufacturing and quality work on the same connected records: less reconstruction between teams, and a shorter path from a result to the decision it supports.

2Neil prepares the work. Your team decides.

Neil is Seal’s AI agent. It works across the same records your analysts and reviewers do, within the permissions of the person asking, and what it produces is work in the system: a proposed method workflow, an assembled investigation brief or a prepared configuration change. It does not hand back text to paste somewhere else.

Everything in the middle column is preparation. Nothing Neil produces takes effect until a qualified person has reviewed it: a proposed workflow is checked against its source before release, and a suggested cause does not close an investigation.

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 the requester’s permissions govern what Neil can read. See how Neil fits Annex 22 and more about Neil.

3Take the sample from receipt to a reviewed result.

Register the sample with its material, batch, collection point and required tests, and assign the method and specification versions before execution. Completing a test is not the same as releasing a batch.

Configured checks identify missing results, values outside limits and outstanding review. Manufacturing and inventory use the authorised disposition from the same record, not a copy of the result.

A result starts before the instrument run. Link the received sample to the aliquots, preparations and dilutions used for each test, with quantities, units, reagent lots, preparation time and analyst. If a preparation is repeated, keep its identity and the reason rather than blurring two preparations into one result. Configure calculations as part of the method, with explicit inputs, units and reporting rules, and verify boundary values, missing inputs, division by zero and rounding whenever the calculation changes.

Record what was fit for use when the test ran. Connect the reference standard’s certificate, assigned value, storage requirements and permitted use period to the preparation, so an investigator can find the work affected by a standard-lot issue. Bring instrument calibration and qualification together with the analyst’s method-specific training and authorisation, and retain the evidence applicable at execution. A later training update should not obscure who was qualified for the original work.

4Check the result against the right version.

Specifications are structured, versioned records. Each result is evaluated against the version assigned to it, and keeps that version when the specification changes.

Keep the measured value, unit, calculation and assigned limits together. A water content result of 0.72% against a limit of ≤ 0.50% is outside limits, and the investigation must retain that result even when further testing is justified.¹

A revised specification does not silently rewrite the basis of earlier decisions. Its applicability to products, markets and work in progress is reviewed as part of the change. Historical testing retains the version used, so a reviewer can establish which limit applied and why.

5Review the evidence, not only the number.

Review the original acquisition and relevant processing history, not only a PDF of the final result.² In Seal the investigation opens on the same records as the result it concerns.

Connect the preparation, system-suitability evidence, calculations and relevant audit-trail entries, and record questions and their resolution against the work they concern. Missing evidence stays a visible gap, and the investigation records the laboratory assessment, hypotheses, further work and conclusions.

Keep three decisions distinct: whether the reported value meets its assigned limits, whether the laboratory evidence is complete and acceptable, and whether the batch can be released. Laboratory review contributes to batch disposition alongside manufacturing exceptions and quality events. Record the reviewer, signature meaning and approval against the version reviewed.³

Because the records are shared, Neil can answer questions that cross the usual boundaries: “Which batches used standard lot WS-041, and which still have an open laboratory review?” It can compare findings by product, method version, instrument or standard lot and prepare a source-backed brief that states the records compared, the pattern found and what is still unknown. Your procedure governs further testing and escalation. Neither a suggested cause nor a passing repeat result closes an investigation by itself.

6Capture instrument data once.

Capture each instrument file once, keep the original with the result it produced, and map its values into the record rather than retyping them.

For file-based acquisition, install Seal IoT on the instrument workstation or an appropriate local computer. Configure the watched folder, processing script and destination record. Retain the original export and map available sample identifiers, values, units and acquisition metadata into the workflow.

Other sources may use supported interfaces or APIs. Assess the model, software version and actual output, not just the manufacturer’s name, and exercise missing files, duplicates, failed transfers and recovery before relying on the connection. A file that arrives does not by itself show that the acquisition is complete or the result valid. Scientific data management explains the capture route; the instrument directory helps scope the source.

7Incoming, environmental and stability work share the same records.

Incoming inspection, environmental monitoring and stability use the same samples, methods, specifications and reviews as release testing. Each result stays linked to the material, location or study it concerns.

Incoming inspection connects the supplier lot, CoA, sampling plan and analytical work. Supplier values are compared with the required tests, discrepancies are recorded for assessment, and inventory uses the authorised material disposition without copying the decision into another application.

For environmental monitoring, retain the location, sampling method, time, conditions and result. Compare like-for-like populations and keep action limits distinct from trend signals: a rising count can warrant investigation below an action limit, but its interpretation depends on the sampling context.

A stability study connects the protocol, storage conditions, pull schedule, samples and results, with each timepoint carrying its assigned method and specification. Missed pulls, chamber excursions and atypical results stay with the study evidence. Trends across batches and conditions help reviewers assess emerging changes; any extrapolation needs a scientific basis and review, and a projected trend is not a shelf-life decision.

8Change methods and configuration under control.

An analyst runs the approved method version, and the next improvement is a reviewed change rather than an edit. Earlier runs keep their original context.

Develop methods in Seal’s ELN, then bring the approved version into QC with defined parameters, calculations, system-suitability checks and review requirements, keeping the development evidence that explains those choices. A new column, revised calculation or updated limit becomes a reviewed configuration change with its impact and verification evidence.

Continuous validation is part of that change. Keep the user requirements, functional and design specifications, configuration specification, verification results and approval together in Seal, and update them with the configuration they describe.⁴ Automated verification and repeatable UAT checks exercise both intended behaviour and failure cases: a missing unit, an out-of-range result, an unapproved method version or an incomplete review. Your team assesses impact, reviews the evidence and approves release. The continuous validation detail explains the risk-based approach and the responsibilities.

9Give Neil the next method to configure.

Bring an approved specification, method or validation report. Neil turns it into a proposed workflow: test names, parameters, calculations, acceptance criteria and review gates.

Your team checks the interpretation against the source and resolves ambiguity before release. For a potency method, evaluate the preparation calculation, required system-suitability records and assigned limits, and test that an outside-limit result follows the investigation route and that missing evidence prevents completion.

Start with one release test, incoming-inspection workflow or stability study. Agree the intended use, representative sample data and acceptance criteria; connect one source and exercise the workflow. The 48-hour evaluation turns that one workflow into a working process with a validation pack to inspect. Production timing then depends on scope, interfaces, migration and your release requirements, and existing systems can continue serving the work outside that scope.

9.1What to bring to the first conversation

• The work: one method or procedure and the bottleneck you want to remove.
• The evidence: a redacted specification, representative result and instrument export.
• The decision: who reviews the configuration and what must be demonstrated before use.

When these are ready, book a demo and we will scope the evaluation with you.