The hazard nobody thought of.

Surgical device launches after three years of development. Risk analysis covered electrical safety, biocompatibility, mechanical failure, use errors. 510(k) cleared. Eight months later, first adverse event: infection at the surgical site. The device's surface texture. Chosen for grip. Creates micro-crevices that harbor bacteria during reprocessing. The sterilization cycle validated for smooth surfaces doesn't reliably sterilize this texture.

This hazard wasn't in the risk file. Nobody asked: "What happens to this surface during reprocessing?" The intersection of two design decisions. Surface texture and sterilization method. Created a hazard that neither team considered because it lived at the boundary between their domains.

The risk analysis you filed with your submission reflects what you knew at the time. It was thorough. Your team spent months on it. The problem is that it's frozen. A document that captured your assumptions on the day you signed it.

Since then, complaints have arrived about issues that weren't in the file. Post-market surveillance has revealed hazards at frequencies different from your estimates. Your design has been modified through multiple change orders. But the risk file sits in a document management system, disconnected from all of it.

Most organizations update the risk file periodically. Maybe annually, maybe during design changes. In between updates, the file and reality diverge. A complaint about an unanticipated hazard gets investigated by the post-market team. The risk management team doesn't see it unless someone remembers to forward it. By the time the annual review happens, the connection between the complaint and the risk analysis has gone cold.

Seal connects the risk file to the systems that generate post-market data. When a complaint maps to an existing hazard, the occurrence data updates automatically. When a complaint describes a hazard that isn't in the file, the system flags the gap. When occurrence rates exceed your pre-market estimates, you see it in real time. Not during a review meeting six months later.

The risk file stops being a document you update and becomes a living model that evolves with your product.

"What's the probability of this hazard occurring?" Three engineers in a room give three different answers. Without defined criteria. What exactly does "remote" mean for this device, with this patient population, in this use environment? the risk matrix is an opinion laundering machine. You get a number that feels rigorous but reflects whoever argued loudest.

This is the core problem with spreadsheet-based risk management. The tool doesn't enforce consistency. Two teams evaluating the same hazard can reach different conclusions because their probability definitions are vague. Severity scales that say "serious injury" without defining the threshold invite interpretation. The matrix produces a green cell, everyone moves on, and nobody questions the assumptions.

Seal defines probability and severity criteria per product type. When an analyst selects P3, they see the specific definition and must cite the basis. Clinical data, complaint history, literature, or engineering analysis. The same hazard evaluated by different teams reaches the same conclusion because the criteria constrain the answer, not the analyst's judgment.

This matters during audits and submissions. When a notified body or FDA reviewer asks "how did you determine this probability?", the answer is a documented rationale tied to defined criteria. Not "the team discussed it and agreed."

The device overheats during extended use. Engineering's proposed control: a warning label. "Do not use for more than 30 minutes continuously." Users will ignore it. They'll use it for 45 minutes because they're almost done. The label absolves the company on paper while the patient gets burned.

ISO 14971 is explicit about control hierarchy: inherent safety first, then protective measures, then information for safety. If you can design out the overheating. Automatic shutoff at a safe threshold. A warning label isn't an acceptable primary control. It's what you add after you've exhausted design and protective options.

Seal enforces this hierarchy structurally. When an analyst proposes a warning label as a control, the system asks: was a design control considered? If yes, why was it rejected? The rationale is documented. If no design control was considered, the analyst must explain why. And that explanation is visible to reviewers.

This doesn't prevent teams from using warning labels when appropriate. It prevents them from defaulting to the easiest control without considering alternatives. The risk file shows not just what controls you chose, but what you considered and rejected. When a regulator asks "why didn't you design this out?", the answer is already documented.

Risk management in isolation is an academic exercise. It becomes powerful when it connects to the systems that generate evidence about whether your risk estimates were right.

In Seal, the risk file connects to complaints, CAPAs, design controls, and post-market surveillance. Because they're all on the same platform. A complaint about a new hazard triggers a risk file update. A CAPA that modifies a risk control triggers re-evaluation of the affected risk. A design change triggers impact assessment against the risk analysis.

These connections aren't manual forwarding between departments. They're structural links in the platform. The design engineer who changes a component sees the hazards associated with it. The quality engineer reviewing a complaint sees the pre-market risk estimate for that hazard. The regulatory team preparing a periodic safety update has current occurrence data, not data they assembled from five different sources.

This is what a living risk file actually means. Not a document that someone updates periodically, but a model that reflects current knowledge because it's connected to the systems generating that knowledge.