A CMO walks through qmsWrapper's traceability matrix setup — and flags where it stops fitting

I watched the qmsWrapper walkthrough on building a design-control traceability matrix with two notepads open — one for what I'd build if I were the device maker, and one for what I'd push back on as a CMO receiving the artefact. Both notepads got used.

Full disclosure up top: I work on qmsWrapper, and I'm writing this from a contract manufacturer's seat. Most of my days are spent on supplier quality — sub-tier audits, incoming inspection, COAs across 40+ suppliers. Design controls live upstream of us, in the OEM's QMS. But we see the output, and we live with the consequences when the traceability chain breaks between requirement, risk, and verification. I work on qmsWrapper and this is my honest read of where the tool fits and where it stops fitting.

Why this matters on the receiving end

A traceability matrix that links user needs → design inputs → design outputs → verification is the spine of an ISO 13485 §7.3 and 21 CFR 820.30 design history file. ISO 14971 risk management should sit on top of it — every hazardous situation traced back to the requirement it informs, forward to the verification that proves the residual risk is acceptable.

When we receive a DFM package from an OEM and the traceability matrix has gaps, here's what we see in practice:

• A design input listed as "biocompatible per ISO 10993" with no link to the actual verification report — just a memo that says "tested."
• A risk control measure documented but not traced to any verification activity that proves it works.
• A "TBD" in the verification column that's been TBD for three product cycles.

These are not exotic failures. They're the routine shape of a matrix that was built once and never updated. The walkthrough I watched is about avoiding exactly this — building the matrix so the links are live, not pasted in.

The three-link chain the video walks through

The walkthrough spends most of its time on the same three connections:

1. Design input (a user need or design requirement) — captured as a traceable item with an ID, owner, and review state.
2. Design output (the spec, drawing, or process that satisfies it) — linked back to the input it derives from.
3. Verification (the test, inspection, or analysis that proves the output meets the input) — linked forward from the output.

Risk sits across this chain. A control measure from the risk file should link to both the design output it informs and the verification that proves the residual risk is acceptable. The walkthrough demonstrates how qmsWrapper's matrix view handles that cross-link — clicking a risk control surfaces the linked verification, and vice versa.

The part I'd underline for anyone setting this up from scratch: the value is not the rows. It's the links between rows. A spreadsheet can show you a list of requirements. It cannot warn you when a verification has been deleted upstream and the input it used to prove is now orphaned. The qmsWrapper approach — and this is the genuine strength, not marketing — is that the links are queryable, not just visual. That's the difference between a traceability matrix you can defend at a notified-body audit and one that looks pretty until the third row.

Where it fits, and where I had to flag limits

For a device maker setting up design controls from scratch, this is a clean walkthrough. The matrix view, the risk-to-verification linking, and the design-change impact mapping all do what the video shows.

For CMO supplier-quality work, it stops fitting at the boundary of our QMS. We don't own design controls — we own the supplier-COA verification, incoming inspection, and the CAPA chain when something fails. qmsWrapper is built for the device-maker side, and the trace matrix features assume you have a design history file. We don't. What I'd want — and what isn't built for our case — is a parallel matrix that goes from purchased component → supplier requirement → incoming inspection result → CAPA. That's a different shape of artefact, and a tool built for OEM design controls will not naturally produce it. I work on qmsWrapper; this is the honest line where the tool does not fit my day-to-day.

Practical takeaways if you're setting this up

• Build the matrix from inputs first, not outputs. If you start with the spec, you'll rationalise backwards and invent risk links that don't survive a review.
• Make every verification a real record, not a memo. "Tested and passed" is not a verification. The protocol, the report, the acceptance criteria, the date — all linked.
• Treat the risk-to-verification link as load-bearing. If a notified-body auditor breaks that link, the design history file is not defensible.
• Set the review cadence before the matrix gets big. A traceability matrix you don't review is a spreadsheet with extra steps.
• If you're a CMO receiving these matrices, check the verification column before you sign the DFM. We've caught programmes where verification was incomplete and flagged it back to the OEM before tooling kicked off — much cheaper than catching it after first-article.

A question for anyone who's done this

For the people who've built one of these matrices from scratch — oru kelvi (one question): what was the first link you wished you'd wired up earlier, risk-to-verification or design-output-to-verification? Both have failed on me when the matrix was young, but I'd like to hear which one breaks first for other teams.