Quality, closed properly
Most quality systems record that something went wrong and that somebody dealt with it. The two questions that matter afterwards — was the fix effective, and does the issue connect to the actual part revision involved — are usually answered by a text field.
What it is, and what it is not
A set of issue types — nonconformance, complaint, corrective and preventive action, supplier corrective action request, deviation, audit finding, inspection result — running through one closed-loop process with a shared lifecycle.
It is not a ticket system with quality-sounding field names. The difference is that every issue attaches to real objects: the part at the revision that failed, the supplier and the manufacturer part, the process step, the requirement it violated, the change that caused it or the change that fixes it.
It is also not a document repository for quality records. Records are a by-product of the process running, not the thing being managed. A quality module whose main artefact is a PDF has automated the filing rather than the work.
The mechanism: closure requires evidence
The loop is six stages: an issue is raised, contained, root-caused, corrected, verified, and closed. The stage that carries the weight is the fifth, because it is the one most systems make optional.
A CAPA cannot close without verification evidence. Not a checkbox saying somebody verified it — an attached result, an inspection record, a batch that passed, a test report at a revision. If verification shows the action was not effective, the issue reopens at root cause rather than closing with a note.
That single constraint is most of the value. A CAPA that closes without effectiveness evidence will be raised again next year by somebody who does not know it already was, and the second investigation will reach the same conclusion at the same cost.
Root cause tooling is 5-Why, fishbone and 8D — structured, but structured is not the same as prescriptive. The methods are templates over the same object, so an organisation using 8D for customer issues and 5-Why internally is not running two systems.
The failure it prevents
A batch fails inspection. An NCR is raised, the batch is quarantined, somebody identifies a supplier process drift, a SCAR goes out, the supplier responds, the NCR closes. Sixteen weeks, and it worked.
Fourteen months later a different batch of the same part fails the same way. The new investigation starts from nothing, because the previous NCR was closed against a free-text part description rather than a part number and revision, and searching for the description returns forty unrelated records.
The whole cost of the first investigation is paid again. Linking issues to the part at its revision, the manufacturer part, and the supplier means the second occurrence surfaces the first immediately — including whether the corrective action was ever verified as effective, which in this case it was not.
How it meets the rest of the product
Issues connect into the same relationship graph everything else uses. A nonconformance on a part is visible from that part, from the products containing it through resolved structures, from the supplier, and from any open change touching it.
A CAPA that requires a design change raises an ECO rather than describing one, so the fix goes through change control with an impact set, approvals, effectivity and an atomic release. A CAPA whose action is a supplier process change raises a SCAR that the supplier answers through the portal, at the specific documents and revisions you shared.
FMEA — design and process — links to the parts, process steps and requirements it analyses rather than sitting in a spreadsheet, so a high-severity failure mode is visible from the part it concerns. Control plans and inspection characteristics attach the same way.
The Quality Agent works this surface at whatever tier you set: clustering recurring nonconformances that were described differently, drafting an 8D from the evidence attached, and flagging CAPAs approaching a verification date. Every claim cites the issues and revisions behind it.
How it meets your ERP
Disposition is where quality meets inventory, and Manufacturing PLM deliberately stops at the edge. 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 the transaction happens in your ERP.
Affected inventory is shown as context — on-hand, committed, open purchase orders and lot or batch quantities where the ERP exposes them — so a disposition conversation happens with the numbers visible rather than in a separate tab.
Supplier records master in your ERP; the SCAR and the quality history attach to Manufacturing PLM's supplier and manufacturer objects. That means supplier performance is visible against the approved manufacturer list engineering maintains, without Manufacturing PLM pretending to own the commercial relationship.
Where the boundary is
Inspection execution is not here. Recording that a characteristic was measured at a station, by an operator, on a specific unit, is MES work. Manufacturing PLM holds the inspection plan, the characteristics, the acceptance criteria and the evidence attached to an issue; the measuring happens elsewhere and flows in.
Calibration and gage management are modelled, including out-of-tolerance retro-flagging so a gage found out of calibration raises the measurements it took since it was last verified. What Manufacturing PLM does not do is schedule the calibration or drive the equipment.
Medical design controls, a device history file and ISO 14971 risk management are not part of this. The requirements and verification model was built so a design-controls package could be added later without re-modelling, but later is not now.
Facts
| Issue types | NCR · complaint · CAPA · SCAR · deviation · audit · inspection |
| Loop | Raise → contain → root cause → correct → verify → close |
| Closure | Requires verification evidence — not a checkbox |
| Ineffective action | Reopens at root cause; it does not close with a note |
| Linked to | Part at revision, supplier, process step, requirement |
| Methods | 5-Why · fishbone · 8D, as templates over one object |
| Disposition | Recorded here, transacted in your ERP |
| Not offered | Inspection execution · design controls · DHF · ISO 14971 |
Frequently asked
What stops a CAPA closing prematurely?
Verification evidence is required — an attached result, an inspection record, a batch that passed, a test report at a revision. Not a checkbox. If verification shows the action was ineffective, the issue reopens at root cause rather than closing with an explanatory note.
How does an issue connect to the product?
Through the part at the revision that failed, plus the supplier, the manufacturer part, the process step and any requirement violated. That is what makes a recurrence surface the original investigation instead of starting from nothing against a free-text description.
Can a CAPA drive a design change?
Yes, and it raises an actual ECO rather than describing one. The fix then runs through change control with a computed impact set, approvals, effectivity and an atomic release — so the corrective action and the engineering change are the same record rather than two.
How do suppliers respond to a SCAR?
Through the supplier portal, against the specific documents and revisions you shared. Their session cannot reach anything else in the tenant — enforced as a data-layer predicate rather than a page check, with a test that attempts the direct fetch and asserts it fails.
Do you handle inspection on the shop floor?
No. Manufacturing PLM holds the inspection plan, the characteristics and the acceptance criteria, and stores evidence attached to issues. Recording that an operator measured a characteristic at a station on a specific unit is MES work, and that data flows in rather than being captured here.
What about calibration and gages?
Both are modelled, including out-of-tolerance retro-flagging — a gage found out of calibration raises every measurement it took since it was last verified, which is the expensive part that nobody does reliably by hand. Scheduling the calibration and driving the equipment happen elsewhere.
Is this enough for FDA design controls?
No, and it is not close. Design controls, a device history file and ISO 14971 risk management are out of scope today. The requirements and verification model was deliberately built general enough to carry that package later, but choosing a tool on that basis would be unwise.