Connect981 – Content Dev

RSC Cluster: Nonconformance, MRB and CAPA (NCR)

The Nonconformance, MRB and CAPA Cluster explains how quality issues should flow through execution instead of living in parallel systems. It covers how nonconformances are detected, contained, dispositioned, corrected, and prevented, with clear ownership and timing expectations. The content makes pause, quarantine, rework, and resume mechanics explicit so quality actions are operationally enforceable. This cluster connects quality events directly back to work instructions, traceability, and prevention rather than treating them as paperwork exercises.

  • Concession Volume

    Concession volume commonly refers to the quantity of material, parts, assemblies, or finished units covered by an approved concession. In manufacturing and quality contexts, a concession is a documented acceptance of a specified nonconformance under defined conditions, and the concession volume sets the numerical scope of that acceptance.

    This term helps define boundaries. It indicates how many affected items may be shipped, used, processed, or accepted under the concession. It does not, by itself, describe the technical deviation, the reason for acceptance, or the disposition decision criteria. Those details are usually recorded elsewhere in the concession or related quality records.

    How it is used in operations

    In practice, concession volume may appear as a count of pieces, batches, serial-numbered units, lots, or another controlled quantity measure. The exact unit depends on how the product is identified and controlled in the organization.

    • For discrete manufacturing, it may be the number of parts or assemblies covered.

    • For lot-controlled material, it may be a lot, batch, or a defined subset of that lot.

    • For serialized products, it may refer to specific serial numbers rather than a general count.

    Systems such as QMS, MES, or ERP may reference concession volume when tracking nonconforming product, release decisions, genealogy, and downstream use restrictions.

    What it includes and excludes

    Concession volume includes only the quantity explicitly authorized by the approved concession. It does not automatically extend to future production, similar parts, or additional nonconforming units unless those are also documented and approved.

    It also should not be confused with broader production volume, shipment volume, rework volume, or scrap volume. The term is limited to the quantity within the approved scope of concession treatment.

    Common confusion

    Concession volume is often confused with concession rate or concession frequency. Concession volume is the amount of product covered by a specific concession, while concession rate refers to how often concessions occur or what share of output they represent.

    It can also be confused with deviation quantity. In some organizations the terms are used similarly, but a deviation often refers to permission before manufacture or processing, while a concession commonly refers to acceptance of a known nonconformance after it exists. Usage varies by company and industry.

    Example

    If 25 parts in a lot have a minor documented nonconformance and quality approval allows those 25 specific parts to be accepted for use, the concession volume is 25 parts, not the full lot unless the full lot is explicitly included.

  • What information should be included in a supplier corrective action request?

    A supplier corrective action request should include enough verified information for the supplier to do four things: understand the nonconformance, contain any further impact, investigate likely cause, and respond in a way that can be reviewed and closed with evidence.

    At a minimum, most organizations include:

    • Supplier identification: supplier name, site, contact, supplier code, and any relevant buyer, program, or commodity ownership.
    • SCAR identification and control data: unique request number, issue date, required response dates, revision status if applicable, and the issuing function or approver.
    • A clear problem statement: what failed, where it was found, when it was found, and how it differs from the specified requirement.
    • Requirement reference: drawing, specification, purchase order clause, process requirement, quality clause, revision level, acceptance criteria, or other governing document tied to the issue.
    • Traceability details: part number, description, lot, batch, serial number, work order, shipment, packing slip, inspection record, and affected quantities.
    • Evidence of the nonconformance: inspection results, measurements, test data, photos, defect codes, samples retained if applicable, and the disposition status of suspect material.
    • Scope and impact: quantity received, quantity affected, whether the issue may extend to previous shipments, inventory, work in process, fielded product, or other customers if known.
    • Immediate containment expectations: stock segregation, shipment hold, certification review, reinspection, recall of open lots if required by your process, and confirmation of who is responsible for each step.
    • Requested supplier response: containment action, root cause analysis, corrective action, verification of effectiveness, implementation dates, and objective evidence.
    • Risk and priority: severity or escalation level if your process uses one, especially if the issue affects fit, form, function, airworthiness-related characteristics, regulatory commitments, or recurring escapes.
    • Communication and approval requirements: required response format, whether interim updates are mandatory, and who must review and approve closure on both sides.

    It also helps to state what you are not asking for. For example, if the immediate need is certified stock containment and not a full systemic response yet, say that explicitly. Ambiguity creates delay and weakens accountability.

    What makes a SCAR usable

    A usable SCAR is specific, traceable, and reviewable. It should link the reported defect to a requirement, affected product, and evidence trail. It should also define response deadlines that reflect actual risk and supplier capability. If the request is too vague, the supplier may respond with generic language that does not resolve the issue. If it is too prescriptive, you can end up forcing a method that does not fit the supplier’s process.

    In regulated and long-lifecycle environments, traceability matters as much as the corrective action itself. You may need to show later how the issue was detected, what material was affected, who approved the response, what changed, and how effectiveness was verified. That is one reason many organizations standardize SCAR content and approval steps even when suppliers use different internal systems.

    Common gaps that cause rework

    • No exact requirement cited, only a generic statement that the part is nonconforming.
    • No lot, serial, or shipment traceability, making containment incomplete.
    • No distinction between immediate correction, containment, root cause, and corrective action.
    • Response due dates without defined evidence requirements.
    • No statement of affected quantity or broader exposure.
    • No link to related NCR, MRB, receiving inspection, customer complaint, or CAPA records.
    • Closure based on supplier narrative alone, without objective verification.

    Those gaps are not just administrative problems. In a mature quality system, they create uncertainty about scope, weaken trend analysis, and make recurrence harder to manage.

    How detailed should it be?

    Detailed enough to be actionable, but not overloaded with irrelevant attachments. The right level depends on product criticality, supplier maturity, data quality, and how integrated your quality processes are. A minor documentation escape may need a lighter request than a repeated process failure on critical hardware. If your incoming inspection data is weak or your part traceability is fragmented across ERP, MES, QMS, and email, the SCAR may need more manual context just to establish the facts.

    That is also where brownfield reality matters. Many plants still manage supplier quality across mixed QMS, ERP, MES, portal, and spreadsheet workflows. In that environment, a good SCAR format often acts as the bridge between systems. Full replacement of those platforms is often not practical because of validation cost, qualification burden, downtime risk, integration debt, and long asset lifecycles. In practice, organizations usually improve the SCAR process by tightening data standards, approvals, and evidence handling across existing systems rather than replacing everything at once.

    Practical rule

    If a new quality engineer, supplier contact, or auditor could not reconstruct the issue and response path from the SCAR record and its attachments, it is probably missing key information.

  • systemic corrective action

    Systemic corrective action is corrective action designed to remove the underlying cause of a problem across the broader process, system, or control environment, rather than only fixing the single instance where the issue was found. In manufacturing and quality systems, it commonly refers to changes that prevent recurrence in similar products, lines, sites, suppliers, documents, training, or workflows.

    The term is often used in CAPA, NCR, 8D, and root cause analysis contexts. A systemic action goes beyond containment or local rework. It may include updates to procedures, inspection methods, equipment settings, master data, ERP or MES rules, training records, approval workflows, or supplier controls when those are part of the actual cause chain.

    Systemic corrective action is commonly contrasted with point correction. For example, replacing one defective part corrects the immediate issue; revising the setup standard, error-proofing the process, and updating operator instructions to prevent the same defect elsewhere would be systemic corrective action. The term does not necessarily mean enterprise-wide action in every case, but it does imply that the response addresses the broader mechanism that allowed the problem to occur or escape detection.

  • FMEA (Failure Modes and Effects Analysis)

    FMEA (Failure Modes and Effects Analysis) is a structured risk analysis method used to identify how a product, process, or system could fail, what the effects of those failures could be, and which failure modes deserve the most attention. In manufacturing and regulated operations, it is commonly used to evaluate potential quality, safety, reliability, or compliance-related issues before they result in defects, deviations, downtime, or customer impact.

    An FMEA typically documents the item being analyzed, its intended function, possible failure modes, the effects of each failure, likely causes, existing controls, and a way to prioritize risk. The method is used to support prevention and risk reduction, not to prove that failure is impossible and not to replace validation, verification, inspection, or root cause analysis after an event has already occurred.

    Where it applies

    FMEA is commonly applied in several ways:

    • Design FMEA (DFMEA): focuses on potential failures in a product or design.

    • Process FMEA (PFMEA): focuses on potential failures in manufacturing, assembly, inspection, packaging, or material handling steps.

    • System FMEA: focuses on interactions across subsystems, equipment, software, or operational functions.

    In plant and quality workflows, FMEA may be linked to control plans, work instructions, process characteristics, inspection strategies, CAPA inputs, and change management records.

    How it is used operationally

    In practice, teams use FMEA to review each step or function, ask what could go wrong, assess the consequences, identify causes and controls, and rank issues for further action. In a manufacturing environment, examples might include an incorrect torque setting, mislabeled material, missed inspection step, recipe parameter drift, or loss of traceability data.

    FMEA is often maintained as a living document when products, equipment, suppliers, routing steps, software logic, or process parameters change. In digital quality systems or MES-integrated environments, some organizations connect FMEA outputs to process controls, nonconformance workflows, and evidence records, but the FMEA itself remains an analysis method rather than an execution system.

    Common confusion

    FMEA is often confused with related terms:

    • FMECA: a related method that adds a formal criticality analysis to the failure mode review.

    • Risk assessment: FMEA is one type of risk assessment, but not the only one.

    • CAPA or root cause analysis: FMEA is generally preventive and forward-looking, while CAPA and root cause methods are commonly used after a problem is found.

    • Control plan: a control plan defines how a process is monitored and controlled; FMEA helps identify what should be controlled and why.

    Another common point of confusion is the scoring method. Many teams associate FMEA with severity, occurrence, and detection ratings and an overall Risk Priority Number (RPN). Those scoring approaches are widely used, but the exact method can vary by industry, company, or quality framework.

  • risk-based escalation

    Risk-based escalation is the practice of routing an issue, event, deviation, or decision to a higher level of review based on its assessed risk rather than by a fixed rule alone. In manufacturing and quality systems, this commonly means that higher-severity, higher-impact, or less-controlled situations are escalated faster, to more senior roles, or into more formal workflows.

    The term is commonly used in quality management, nonconformance handling, deviation review, supplier issues, maintenance response, and production support. A risk-based escalation model may consider factors such as product impact, safety relevance, regulatory sensitivity, customer effect, recurrence, containment status, and time criticality. For example, a minor documentation error may stay within routine correction, while a repeated process deviation affecting traceability may be escalated to quality, engineering, or management review.

    Risk-based escalation does not mean any issue can be handled informally. It usually operates within a defined procedure, matrix, or workflow that sets escalation thresholds and responsible roles. It is also not the same as a risk register, which records risks, or a CAPA, which manages investigation and corrective action after an issue is formally taken up. In digital systems such as MES, QMS, ERP, or service management tools, risk-based escalation is often implemented through priority rules, workflow states, notifications, and approval routing.

  • Dimensional Report

    A dimensional report is a formal record that documents the measured dimensions of a part or assembly and compares them to the design or specification requirements. It is commonly generated after an inspection activity and is used as objective evidence that the manufactured item meets, or does not meet, defined dimensional tolerances.

    What a dimensional report typically includes

    While formats vary by organization and customer, a dimensional report commonly contains:

    • Part and drawing identifiers (part number, revision, drawing number)
    • Inspection lot, work order, or serial number references
    • List of characteristics or features to be measured (often ballooned from the drawing)
    • Nominal dimension and tolerance for each characteristic
    • Actual measured values from inspection equipment
    • Pass/fail or in-tolerance/out-of-tolerance indication for each dimension
    • Measurement method and equipment identifiers, when required
    • Inspector identification and date, and sometimes approval signatures

    In regulated and aerospace environments, the dimensional report may be tied to first article inspection (FAI) packages, manufacturing records, or supplier deliverables.

    Operational use in manufacturing and quality systems

    In industrial operations, dimensional reports are used to:

    • Provide traceable evidence that critical dimensions meet design and customer requirements
    • Support first article inspection and qualification builds
    • Document results of in-process, final, or receiving inspection activities
    • Feed nonconformance, CAPA, or MRB workflows when dimensions are out of tolerance
    • Support audits and customer reviews of inspection and quality records

    Digital MES, QMS, or inspection systems often generate dimensional reports automatically from captured measurement data, linking them to work orders, inspection plans, and device history or as-built records.

    Relationship to standards and FAI

    In aerospace, dimensional reports are often part of AS9102 first article inspection documentation. The report lists drawing characteristics, their requirements, and the measured results that demonstrate conformity. Similar reporting approaches are used in other regulated sectors, even when different standards apply.

    What a dimensional report is not

    • It is not the same as a full device history record or manufacturing history, which includes process steps, materials, and other data, not only dimensions.
    • It is not a process capability study, although dimensional report data may be used as input to capability analysis.
    • It is not limited to first articles; it can be used for routine inspection, sample inspection, or special measurement studies.

    Common confusion

    • Dimensional report vs. inspection report: An inspection report is a broader term that may include visual checks, functional tests, and other attributes. A dimensional report focuses specifically on measured dimensions and tolerances.
    • Dimensional report vs. CMM report: A CMM report is a type of dimensional report generated from a coordinate measuring machine. Not all dimensional reports come from CMMs; they may use calipers, micrometers, optical systems, or manual gauges.

  • What criteria should drive a scrap decision for aerospace structural parts?

    A scrap decision for aerospace structural parts should be driven first by approved technical requirements and objective evidence, not by part value, schedule pressure, or whether the defect “looks minor.” In practice, the core question is simple: can the part still be shown, with traceable records, to conform to drawing, material, process, and customer or program requirements after any permitted rework or repair? If the answer is no, or cannot be demonstrated credibly, scrap is usually the right decision.

    What should drive the decision

    The decision normally starts with product definition and disposition authority, not shop-floor opinion. For structural parts, the most important criteria are these:

    • Type and severity of nonconformance: dimensional out-of-tolerance, wrong material, heat-treat issue, surface damage, blend-out condition, hole quality problem, coating issue, process excursion, or traceability gap do not carry the same risk.
    • Location and structural criticality: the same defect may be acceptable in a non-critical area and unacceptable in a high-stress, fatigue-critical, bearing, sealing, or mating feature.
    • Engineering allowables and drawing requirements: if approved limits, repair schemes, or rework paths exist, they govern. If they do not, the part is not automatically recoverable.
    • Material and process pedigree: unknown or broken traceability, suspect lot control, or missing process records can force scrap even when the geometry appears recoverable.
    • Effect of rework or repair: additional machining, blending, sleeving, bushing, cold work, weld repair, or other recovery steps may consume life margin, alter fit, or trigger requalification requirements.
    • Inspection evidence quality: the decision depends on reliable measurement, calibrated equipment, valid methods, and a clear understanding of actual versus suspected defect extent.
    • Contractual and customer constraints: some programs restrict repair methods, concession use, or repeated rework more tightly than internal practice would suggest.
    • Disposition authority: MRB, engineering, quality, and sometimes customer approval are required depending on the condition and the contract. Operators and supervisors should not be making final structural accept/scrap calls informally.

    What should not drive it

    Cost matters, but it is not the primary criterion. A high-cost part is not more repairable just because it is expensive to replace. Likewise, delivery pressure is not a technical basis for use-as-is, repair, or rework. In regulated aerospace environments, forcing borderline parts through because capacity is tight usually creates a larger problem later in audit trail review, customer escape analysis, or service risk assessment.

    When scrap is often the right answer

    Scrap is commonly the right outcome when one of these is true:

    • The nonconformance violates a requirement with no approved rework or repair path.
    • The defect affects a critical feature and engineering cannot justify residual strength, fatigue performance, fit, or function.
    • Required traceability is missing or compromised for material, processing, or serialized identity.
    • The proposed recovery would push the part outside other limits, including minimum wall, edge distance, coating thickness, residual stress expectations, or dimensional stack-up.
    • The process excursion is broad enough that the true impact cannot be bounded credibly.
    • The record set needed to support acceptance, concession, or repair cannot be completed with confidence.

    Where MRB and engineering matter

    For aerospace structural hardware, scrap decisions are usually part of a formal nonconformance process. MRB may coordinate the disposition, but engineering rationale is often decisive where structural performance is affected. The exact split of authority depends on company procedures, delegated authority, customer flowdowns, and part criticality.

    This is where many plants get into trouble. They treat scrap as a production loss decision when it is really a controlled disposition decision. If the nonconformance workflow in MES, QMS, and ERP is weak, teams may argue from incomplete data, outdated drawings, or disconnected inspection records. In brownfield environments, that failure mode is common.

    Data and system dependencies

    A good scrap decision depends on having the right records linked together:

    • Current drawing and revision from PLM or document control
    • Traveler or routing history from MES or paper traveler records
    • Material certs, lot genealogy, and serialized traceability
    • Special process records
    • Inspection results, including CMM or manual measurement evidence
    • Prior rework, prior NCRs, or repeated escapes on the same feature
    • Customer-specific disposition restrictions where applicable

    If those records are fragmented across MES, ERP, QMS, and shared drives, the practical risk is not just delay. It is an incorrect disposition based on partial evidence. Full system replacement is usually not the answer here. In regulated aerospace environments, replacing core execution and quality systems wholesale often fails because of validation cost, qualification burden, downtime risk, and integration complexity. More often, plants improve the decision process by tightening record linkage, authority rules, and evidence capture across existing systems.

    A practical decision frame

    A defensible scrap decision for a structural part usually asks these questions in order:

    1. What exact requirement was violated?
    2. Is the feature structurally or functionally critical in this location?
    3. Is there an approved rework or repair path for this condition?
    4. Will that recovery path preserve all other requirements and margins?
    5. Do we have complete, trustworthy evidence and traceability to support the disposition?
    6. Do the required authorities agree and document the rationale?

    If any of those answers is unclear, the part should stay in formal nonconformance control until clarified. In many cases, that uncertainty ends in scrap, and that is sometimes the least risky outcome.

    Bottom line

    The right criteria are technical conformity, structural intent, traceability, and approved disposition authority. Scrap should be decided by whether the part can still be demonstrated to meet requirements after an allowed recovery path, not by replacement cost or urgency. Where evidence is weak, traceability is broken, or structural margin cannot be justified, scrap is usually the defensible decision.

  • Nonconformance Code

    A nonconformance code is a standardized identifier used to classify a nonconformance in a quality or manufacturing system. It commonly appears as a short alphanumeric value, picklist option, or controlled label in records such as NCRs, inspection results, supplier issues, scrap reports, or CAPA-related workflows.

    The code does not describe the entire event by itself. It is a structured way to categorize the issue so that people and systems can sort, trend, route, report, and analyze nonconformances consistently across products, work centers, suppliers, or sites.

    What it typically includes

    • The type of nonconformance, such as dimensional, documentation, material, process, or labeling issue

    • Sometimes the source or point of detection, such as incoming inspection, in-process inspection, final inspection, or customer return

    • Sometimes disposition or workflow classification, depending on how the quality system is configured

    In digital quality systems, a nonconformance code may drive reporting logic, approvals, escalation paths, or links to downstream activities such as MRB review, rework, scrap tracking, supplier follow-up, or corrective action.

    What it is not

    A nonconformance code is not the same as the full nonconformance record. The full record usually includes details such as part or batch affected, requirement not met, quantity, evidence, containment, disposition, and approvals. The code is only one controlled data element within that record.

    It is also not necessarily a root cause code. Some organizations use separate coding structures for defect type, cause, containment, and disposition to avoid mixing problem description with cause analysis.

    Common confusion

    Nonconformance code is often confused with defect code, rejection code, disposition code, or root cause code. These may overlap in some systems, but they are not always interchangeable:

    • A defect or rejection code usually identifies what was found wrong

    • A disposition code usually identifies what will be done with the affected item, such as rework or scrap

    • A root cause code usually identifies why the issue happened after investigation

    Organizations sometimes use one code set for several of these purposes, but the distinction matters for reporting accuracy and trend analysis.

    Manufacturing context

    In manufacturing and regulated environments, nonconformance codes support more consistent data capture across MES, QMS, ERP, and supplier quality workflows. For example, a receiving inspector might select a code for a material certification mismatch, while an in-process operator or quality technician might select a code for an out-of-tolerance feature. When codes are standardized, quality teams can compare patterns across jobs, lines, products, and suppliers more reliably.