The change notification arrived with one line describing the change. "Update mating feature per DFMEA revision B." That sentence touched twenty-three verification reports across four part families, two of which were already in distribution.
I am writing from a contract manufacturer's bench. We manufacture components to our customers' drawings, and design changes arrive as revisions rather than fresh starts. The version our OEM customer issues is rarely the version we end up working with. We need to know, for every change, which drawings we hold, which inspection plans we have approved, which work instructions we have trained, and which verification records are now stale. That map cannot live in someone's head.
What "traceability" actually means in design control
The intent behind the design and development clauses in ISO 13485, and the equivalent expectations under MDR, is that an organisation can answer a small set of questions quickly and reliably:
- Which requirement does this design output satisfy?
- What verification demonstrated this output meets the requirement?
- What changes have been made to the requirement, and which outputs and verifications are now affected by that change?
The whole exercise is in service of those questions. A requirement traceability matrix is the conventional answer. I have seen them in Excel, in SharePoint lists, and in the heads of engineers who have worked on the same product for years. They work, until they don't.
Memory is not a control
The first time I watched an engineer trace a single design input through to its verification record, it took her fifteen minutes. She knew where to look because she had been involved in the original transfer. A year later, when a similar trace was needed for a different part, the same engineer took three days. Two of those days were spent finding the colleague who originally wrote the verification protocol, because he was the only person who remembered which test report ID mapped to which clause.
That second trace was the trace that mattered. It was needed for a customer audit, and the question being asked was exactly the one the standards are written around. The answer, when we eventually produced it, was correct. The journey was an audit finding waiting to happen.
What "connected" looks like in practice
A traceability matrix that lives as a single document is brittle. The relationships need to exist in the system, not on the page. When a change happens, the propagation looks like this:
- A requirement is updated. Every design output linked to that requirement is flagged for review.
- An output is updated. Every verification referencing that output is queued for re-assessment.
- A verification protocol is revised. The linked requirement becomes the starting point for re-review.
I have spent the last year wiring these links together with a small Python service over a Postgres database. The structure is simple: a requirements table, a design outputs table, a verifications table, and a changes table. Foreign keys hold the relationships. A single view shows the full chain for any requirement, and a change event fires alerts to the owners of every record in scope. No one's memory is on the critical path.
The slow part is not the database. The slow part is convincing people to enter the relationships as they work, rather than reconstructing them after the fact. A retroactive matrix is a forensic exercise. A forward-built matrix is a byproduct of doing the work.
What I would still do differently
The system does not replace review. It surfaces what needs to be reviewed. A change still needs a human to decide whether the linked verifications need to be repeated, whether the linked risk controls need re-evaluation, whether the linked work instructions need re-training. The map points; it does not decide. That distinction matters, because reviewers are the control, and the system provides reviewability.
I would also start earlier. The cost of wiring relationships after a design has been transferred is real, and it scales with the number of linkages. The cost of wiring them during transfer is part of the transfer. We have a habit now of treating traceability links as a transfer deliverable, not a transfer follow-up.
The thing I would change most: I would make the change-impact view visible to the people who actually receive the change, not just to QA. When an OEM customer sends us a revision, the production engineer, the supplier quality engineer, and the inspection planner all need to see the same scope. Putting it on a shared screen saved more time than any report I have written this year.
A question I keep returning to
When you receive a design change, how long does it take you to answer, with proof rather than memory, the question of which verification records are now affected?
Top comments (1)
"Memory is not a control" is the line. The same thing happens with API changes in software teams: the person who remembers the consumers moves on, and every change after that turns into archaeology. Forward-built vs retroactive is a good way to put it.