Half a day of chasing an incomplete audit trail taught me the difference between "we fixed it" and "we can defend why we fixed it." Early signals — the little alarms that precede a formal nonconformance — matter because they are the raw material of a defensible narrative. If you only save the final corrective action and the changed document, an auditor (or a notified body) will ask: why did you escalate, who decided, and on what evidence?
Early signals matter — and they are fragile
At our CMO, incoming inspection is noisy: COA mismatches, one-off dimensional hits, intermittent particle counts. I automated the first pass of incoming inspection and supplier-COA verification (Python + Postgres + Grafana), and that automation gave us two useful things:
- consistent, timestamped measurements (data),
- a machine-readable event stream that could raise automated flags (signals).
But automation alone didn’t solve the deeper problem. We still lost the "why" in handoffs. The inspection machine said "out of spec" at 09:12; a line engineer quarantined the lot at 09:40; QA opened a CAPA two days later. Between 09:12 and when the CAPA was authored, decisions were taken orally, workarounds applied, and a supplier email was sent. If you cannot reconstruct that chain, the CAPA looks like an afterthought — not a reasoned response.
What makes a narrative defensible
Regulators care about traceability, reviewability, and reasoned decisions. ISO 13485 and 21 CFR 820 expect you to show you evaluated risks, recorded decisions, and verified effectiveness. For MDR audits, a technical file with post-market actions needs context, not just outcomes.
A defensible narrative captures:
- event source and raw data snapshot (sensor reading, COA PDF, inspector notes)
- timestamped decision points (quarantine, retest, supplier hold)
- who made each decision and their role/responsibility
- why the decision was made (risk assessment summary, thresholds crossed)
- alternatives considered and why they were rejected
- immediate containment actions and evidence
- escalation chain and notification logs (emails, system alerts)
- decision to trigger or not trigger CAPA (CAPA is a decision, not a default start)
- review and approval signatures with timestamps
If any of those are missing, you can still respond to an auditor — but it will be longer, more manual, and more stressful.
How I built the "why" into our flows
We added a thin decision layer to our existing automation rather than replacing people:
- when the automated inspection flagged an event, the system created a QMS event with the raw payload attached (COA PDF, measurement snapshot).
- the inspector received a short, required form: "What immediate action?" with options (quarantine, rework, release pending supplier confirmation). This is controlled assistance — short, reviewable choices, not AI dictation.
- a lightweight risk checkbox required a one-line rationale if the risk score crossed a threshold ("Why escalate to QA?").
- every manual override required an approver and a comment.
This bought two things: consistent early context, and a short, auditable reasoning trail that flowed into our CAPA decision. When QA opened a CAPA later, its "trigger" section pulled the event id and attached the original decision rationale automatically. CAPA owners didn't have to reconstruct events from emails.
Don't outsource the "why" to AI — make it assistive
There is a lot of talk about AI-driven CAPA assistance. Useful, but be cautious:
- Use AI for summarising long threads or suggesting potential root causes, but require humans to sign off and record the rationale.
- Keep AI outputs as "controlled assistance" — traceable, reviewable, and versioned.
- Never replace the decision signature. Regulators want to see who made the judgement, not who suggested it.
We experimented with automated root-cause suggestions in a beta feature. It saved time, but it also produced confident-sounding options that required explicit human acceptance and comment. That preserved reviewability.
Tooling needs for supplier-heavy CMOs
If you're a supplier-heavy shop like mine (40+ suppliers), the system must link supplier records, COAs, incoming inspection, change events, and CAPA. Many eQMS products are built with device makers in mind; they assume the device team owns most inputs. For a CMO you need flows that:
- attach supplier COA snapshots to events,
- allow quick supplier notification templates,
- autosync inspection trends across batches,
- keep a tidy decision log (who, why, when).
Connected workflow is the point: one place where change, CAPA, risk, and supplier correspondence actually connect.
Takeaways — practical minimums to capture today
If you only start with three items, make them:
- raw evidence snapshot (attached file or data row) with timestamp,
- timestamped decision and a one-line rationale,
- decision owner and approver with role.
Those three let you reconstruct a defensible story without rewriting history.
I’m sceptical of marketing language that treats CAPA as the product — CAPA is a decision triggered by context. Capture the context early and make the decision transparent.
I work on qmsWrapper and am giving my honest read of where it does not fit CMO supplier-heavy workflows.
How are you capturing the "why" in your organisation — spreadsheet emails, or something auditable and connected?
Top comments (0)