The requirement nobody verified.

510(k) cleared in 90 days. Six months later, a nurse called: the device was too hard to activate. Her patient's hand strength couldn't generate the required force.

The design input was there: "Activation force shall not exceed 2N." But somewhere between requirements and launch, nobody built a test for it. The traceability matrix showed Input → Output → Verification for every other requirement. This one had a gap.

FDA noticed. "How did you verify this requirement was met?" Silence. Class I recall followed.

Traceability that exposes gaps before auditors do

Most companies treat design controls as a documentation exercise—static Word documents that describe what should happen. Seal makes design controls a living system where gaps become visible the moment they're created, not when an auditor finds them.

The lifecycle

Design planning → Design inputs → Design outputs → Design reviews → Verification → Validation → Design transfer → Design changes.

Inputs are the foundation—everything else traces back to them. If an input doesn't have a corresponding output, something is missing. If an output doesn't have verification, something is missing.

Verification vs validation

Verification: do outputs meet inputs? The device specifications say X; does the device do X?

Validation: does the device meet user needs? You can meet all specifications and still fail validation if your specifications were incomplete.

Design History File

The DHF is the complete record. In most companies, assembled manually before an audit—pulling documents from various locations, hoping nothing is missing.

In Seal, the DHF compiles automatically. When you add a design input, it's in the DHF. When you execute a verification protocol, results are in the DHF. Always current. Always complete.