A senior engineer pinged me one Tuesday morning: "There's a 404 in the DHF." Not a web 404. A traceability 404 — a dead link between a design input and the test report that was supposed to prove it.
We are a contract manufacturer in Bangalore producing components for three global medtech OEMs. We inherit Design History Files from customers, add our process-specific verification, and run the design transfer. This particular DHF was eight years old, originally authored under 21 CFR 820.30(j), and had lived through at least two design transfers before ours.
What broke
The dead link sat in a Verification Traceability Matrix (VTM) — the spreadsheet that maps design inputs to outputs, to verification activities, to test reports, and back to risk controls. Someone, in some prior revision, had renamed a test protocol ID. The matrix referenced the old ID. Eight years of subsequent changes piled on top, and no one had ever re-walked the matrix to confirm every cell still resolved.
When our team tried to extend the VTM for a new supplier-driven change, a script that cross-checked IDs found a dangling reference. The protocol did not exist. The test report that was supposed to reference the protocol had a footnote saying "superseded by [new ID]" — but nothing in the DHF told you what that ID was, or where the new protocol had landed.
That is how we lost a sprint. Not to the change itself. To reconciling eight years of trace records by hand.
What the standard actually asks for
ISO 13485:2016, clause 4.2.5, says records shall remain readily retrievable and protected from loss. Clause 7.3.9 says design and development changes shall be reviewed, verified, and validated as appropriate, and the records of those changes kept. Clause 8.2.1 says feedback — including complaints and nonconforming product — has to feed back into the risk file.
None of those clauses say "your traceability shall be stored in a spreadsheet." But the implicit ask is that traceability must be live — you must be able to demonstrate the chain, not just point at a static document and hope.
The FDA's 21 CFR 820.30(j) asks for a DHF that contains, or references, the records necessary to demonstrate that the design was developed in accordance with the approved design plan. EU MDR Annex II asks for similar — the technical documentation has to allow the manufacturer to demonstrate conformity.
The common thread: traceability has to be demonstrable. A VTM frozen in 2017 and never re-walked does not satisfy that.
What we did to fix it
We did three things, in this order.
- Rewrote the affected VTM by hand. Two engineers, four working days. Painful, but unavoidable.
- Wrote a small Python script that walked every cell, looked up the referenced ID in our document repository, and flagged unresolved ones. Anything flagged got a comment in the VTM itself.
- Scheduled that script to run on every revision commit. A dead link now blocks the PR, the same way a broken unit test would.
The script is not clever. It does plain string matching against IDs, because our IDs follow a strict format. Semantic similarity is for a different problem — I wrote about that last year (see the 0.87 problem). Here, exact match is the right tool.
What I would do differently next time
If I were starting this DHF fresh, I would not author the VTM as a spreadsheet at all. I would author it as code — a small structured file (YAML, if you like), one record per trace link, validated on commit. Each link would carry a timestamp, a status, and the IDs it points to. The "matrix view" would be a rendered output, regenerated on every change.
Treating traceability as code means:
- Every change to a trace link is a diff you can review.
- A dead link is a CI failure, not a discovery during an audit.
- The DHF and the VTM cannot drift, because they are the same artifact.
That is what I mean by treating traceability as a living structure. A static matrix, however complete, decays. A structure that re-validates on every change catches the ripple instantly.
The change that exposed the dead reference did not cause the decay. Eight years of changes did, and we had no system to flag them in flight.
What we still have to reckon with
We have forty-plus suppliers of our own. Each one ships a CoA, a test report, a certificate of conformance. Each of those has to land somewhere in our traceability. The same decay problem applies to our supplier records.
We are not there yet. But the principle holds: if a link can break silently, it will. The only fix is to make breakage impossible to merge.
What does your team's traceability look like — a spreadsheet someone updates quarterly, or a structure that re-validates on every change? I would be curious to hear how others draw the line between "documented" and "demonstrable."
Top comments (0)