quality_nonconformance v1.0.0

name: quality_nonconformance description: "Run manufacturing nonconformance management end to end: write NC reports that meet ISO 9001 8.7, drive root-cause analysis (5 Whys, fishbone, 8D), and track CAPA records through to verified effectiveness. Use when a part, lot, or process step fails spec, when a customer complaint needs an 8D response, when an NC needs disposition, or when a CAPA must survive an audit."

Quality Nonconformance

Purpose

Turn a detected nonconformance into a closed, audit-defensible record: identify and contain the suspect material, disposition it through the right authority, find the real root cause (occurrence and escape), fix it permanently, and prove the fix worked. Grounded in ISO 9001:2015 clause 8.7 (control of nonconforming outputs) and clause 10.2 (nonconformity and corrective action), plus FDA 21 CFR 820.90/820.100 where medical-device rules apply.

Workflow

1. Open the NCR. Record what failed, where it was found, the quantity, the requirement it violated (spec, drawing rev, acceptance criterion), and who detected it. Use bin/ncr_new.py or the blank template in assets/ncr-report-template.md. See field guidance in references/nc-report-template.md.
2. Contain first, investigate second. Physically or electronically segregate suspect material immediately (hold area, quarantine tag, system status flag) and verify the containment works. Scope the suspect population: which lots, dates, and shipments could carry the same defect.
3. Disposition through authority. Route to the Material Review Board or the named disposition authority. Pick from the standard codes: use-as-is (only with customer concession authorized), rework, repair, regrade, scrap, return to vendor. Rework and repair must be re-verified against the original requirement before release. Never disposition by informal agreement; record the decision and the deciding authority (ISO 9001 8.7.2 requires it).
4. Decide if it needs root cause. Single isolated NCs may close at disposition. Escalate to root-cause analysis when: the NC repeats, a customer reported it, it reached the field, safety or regulatory impact is possible, or the trend data crosses your escalation threshold (Pareto top defect codes, repeat lot families).
5. Find the root cause, twice. Use 5 Whys and an Ishikawa fishbone (6M: man, machine, material, method, measurement, milieu) to land the root cause of occurrence (why the defect was made) and separately the root cause of escape (why inspection did not catch it). A 5-Why chain that ends at "operator error" is not finished; keep going until you hit a system cause you can change. Is/Is-Not scoping keeps the problem description honest.
6. Choose one permanent corrective action per verified root cause. Actions must eliminate the cause, not restate the correction. Prefer error-proofing and system changes (fixtures, interlocks, automated checks, updated setpoints) over retraining alone.
7. Implement and verify effectiveness. Put the actions in with owners and due dates, then prove they worked with objective evidence over a defined monitoring window (e.g. 30 days or N lots with zero recurrence), not just proof of installation. Closing a CAPA on implementation is one of the most common audit findings; close it on demonstrated effectiveness.
8. Prevent recurrence. Update the documents the fix touches: PFMEA, control plan, work instructions, PM schedules, supplier requirements. Assess horizontal deployment: where else could the same cause produce the same defect.
9. Close with evidence. Run bin/capa_lint.py against the CAPA record before sign-off; fix every gap it flags. Closure sign-off comes from the approver, who must be a different person than the action owner.

Use the 8D format (D0-D8) when a customer demands a formal response or the problem is cross-functional. See the fully worked example in references/eight-d-worked-example.md.

Output Contract

• NCR: unique ID, part/lot/quantity, requirement violated, objective evidence of the defect, containment status, disposition decision with authority named, linkage to any CAPA. Never vague ("bad parts"); always measured.
• Root-cause record: problem statement with measured values, Is/Is-Not, 5-Why chain or fishbone, verified root cause of occurrence, verified root cause of escape, the data or test that verified each.
• CAPA record: one permanent corrective action per root cause with owner and due date, preventive action, implementation evidence, verification-of-effectiveness data and monitoring window, management-review note, approver sign-off distinct from the owner. Lint-clean per bin/capa_lint.py.
• Audit trace: an auditor can follow NCR ID -> CAPA ID -> affected product/batch -> implementation evidence -> effectiveness data without asking for help.

Operating Rules

• Correction (rework/repair/disposition of the bad parts) is not corrective action (eliminating the cause). Do not close a CAPA on correction alone.
• "Operator error" is a starting point, never a root cause. If the chain ends there, the analysis is incomplete.
• Containment is past tense before investigation proceeds: suspect material segregated, dates and scope documented, effectiveness checked.
• Reworked output gets re-verified against the original requirement before release. Always.
• Use-as-is requires documented customer concession/authorization. No concession, no use-as-is.
• One verified root cause gets one permanent corrective action. Two root causes, two actions.
• Verify effectiveness with data over a monitoring window. Implementation evidence alone does not close a CAPA.
• The approver and the action owner are different people.
• Keep the regulatory mapping light: cite ISO 9001 8.7 / 10.2 and 21 CFR 820.90 / 820.100 only where they add a requirement; do not turn the skill into a clause lecture.
• Templates and worked examples live in assets/ and references/; the skill stays in the room to run the job.