Build the device. Improve how it gets built.

1A traditional eQMS files the design history. Seal links it to every device built.

A device change can reach requirements, risk controls, software, components, manufacturing instructions and units already in the field. A traditional eQMS keeps the design history file, the device master record and each device history record as documents, joined by a trace matrix that someone maintains by hand. Each file is right for its own audit, but the team must reconstruct a change’s scope across all of them before it can decide what to do.

Seal makes those relationships part of the work. Engineering defines the product, operations records what was built, and quality follows the evidence across both: requirements link to design outputs, verification and risk controls, the released configuration links to the procedures used on the floor, and each unit links to the versions and lots it was built from.

The design history file (DHF), device master record (DMR) and device history record (DHR) are terms from the former Quality System Regulation. The Quality Management System Regulation, effective on 2 February 2026, incorporates ISO 13485:2016 and no longer uses them; FDA expects their contents in the records ISO 13485 requires.¹² Seal keeps all three as connected records, whichever names your procedures use.

Consider an illustrative infusion-device requirement, REQ-047, for flow accuracy. Its design output, verification protocol and recorded result need to remain identifiable together. Verification must confirm that design outputs meet design inputs and retain the evidence of that confirmation.³¹ The value extends beyond an audit. A proposed component revision can identify which tests and configurations need assessment, and a field report can be followed back to the unit’s actual build.

You can start beside the requirements tool you already run. Seal can read requirements, design controls and test evidence from Jama Connect, Siemens Polarion and Greenlight Guru through their APIs; see all integrations.

2Neil prepares the work. Your team decides.

Neil is Seal’s AI agent. Give it the device, the permitted records and the question. It works within the permissions of the person asking, and what it produces is work staged in Seal for review: a linked assessment, a check of trace coverage or the configuration behind the next intake or review workflow.

Describe the device to Neil, for example “Class IIb infusion pump with wireless connectivity”. Neil can propose a design-control framework, with requirement categories mapped to EU MDR general safety and performance requirements, a risk analysis structure following ISO 14971 and a technical documentation outline following Annex II. It can suggest hazard categories for the device type and intended use. The team reviews the proposal rather than starting from blank templates, and adds what is specific to the device.

During development, Neil can identify gaps: a requirement without linked verification, a risk control without effectiveness evidence or a GSPR without supporting documentation. Those gaps are then addressed in design reviews rather than before an audit.

Give Neil a field-report procedure and it prepares the intake: one retained source report with an owned device-identification request, a technical assessment linked to the identified unit’s as-built records, and a safety review that starts in parallel with its own owner, evidence and decision. The reporter’s account is preserved without being treated as an established technical cause. Its verification cases cover a missing device identifier, technical work finishing before the safety decision, and a unit built to an earlier configuration, which must return its as-built versions rather than the latest design. Earlier reports keep their source accounts, assessment paths and decisions, and quality and the relevant reviewers verify intake, access, escalation and assessment paths before the new version is used.

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

3Build traceability into the records.

A verification protocol in Seal is created against the requirement it tests, so the trace is a relationship between records rather than a cell in a matrix. The protocol identifies the requirement it verifies, and the requirement lists the protocols that verify it.

Test results attach to the protocol execution with their data and outcome. A summary belongs to the configuration that was tested, and it does not always settle verification: a mean alarm response of 24 seconds does not show that every response met a 30-second limit, and a median battery life of 9.2 hours does not show that every unit reached 8. The individual results, test conditions and acceptance criteria stay one step away. Design outputs work the same way: a drawing or specification is linked to the requirements it implements, and its version history keeps the link.

Open requirement 47 and its rationale, source (user need, standard or risk control) and the design reviews that evaluated it are on the same record. Follow it forward to the design output specifying the pump mechanism, the bench protocol and the results with their data. Follow it to risk to see that it controls HAZ-023, incorrect dosing and what residual risk remains, and to the general safety and performance requirement it supports.

When a design changes after certification, the same links show which verification may need repeating, which risk controls are affected and whether the technical documentation needs updating. An impeller revision brings REQ-047, its protocol and the affected device configurations into the change assessment; a sensor or software change identifies the timing study, alongside other requirements that use the same sensing path. The design-change assessment starts from those relationships; the team decides what the change requires.

4Carry the design into manufacturing and the field.

Design traceability is worth most when it reaches the device that was built. Each lot or serialised device should identify the versions and actual inputs used in its manufacture.

Model the product definition, approved configuration, component specifications, supplier parts, manufacturing route, tests and released units. A component specification links to the design output and requirements it implements, and to the received supplier lots, their acceptance evidence and the units that consumed them. A test method links to the requirement or risk control it verifies, and each execution to its method version, equipment, data and reviewed outcome.

Configure the manufacturing traveller around the work: material acceptance, component identity, equipment readiness, assembly steps, measurements, inspection and review. Required checks can act at the point of use. The execution retains actual values and exceptions so a reviewer can distinguish completed work from an approved disposition. The traveller runs as an electronic batch record, drawing components from inventory.

Paradromics runs the manufacturing travellers and quality records for its brain-computer interface in Seal. Operators there had spent 30 to 60 minutes per process on paperwork, and senior engineers three to four hours a day reviewing paper travellers. Operator paperwork time fell by over 80% and engineers’ traveller review time by 90%: they now review the exceptions the system surfaces.

A design change may affect only some configurations, component revisions or software versions. Represent that applicability explicitly. When the team assesses a field issue, it can follow the serial or lot through the as-built configuration, component lots, manufacturing results and relevant design decisions. A current drawing alone cannot explain a unit made under an earlier revision. A change assessment keeps its rationale, affected outputs and verification scope with the effective version, implementation evidence and the lots or serials it reaches.

5Follow supplier changes through the product.

A supplier approval, a component acceptance and a product release answer different questions. When they stay connected, a supplier change starts from the specifications and configurations it reaches.

Keep the approved supplier scope, quality agreement, specification, received lot and acceptance evidence connected. Record concessions or nonconformances against the material and the manufacturing work they affect.

When a supplier changes a material, manufacturing method or component revision, start the impact assessment from the affected specifications and product configurations. Identify design outputs, risk controls, manufacturing validations and incoming tests that may need review. Preserve the source notice, assessment, decisions and implementation evidence.

The same relationships support containment. The team can identify which stock, work in progress, finished units and distributions used the affected lot, then record the authorised disposition and follow-up. Source data may remain in an ERP or manufacturing system; retain its identifiers and the time of the extract or connection so the scope can be reconciled.

6Manage software and configuration as part of the device.

A software release is part of the device configuration, and a test result belongs to the build and environment it evaluated, not just to the name of the test.

For a device with software, connect each release to its requirements, architecture or design outputs, interfaces, verification, unresolved anomalies and risk assessment. Record which hardware and accessory configurations are covered, and which released version is installed on each.

When an interface, dependency or cybersecurity finding changes the assessment, follow the affected configuration and requirements into verification and the release package. Engineering and quality decide the necessary work and acceptance criteria. Neil can assemble the linked records and identify missing evidence for that review.

Keep released evidence identifiable even as development continues. A later passing test does not silently replace a failed result for an earlier build. Reusable verification procedures can improve across products, while each execution retains the configuration, inputs and evidence specific to the device tested.

7Keep risk management current with the device.

Risk analysis is often a file approved during development and updated only when required. Seal holds it as connected records, so what the field reveals reaches the analysis that the next design review uses.

ISO 14971 describes a risk management process: identify hazards, analyse hazardous situations, estimate risk, implement controls and evaluate residual risk. The hazards identified during development were the best estimate before anyone used the device, and field experience can reveal use errors, failure modes and conditions that were not anticipated.

Each hazard in Seal links to its hazardous situations and potential harms, with probability and severity. Risk controls link to the hazards they address and to the verification of their effectiveness. When a complaint suggests a new hazard, the team adds it and reviews what it touches: the requirements that address it, the controls that might mitigate it and where in the design it arises. A design review then uses the current risk picture rather than a copy.

The benefit-risk determination required under EU MDR is maintained the same way. Clinical benefits are documented with evidence, risks are characterised from the current analysis, and when new clinical data or adverse events require an update, the team updates those sources and revises the determination from them.

8Render technical documentation from the records.

Seal renders technical documentation from the current records, and a submitted package keeps the exact versions it used while the next one is prepared.

Assembling technical documentation often means pulling documents from shared drives, working out which version is current and discovering inconsistencies, such as a clinical evaluation that references an older risk analysis. Development continues while the file is assembled, so the submitted version can already be behind the device.

Seal renders the EU MDR Annex II sections from the underlying records: the device description from the master record, design information from the design history file, GSPR conformity from the mapping between requirements and regulations, risk analysis from the current risk records and clinical evaluation from the CER with its linked literature and post-market data. An FDA 510(k) needs a different structure over the same device description, risk analysis and clinical evidence, so one source serves several submissions without parallel copies.

Neil can assemble the revised source set and draft the affected sections. Qualified people review the evidence and remain responsible for approving what is submitted; the earlier submission retains its original sources.

9Detect post-market signals across every source.

A field report can lead to a design change, a manufacturing improvement or a new risk control. Seal connects the report to the device and the work it creates, and brings every surveillance source into one record.

Post-market surveillance under EU MDR is active: the manufacturer gathers and analyses data to identify problems, describes how in the PMS plan and reports the results in the PSUR (or the PMS report for Class I devices).⁴ The data arrives from many places: complaints through customer service, vigilance reports through regulatory affairs, literature through medical affairs, registry data through clinical teams and PMCF results through R&D. Finding patterns across them depends on manual aggregation that happens infrequently.

In Seal, complaints are entered as structured data (product identifier, event, patient outcome and investigation findings), so trends are queryable without reading every complaint. Under the QMSR, a complaint that is investigated or reported records the device name, the date received, its UDI or other identification, the complainant’s details, the nature of the complaint, any correction and the reply.⁵ Statistical methods can run as the data accumulates: when alarm-related complaints exceed their historical baseline, for example, the trend is surfaced for review rather than noticed in a quarterly report.

When a signal is confirmed, the response starts from connected records: the complaint trend, the affected products with lot numbers and distribution records, and the risk analysis that needs updating. FSCA documentation can be prepared from that information. The team assesses the signal and decides the action.

10Build a reusable product platform with AI.

A new product can start from what your team has already established, provided each reuse is an assessed decision rather than a copied document.

Device families often share assemblies, software components, test methods and manufacturing operations. Represent those common elements in a controlled library, with the configurations and intended uses to which they apply, and record each new product’s own requirements and differences.

Reuse needs an applicability decision. A verification method may be reusable even when an earlier result is not evidence for the new device. A risk control may need different effectiveness evidence for a changed population, environment or use scenario. Record that reasoning so a copied document does not become an unexamined claim of coverage.

Neil can help build and revise the operating workflows around these records. Ask it to prepare a design-change assessment, configure a review path that checks requirement coverage, or assemble manufacturing evidence for a specified configuration. The team can turn repeated review findings into better checks and reusable work methods.

Persistent memory gives the agent context from previous work and decisions; versioned skills provide a repeatable method. A design-review skill might require the intended use, affected requirements, configuration, risk assessment and verification scope before it prepares the package. Review and refine that method using known cases, including missing evidence and changed applicability.

Keep customer designs, supplier intellectual property, restricted test data and identifiable complaint information within their authorised scope. A shared skill can encode the method for checking trace coverage without carrying another customer’s requirement text or results. Memories, attachments and examples need the same review for permitted reuse as a document prepared by a person.

11Keep the quality system capable of change.

A useful quality system should become better as the organisation learns, and each improvement is an assessed change to the workflows people run.

A recurring nonconformance may justify a new inspection step; a design review may reveal that interface requirements need a different structure; a field investigation may identify a missing follow-up state. Configure those improvements in Seal rather than in a separate document.

For each revision, identify its intended use, affected records, access rules, calculations, integrations and outputs. Verify the normal path and meaningful exceptions, then record review, approval and effective use. Earlier executions retain the instructions and evidence under which the work was performed.

Map the configured quality system to the QMSR, ISO 13485 and other requirements that apply to your device and operation; the presence of a workflow does not itself demonstrate conformity.⁶

12Evaluate the complete chain on a real change.

Choose a device and a proposed change with consequences beyond one document, and follow it from the requirement through verification, manufacturing and the affected units.

Import the affected requirements and configuration, link the available design and verification evidence, and follow the change into manufacturing and post-market records. Give engineering, quality and operations the access needed to review their part of the decision.

Exercise missing verification, an obsolete test version, a restricted supplier record, an affected serial range and an unresolved anomaly. Check that the reviewer can locate the source, distinguish planned work from completed evidence and identify who must decide. Assess how much effort is required to configure the next product or change using the same foundation.