An instrument produces files. The lab needs a result. Manufacturing needs to know which batch it informs. Quality needs the evidence behind the decision. Seal connects that work in one platform, with the original scientific data still available to inspect.
Install Seal Edge. Connect the instruments you already use.
Seal Edge is the installable agent that connects local instrument output to Seal. 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. Existing installation materials call the agent Seal IoT Bridge.
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; Edge 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.
What IT needs to know
The documented folder-upload route uses outbound HTTPS on port 443 and does not require inbound ports. The running account needs access to the watched folder; Windows network shares use that account’s permissions. For unattended operation, configure a dedicated account and the host’s startup arrangement.
Scope the destination workspace and API credentials, and test connectivity from the actual host. Authentication and agent updates require additional service domains, not only seal.run. Review the full allowlist, update behaviour and operating responsibilities before deployment.
What 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.
Start with neil. Keep the evidence behind the answer.
Ask which acquisitions support a batch, what changed between two reports or where an investigation is missing evidence. neil can follow accessible records, connect the findings and help prepare the next step. Your team can inspect the sources and review the conclusion.
That starts with usable context: the sample, instrument, method, acquisition and version. Unsupported formats, missing records and unresolved matches need to remain visible—not become confident guesses.
Capture 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.
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 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.
Raw acquisition
sequence-1842.raw
Source measurementsMethod
assay-method-v08.xml
Acquisition settingsSequence
sequence-1842.csv
Sample and injection orderAudit trail
audit-1842.xml
Actions and changes3 of 4 required files received
The PDF report cannot stand in for the missing audit trail. Keep the package incomplete.
One 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.
You do not have to replace every system to start. 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.
A 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.
Review covers the source evidence and the changes, not only the final number. Findings, responses and required signatures belong to the package being assessed. neil can assist with the investigation; it does not turn receipt of a file into approval of a result.
Evolve 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 an Edge 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. Repeat the affected checks when the configuration changes; investigate exceptions before release. Installation alone does not validate the end-to-end workflow.
Retrieve the evidence when it matters.
Search 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 search, 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.
Prove 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.
