Instrument data. Connected to the work.

1A traditional SDMS archives the file. Seal connects it to the work.

A traditional SDMS is an archive for instrument files. It keeps them beside the work: the result, the batch it informs and the investigation that assesses it live in other systems and point back by filename, and a parser or mapping change is a project of its own. Yet the lab needs a result, manufacturing needs to know which batch it informs and quality needs the evidence behind the decision.

Seal captures the same files with Seal IoT and treats each acquisition as a record with relationships. In Figure 1, ACQ-1842 keeps its five original files and links to sample QC-1842, batch B-041 and investigation DEV-018, so a reviewer, an investigator and Neil reach the same preserved original from the work they are doing. That work runs in one platform, with the original scientific data still available to inspect. A revised format, parser or mapping goes through change control, and earlier files keep the interpretation they were reviewed under.

You do not have to replace every system to start. Seal IoT collects the exports your instrument software already writes, from Waters Empower, Chromeleon and OpenLab CDS to the rest of the instrument directory. Connect the source needed for the first job, agree which system owns each record and verify the mapping. Review ambiguous matches rather than silently attaching a result to the wrong sample.

2Install Seal IoT. Connect the instruments you already use.

Seal IoT is the installable agent that connects local instrument output to Seal. It runs beside the instrument software, sends each file over outbound HTTPS and keeps the original as it was written.

Run it on a Windows or macOS machine with access to the source files: an instrument workstation, a local staging machine or a host that can read the relevant network share.

Choose the folder, whether to include subfolders and which Seal template should receive the files. A file-watch trigger detects new or changed files, waits for file-size stability and runs a configurable script to upload the file as an attachment to a record. Different sources can use different triggers and templates.

This makes the connection adaptable to the laboratory. The vendor application continues to acquire the data; Seal IoT bridges its supported exports into the workflows your team runs in Seal. Preserving a proprietary file and interpreting its contents are separate capabilities. Agree and verify the required formats, extraction and mappings for each source.

2.1What IT needs to know

The documented folder-upload route needs no inbound connection to the workstation. Confirm the rest with IT before installation.

Test connectivity from the actual host before relying on it. Windows network shares use the running account’s permissions, so an unattended installation needs its own account and the host’s startup arrangement. Authentication and agent updates use service domains beyond seal.run; review the full allowlist, update behaviour and operating responsibilities before deployment.

2.2What happens when capture is interrupted

The agent exposes connection diagnostics, recent runs and errors. Upload scripts can retry transient failures. Startup capture can include files already present, so files that arrived while the agent was stopped can be picked up if they remain at the source.

That recovery needs an agreed source-retention window and reconciliation rules. A changed file can trigger another upload; the basic folder-to-record script does not deduplicate by filename. Define how acquisition identity, retries and changed content are handled before treating the connection as ready for use.

3Capture the acquisition, not just the report.

A chromatographic run may produce raw data, a method, a sequence, an audit trail and a report. Define the required file roles for the source: a finished PDF does not prove that the rest arrived.¹

A chromatographic record is dynamic: the baseline can be changed and the data reprocessed. A printout or static report does not preserve that format, so it cannot stand in for the original.²

Configure capture around the supported interface: an export, watched location or API. Account for files still being written, late companion files, duplicate transfers and interrupted connections. A missing file and, where a checksum check is configured, a checksum mismatch require different responses.

Preserve the original bytes and their source metadata.³ Record capture time separately from acquisition time, and keep the source identity behind any normalised timestamp. Extracted values carry their parser and version so reviewers can trace them back to the file.

4One platform from acquisition to investigation.

Scientific data sits alongside lab workflows, electronic lab notebooks, manufacturing and quality management in Seal. The acquisition links to a sample; the sample links to a batch; an investigation points to the evidence it assesses.

Those relationships give people and Neil a common context. They distinguish an original file from a processed result, an approved report from a draft and a complete package from one still waiting for review.

5A new result must not erase the old one.

Reprocessing, reintegration and report generation create derived records. Keep the input objects, method and software version, changed parameters, reason and output together.

Reviewers should be able to compare the earlier result with the new one and reach the same preserved acquisition from either.⁴ Saving only the final result of reprocessed chromatography is not enough: each result is retained for review.⁵

Review covers the source evidence and the changes, not only the final number. Findings, responses and required signatures belong to the package being assessed.

6Neil prepares the work. Your team decides.

Neil is Seal’s AI agent. Ask which acquisitions support a batch, what changed between two reports or where an investigation is missing evidence. Neil follows the records the requester is permitted to see, connects the findings and prepares the next step as work in Seal; your team inspects the sources and reviews the conclusion.

That starts with usable context: the sample, instrument, method, acquisition and version. Unsupported formats, missing records and unresolved matches remain visible rather than becoming confident guesses. Neil can assist an investigation, but it does not turn receipt of a file into approval of a result.

Nothing Neil produces takes effect on its own. Neil stages changes for review; authorised people check a capture configuration against the source, run the required verification, sign and publish the change, and approve results. Existing acquisitions keep the configuration they were captured under.

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. See how Neil fits Annex 22 and more about Neil.

7Evolve the connection under change control.

A software upgrade can change a file format. A new method can add a companion file. A parser update can change an extracted value. Treat these as controlled configuration changes, with affected requirements, specifications and verification linked to the version that will enter use.⁶

Seal’s continuous validation approach keeps that work in the platform. Verify representative inputs and failure cases, review the impact and approve the change. Keep existing records connected to the configuration and processing history that produced them.

For a Seal IoT connection, the change scope includes the agent version, trigger script, source path, destination template and metadata mappings. Keep the relevant user requirements, functional and design specifications, configuration specification and verification evidence linked to the change. Neil can assemble them in a changeset with the revised configuration and verification cases. Repeat the affected checks when the configuration changes; investigate exceptions before release. Installation alone does not validate the end-to-end workflow.

8Retrieve the evidence when it matters.

Query by the work you recognise: sample, batch, method, instrument or investigation. Confirm why a record matched and whether it is the original, a derived result or a report. Access permissions still apply to queries, Neil and export.

Retention is specific to the record and its governing policy—not a universal number of years. Define the start event, policy version, holds and disposition authority. Test restore and readability with the required files and applications; storing a binary is not the same as being able to review it later.

For an inspection or migration, keep the selected objects, manifest, identity mapping and verification evidence together. Clearly distinguish a migrated rendition from a native original.

9Prove one source before expanding.

Bring one representative acquisition and the question or workflow it needs to support. Confirm the vendor interface, file formats, required companions, ownership and review expectations. Start with a sample, or arrange an NDA before sharing confidential records.

Include a late file, a duplicate transfer, a clock discrepancy and a failed integrity check in the evaluation. Demonstrate the path from capture to retrieval, including what happens when the expected evidence is absent. Then extend the pattern to the next instrument or laboratory. To scope that first source with us, book a demo.