Nonconformity reports should be detailed enough that a competent person, unfamiliar with the event, can reconstruct what happened and why it matters using the record alone. In regulated and aerospace-grade environments, that usually means more detail than operators initially think, but still focused on objective, traceable facts rather than long narratives.
Minimum information every nonconformity report should contain
At a minimum, each nonconformity report should clearly capture:
- Identification and context
- Part number, description, and revision
- Lot/batch, serial number(s), or other unique identifiers
- Work order, operation/step, and line/cell/location
- Date/time detected and by whom
- Customer/program and any contract or drawing identifiers if relevant
- What is nonconforming
- Clear description of the defect or deviation (e.g., “diameter 25.12 mm, spec 25.00 ±0.05 mm”)
- Specific requirement violated (drawing note, spec clause, SOP, control plan item, etc.)
- Extent of condition: single unit, lot-wide, systemic pattern, or unknown
- Evidence: measurement values, photos, test results, inspection reports
- Detection details
- Stage of detection (in-process, final inspection, receiving, MRO teardown, customer return)
- Method used (visual, gauge, functional test, documentation review, etc.)
- Relevant instruments or systems (gage ID, test stand ID, inspection system, MES transaction)
- Immediate containment and status
- Quarantine location, status (hold, rework, scrap, return to supplier, etc.)
- Boundary of containment (e.g., “all parts from WO 12345 and supplier lot ABC”)
- Who authorized the action (name/role, MRB or quality approver)
- Risk and impact indicators
- Potential impact on fit, form, function, safety, or regulatory performance, if known
- Whether suspect parts may already be in downstream operations, the field, or with customers
- Reference to related events (linked NCR/CAPA, recurring defect code, similar supplier issues)
- Traceability and references
- Linked CAPA, 8D, or root cause analysis if initiated
- Relevant process documents (work instructions, router, control plan, FAI/AS9102 report)
- System identifiers (MES/ERP/QMS record numbers) for cross-reference
How much narrative detail is enough?
Most plants struggle with either extremely brief or overly narrative reports. A practical target is:
- 1–3 short paragraphs of narrative to explain circumstances, not to restate data fields.
- Focus on facts: what was observed, under what conditions, by which method.
- Avoid subjective language (“operator made a mistake”) unless supported by later root cause analysis.
- Keep cause and correction separate: the NCR describes the nonconformity and immediate containment; deeper causes belong in a linked CAPA/8D, unless your QMS prescribes full root cause inside the same record.
A good test: if an auditor, new quality engineer, or customer representative can understand the event, verify the requirement, and trace the affected product scope without asking for hallway explanations, the report is detailed enough.
Adjusting detail based on risk and regulatory context
Detail should scale with risk and compliance exposure:
- Low-risk, internal-only issues (e.g., cosmetic defects on non-critical internal components) can be handled with more templated fields and fewer narrative details, as long as traceability is maintained.
- Safety, airworthiness, or mission-critical parts require more thorough documentation, especially around impact assessment, traceability, and links to MRB and engineering dispositions.
- Customer- or authority-reportable events (e.g., escapes, repeated supplier issues) generally demand a level of detail that supports external review and possible regulatory scrutiny.
Your QMS, customer contracts, and regulatory approvals ultimately define the minimum requirements. Nonconformity forms and workflows should be aligned to those, validated, and controlled under change management.
Digital vs paper: what changes and what does not
Whether you use paper forms, a QMS, or an MES/ERP-integrated NCR module, the required level of detail does not change, but how you capture it can:
- Digital NCRs can pre-fill part, order, and revision data from ERP/MES, reducing manual errors and freeing narrative fields for context rather than identifiers.
- Dropdown defect codes improve consistency but should be supported by a free-text field for nuanced cases.
- Links to genealogy/traceability data (heat lots, serial numbers, inspection records) can reduce narrative while actually increasing detail and auditability.
- Brownfield coexistence: if some nonconformities originate in legacy systems or at suppliers, your central record must still capture enough information to bridge those systems and support traceability. Do not assume another system will always be available later to “fill the gaps.”
In long-lifecycle, highly regulated environments, trying to replace all legacy NCR tools at once often fails due to validation overhead and downtime risk. Many organizations instead standardize the data content and traceability requirements first, then gradually converge systems while ensuring that any combination of old and new tools still produces complete, reconstructable nonconformity records.
Common failure modes and how to avoid them
- Too vague: “Part out of spec” with no spec reference, no measured value, no indication of scope. Remedy: enforce required fields for requirement reference and measurement or clear descriptive evidence.
- Too dependent on tribal knowledge: “Same issue as last week” or “bad finish at drill op,” assuming the reader knows the context. Remedy: require explicit operation numbers, machine IDs, and defect descriptions.
- Mixing disposition with description: Writing “scrapped for cost reasons” instead of describing what was actually wrong. Remedy: separate fields for defect description, risk/impact, and final disposition.
- Inconsistent coding: Similar defects coded differently by each inspector, making analytics unreliable. Remedy: maintain a controlled defect code list with examples, and use free-text detail only to supplement, not replace, codes.
- Unverifiable claims: Statements that cannot be supported by evidence (e.g., “defect is harmless” without engineering input). Remedy: limit the NCR to observed facts and traceable assessments with responsible signoffs.
Practical guideline
As a rule of thumb: if someone can, years later, answer “what failed, against what requirement, where else it might exist, and what we did about it” using the nonconformity report and linked records alone, the level of detail is appropriate. If any of those answers require finding the original operator or engineer to explain what they meant, the report is not detailed enough.
