For the quality manager
Your problem is not recording that something went wrong. It is that when the same failure recurs fourteen months later, nobody can find the first investigation — because it closed against a free-text description rather than a part number and a revision.
What you are actually deciding
Whether the quality system is connected to the product data or beside it. Almost every tool in this category records issues competently; the difference is whether an issue attaches to the part at the revision that failed, or to a text field describing it.
That single distinction determines whether a recurrence costs a day or repeats the entire original investigation. It also determines whether an auditor asking “show me the corrective action for this finding” gets an answer or a search.
The second decision is whether closure means anything. In most systems a CAPA closes when somebody marks it closed.
Closure requires evidence, and that is enforced
The loop is six stages — raise, contain, root cause, correct, verify, close — and the fifth is where most systems become optional. Here it is not.
A CAPA cannot close without verification evidence: an attached result, an inspection record, a batch that passed, a test report at a revision. Not a checkbox recording that somebody verified it. If verification shows the action was ineffective, the issue reopens at root cause rather than closing with an explanatory note.
That constraint is most of the value on this page. An unverified CAPA gets raised again next year by somebody who does not know it already was, and the second investigation reaches the same conclusion at the same cost — except now you have paid twice and have two closed records that disagree about whether the problem is solved.
Root cause tooling is 5-Why, fishbone and 8D, as templates over one object rather than three separate modules. Using 8D for customer issues and 5-Why internally does not mean running two systems.
Issues attach to the product, not to a description
Every issue links to the part at the revision that failed, the supplier and manufacturer part involved, the process step, the requirement violated, and any change that caused or fixes it.
So when the same part fails the same way fourteen months later, the new NCR surfaces the old one immediately — including whether its corrective action was ever verified as effective. In the common case it was not, and knowing that in the first hour rather than the fourth week changes what you do.
It also works in the other direction. From a part you can see its quality history; from a supplier you can see theirs against the approved manufacturer list engineering maintains; from a product you can see everything in its resolved structure. None of that requires anybody to have tagged anything consistently.
FMEA — design and process — links to the parts, process steps and requirements it analyses rather than living in a spreadsheet, so a high-severity failure mode is visible from the part it concerns rather than only from the FMEA itself.
What an auditor will actually be shown
The audit trail is hash-chained: each row commits to its predecessor, so a tampered or deleted entry breaks verification and the break is locatable. Writes arriving without an attributed actor are refused rather than recorded as unknown.
Administrators have no silent bypass. An administrator who needs access to a restricted programme grants it to themselves and leaves a row saying so — which is the difference between an access control story that survives an audit and one that ends with somebody saying nobody can tell.
Because a released revision cannot be edited, the record of what was specified at any point in the past is intact by construction rather than by policy. “What did unit 1420 ship with” resolves to a structure with every line at its revision, and that answer is reproducible.
Every AI action is audited too, naming the agent, the permission tier it ran at, the tools it called and the object revisions it cited. There is no entry that says only that the AI did it.
How it meets your ERP
Disposition is recorded here and transacted there. Use-as-is, rework, scrap and return-to-vendor are decisions people make with stock in front of them; the NCR records what was decided, by whom, against which quantity, and your ERP performs the movement.
Affected inventory appears as context — on-hand, committed, open purchase orders, and lot or batch quantities where your ERP exposes them — so the disposition conversation happens with the numbers on screen rather than in a separate tab and a phone call.
Supplier records master in your ERP. The SCAR, the response and the quality history attach to Manufacturing PLM's supplier and manufacturer objects, so supplier performance is visible against the approved manufacturer list without Manufacturing PLM pretending to own the commercial relationship.
Where the boundary is
Inspection execution is not here. Recording that an operator measured a characteristic at a station on a specific unit is MES work. Manufacturing PLM holds the inspection plan, the characteristics, the acceptance criteria and the evidence attached to issues; measurements flow in rather than being captured here.
FDA design controls, a device history file and ISO 14971 risk management are out of scope, and this is the row most likely to disqualify us for you. The requirements and verification model was built general enough to carry that package later without re-modelling, but later is not now and choosing on that basis would be unwise.
Facts
| Loop | Raise → contain → root cause → correct → verify → close |
| Closure | Requires evidence — an attached result, not a checkbox |
| Ineffective action | Reopens at root cause; cannot close with a note |
| Issues link to | Part at revision · supplier · process step · requirement |
| Methods | 5-Why · fishbone · 8D, over one object |
| Audit trail | Hash-chained; unattributed writes refused |
| Administrators | No silent bypass — access is granted and logged |
| Not offered | Inspection execution · design controls · DHF · ISO 14971 |
Frequently asked
What stops a CAPA closing without being effective?
Verification evidence is required to close — an attached result, an inspection record, a batch that passed, a test report at a revision. If verification shows the action did not work, the issue reopens at root cause rather than closing with an explanatory note attached.
How does a recurrence find the original investigation?
Because issues attach to the part at the revision that failed rather than to a free-text description. A new NCR on the same part surfaces the old one immediately, including whether its corrective action was ever verified as effective — which is usually the interesting part.
Can a CAPA drive an engineering change?
Yes, and it raises a real ECO rather than describing one. The fix runs through change control with a computed impact set, approvals, effectivity and an atomic release, so the corrective action and the engineering change are one record rather than two that drift apart.
What will an auditor see?
A hash-chained audit trail where each row commits to its predecessor, so tampering breaks verification and the break is locatable. Unattributed writes are refused outright, administrators have no silent bypass, and released revisions cannot be edited — so past specifications stay intact.
Where does FMEA live?
Linked to the parts, process steps and requirements it analyses rather than in a spreadsheet. A high-severity failure mode is therefore visible from the part it concerns, not only from inside the FMEA document — which is what makes it usable during a change review.
Do you handle shop-floor inspection?
No. Manufacturing PLM holds the inspection plan, the characteristics and the acceptance criteria, and stores evidence against issues. Recording that an operator measured something at a station on a specific unit is MES work, and those measurements flow in rather than being captured here.
Is this enough for a medical device?
No, and this is the row most likely to disqualify us. Design controls, a device history file and ISO 14971 risk management are out of scope today. The model was built to carry that package later without re-modelling, but choosing a tool on a roadmap is how you migrate twice.