A TIL on qmsWrapper's version logic — and the supplier-side half it doesn't cover

A TIL that started with a bad morning

I lost forty minutes last quarter chasing a "current" drawing that turned out to be a superseded one. Someone had emailed me a Rev B over a year ago, my inbox had quietly become my document store, and an auditor wanted to know which revision the line was actually running. The answer was Rev C. The printed copy on the shop floor was Rev B. That gap is the kind of finding that becomes a CAPA, and that CAPA becomes an inspection finding if you don't close it cleanly.

So when I poked around qmsWrapper this morning and saw that the platform keeps the approved original untouched and pushes superseded revisions out of the daily view, my first reaction was: that is the version logic every QMS should already have. My second reaction was: I have to think about whether it works from where I sit.

What I actually saw in the daily view

In the Documents area, the default landing view is Current. Superseded revisions don't sit next to current ones in the same list. They live in a separate state — present, recoverable, audit-trailable — but not in the place you reach for on a Tuesday morning. The approved original is preserved as the original. New revisions supersede it cleanly. The line between revisions is explicit, not implied.

This is the boring kind of feature that matters most during a notified-body audit. ISO 13485 §4.2.4 expects you to prevent obsolete documents from unintended use. EU MDR Annex IX §3 expects the same kind of control over documentation supporting conformity assessment. 21 CFR Part 820.40 expects document control procedures that prevent unintended use of obsolete documents. The standard is not exotic. Most eQMS tools claim to satisfy it. The real question is whether the daily experience of the tool actually enforces it.

qmsWrapper's design, at least on the surface, does. The default view is "what is current," and the daily behaviour of the tool is consistent with that. That is not magic — it is process automation aligned with a regulatory expectation that already exists. Reviewability and traceability between revisions are preserved in the audit trail, which is the second thing an auditor will ask for.

Where my CMO context breaks the picture

Here is the part I have to be honest about. I run supplier quality at a contract manufacturer in Bangalore. My "approved documents" list is split into two halves. The first half is internal — work instructions, inspection procedures, gauge calibration records, our own DHF references. The second half is external — supplier specifications, supplier COAs, sub-tier process records.

qmsWrapper is built and marketed for device makers, not for the supplier-side of the relationship.

• For the internal half, qmsWrapper's version logic would work well. Approved originals stay approved, superseded revisions fall out of the daily view, and the audit trail keeps the reviewability auditors expect. If I were a 30-person device maker with a real QA/RA function and a CAPA queue that wouldn't shrink, I would want exactly this.
• For the external half — the supplier-controlled half — version logic on qmsWrapper's side does not solve my problem. My suppliers do not all live inside my QMS. Their version logic is their own, and my reconciliation against their COAs is still a Python + Postgres job I wrote two years ago, with a Grafana panel on top.

The connected workflow I want from a QMS tool would be one that brings supplier revisions into a controlled view without forcing my suppliers to adopt a new tool. That is a different category of problem from "version logic inside the device maker's own controlled-document set."

What I am taking back to the team

Three concrete things:

• Default to current, keep the original approved, push superseded out of daily view. This is what ISO 13485 §4.2.4 is asking for, even if the standard does not say it in those exact words. Boring, correct, defensible.
• The CMO gap is real. Version logic inside a device maker's QMS does not address supplier-side document control. That is a separate problem, and an honest read of qmsWrapper has to say so plainly.
• "Which revision is current?" is still the question I get asked most by inspectors. The tool that answers it without me clicking through history is the tool that survives a notified-body visit. Most tools claim to. Few enforce it in the daily view.

The question I am sitting with

For the QA and supplier-quality people here who run contract manufacturing or supplier-heavy device builds: how do you handle version control on the supplier side — do you trust the supplier's revision state, replicate their documents into your own QMS, or run a script in between the two?

I work on qmsWrapper and have given my honest read above of where it does not fit my CMO use case.