Connect981 – Content Dev

FAQ Tag: change control

  • How long should an NCR stay open before escalation in aerospace environments?

    There is no single fixed number of days that is correct for every aerospace NCR. The escalation point should be defined by your quality system, product risk, contractual obligations, and the operational impact of leaving the NCR open.

    In practice, an NCR should escalate when it is open long enough to create unmanaged risk, delay disposition, weaken traceability, or allow recurrence without effective containment. For aerospace environments, that often means using tiered aging rules rather than one blanket deadline.

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    What usually drives escalation

    • Severity and criticality: Potential airworthiness impact, flight safety relevance, special process exposure, escaped nonconformance, and configuration impact should escalate faster than routine workmanship issues.

    • Containment status: If suspect material is not fully identified, segregated, and controlled, escalation should happen quickly regardless of NCR age.

    • Production impact: Line stoppage, blocked assemblies, shortage creation, or repeated use-as-is decisions are signs the issue should not sit in a queue.

    • Recurrence: Repeated NCRs on the same part, process, tool, supplier, or failure mode usually warrant earlier management review.

    • Disposition path: Cases needing MRB, engineering review, customer approval, supplier response, or concession workflows often take longer, but that is not a reason to leave them unmanaged. Aging controls still need checkpoints.

    • Customer and internal requirements: Some programs, contracts, or internal procedures define explicit response and closure windows. Those must govern if they exist.

    A practical approach

    A common approach is to set formal review thresholds such as:

    • initial review within 24 to 72 hours for triage, containment, and ownership

    • management visibility after a defined aging point such as 7, 14, or 30 days depending on risk class

    • senior quality or operations escalation for overdue disposition, blocked material, repeat events, or customer-impacting issues

    That does not mean every NCR should close in a week. Some aerospace NCRs legitimately remain open longer because root cause work, engineering assessment, supplier investigation, or approval workflows take time. The control point is not just total age. It is whether the record shows timely containment, clear ownership, documented status, and justified delay.

    What should not happen

    An NCR should not remain open indefinitely because the plant is busy, the responsible function is unclear, or the disposition process is fragmented across QMS, ERP, MES, PLM, and email. In brownfield environments, this is common. Open NCR aging often reflects system handoff failures as much as product quality issues.

    If your process spans multiple systems, escalation rules should account for that reality. For example, an NCR may be created in QMS, tied to hold status in ERP, linked to genealogy or traveler data in MES, and require engineering action from PLM or a separate workflow tool. If those integrations are weak, aging metrics can be misleading unless ownership and status synchronization are explicit.

    What auditors and leadership typically care about

    Not whether every NCR closes within one universal number, but whether you can show:

    • documented criteria for escalation and aging

    • risk-based prioritization

    • effective containment while the NCR is open

    • clear responsibility and due dates

    • traceable links to MRB, CAPA, supplier action, and rework or scrap decisions where applicable

    • evidence that overdue NCRs are reviewed, not ignored

    So the short answer is: escalate based on risk and aging thresholds defined in your quality system, not on an industry myth that every aerospace NCR must close in a fixed number of days. If you do not already have formal thresholds, many organizations start with staged reviews at 7, 14, and 30 days, then tighten or relax by risk class and process maturity.

    If your backlog is large, the safer response is usually not a full system replacement. In regulated aerospace settings, replacing QMS, MES, ERP, or MRB-related workflows outright often fails because of validation burden, qualification impact, downtime risk, integration complexity, and long equipment and process lifecycles. A more realistic path is to add aging rules, ownership checkpoints, and evidence links across existing systems first.

  • Who should be responsible for planning and executing FAI?

    In regulated aerospace and defense environments, no single person or function should own all aspects of First Article Inspection (FAI). Planning and execution usually span several roles, with clear accountability defined in the Quality Management System (QMS), procedures, and customer flowdowns.

    Typical responsibility split for FAI

    1. Quality function (process owner and approval authority)

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    • Owns the FAI procedure, forms, and alignment to AS9102 or other customer standards.
    • Defines when FAIs are required (new part, design change, process change, lapse in production, supplier change, etc.).
    • Ensures measurement methods, gages, and sampling are appropriate and calibrated.
    • Reviews and approves the FAI package (forms, ballooned drawing links, objective evidence).
    • Interfaces with customers or regulatory representatives on FAI questions and findings.

    2. Engineering (planning and technical definition)

    • Translates design requirements into inspectable characteristics and inspection plans.
    • Supports drawing ballooning, feature definition, and characteristic classification where required.
    • Defines or approves special process controls, process parameters, and key characteristic controls.
    • Ensures manufacturing routings, work instructions, and tooling/gage plans align with the FAI.
    • Resolves technical discrepancies during FAI (tolerance interpretation, alternative methods, concessions).

    3. Operations / Production (execution of the build)

    • Manufactures the FAI part using normal, released production processes and routings.
    • Executes in-process inspections and records actuals where required by the FAI plan.
    • Coordinates with Quality to make parts, fixtures, and records available for measurement.
    • Implements corrective actions to the process when FAI reveals nonconformances or instability.

    4. Inspection / Metrology (measurement execution)

    • Performs dimensional and functional measurements against the FAI plan and drawing.
    • Documents objective evidence (CMM reports, test results, SPC data, gage readings).
    • Flags any nonconformances, out-of-tolerance conditions, or ambiguous requirements.
    • Supports repeatability checks if the FAI is questioned by the customer or internal audit.

    5. Supply chain / Supplier quality (for purchased parts)

    • Communicates FAI requirements and formats to suppliers and verifies they understand them.
    • Ensures supplier FAIs are submitted on time, complete, and aligned to contractual standards.
    • Performs incoming inspection and FAI package review for critical and delegated parts.
    • Coordinates with internal Quality for approval and any required feedback to the supplier.

    Who is ultimately accountable?

    Although multiple functions contribute, ultimate accountability should be explicit:

    • Process ownership for FAI usually sits with the Quality organization (e.g., Quality Manager or designated FAI coordinator).
    • Technical correctness (requirements, ballooning logic, inspection methods) is typically owned by Engineering.
    • Process capability and repeatability is owned by Operations, since FAI is intended to prove the production process, not a one-off lab build.
    • For supplier FAIs, Supplier Quality or Supply Chain is often accountable for ensuring the supplier’s FAI meets internal and customer expectations before acceptance.

    In a mature QMS, these accountabilities are defined in:

    • FAI or AS9102 procedure(s) and process maps.
    • RACI matrices that cover planning, execution, review, and customer submission.
    • Job descriptions or role profiles for Quality, Engineering, and Operations leads.

    Planning vs. execution responsibilities

    FAI planning is usually led by Quality and Engineering together:

    • Quality: triggers FAI based on criteria, selects FAI type (full, partial, delta), and defines documentation expectations.
    • Engineering: defines the inspection plan, special process controls, and any additional checks beyond AS9102 minimums.
    • Both: agree on what constitutes an acceptable FAI outcome and how nonconformances will be processed.

    FAI execution is usually distributed:

    • Operations: produces the part under normal production conditions and captures required in-process data.
    • Inspection/Metrology: executes measurements and records results on the FAI forms or digital system.
    • Quality: assembles, reviews, and approves the complete package, including nonconformance records and concessions where present.

    Dependencies on systems and plant context

    Who does what in practice depends heavily on your system landscape and process maturity:

    • Brownfield reality: Many plants have paper travelers, a mix of legacy MES and point inspection tools, and limited integration with PLM or ERP. In these cases, FAI coordination often lands with a single experienced Quality engineer or planner who manually stitches data together.
    • Digital FAI tools: Where AS9102 or Net-Inspect style software is in place and integrated with PLM/MES, ballooning, characteristic import, and result capture may be shared between Engineering, Inspection, and Quality. The tool does not change who is accountable, only how work is divided and evidenced.
    • Supplier FAIs: If suppliers submit FAIs through portals (e.g., customer-mandated systems), supplier quality typically owns review and internal routing, even if plant Quality signs the final internal approval.

    Because plants operate different mixes of MES, PLM, QMS, and inspection software, you should not assume that FAI can be centralized in one system or role without considering:

    • Traceability and record retention requirements.
    • Who can legally and contractually sign off on FAIs.
    • Where authoritative design, process, and measurement data actually resides.

    Common failure modes when responsibilities are unclear

    When FAI responsibilities are not well defined, typical problems include:

    • Parts built without required FAI because no one owns the trigger logic.
    • FAIs executed with non-production setups, so results do not represent normal process capability.
    • Conflicting versions of drawings or models used for ballooning and inspection.
    • Suppliers completing FAIs to different standards than internal expectations.
    • Audit findings due to missing signatures, incomplete traceability, or inconsistent application of AS9102.

    These failures are rarely system-only issues. They usually reflect unclear process ownership and weak coordination between Quality, Engineering, and Operations.

    Practical way to assign responsibility

    To make FAI responsibilities explicit without overcomplicating:

    1. Define a single FAI process owner (usually Quality) responsible for the procedure, training, and continuous improvement.
    2. Document a RACI for at least: FAI trigger/decision, ballooning and inspection planning, part build, measurement, FAI review/approval, and customer submission.
    3. Align roles to existing systems: specify who enters or approves data in PLM, MES, QMS, or FAI software, given your current brownfield stack.
    4. Review with key customers and suppliers where their requirements impose extra steps (customer witness, mandatory formats, portal submissions).
    5. Periodically audit FAI execution to confirm that actual practice matches the defined roles and that handoffs between functions are reliable.

    This approach respects existing systems and constraints, avoids assuming a full platform replacement, and focuses on clearly owned responsibilities for planning and executing FAI within your current environment.

  • What makes a corrective action effective and auditable in aerospace environments?

    In aerospace environments, a corrective action is judged on two dimensions: whether it actually eliminates or reduces the true root cause, and whether an independent reviewer (customer, regulator, or registrar) can reconstruct what you did and why. Both depend on disciplined problem solving and reliable records, not on any single tool or software module.

    1. Clear problem definition and containment

    Before a corrective action is even designed, you need a precise, bounded problem statement and documented containment. Auditors look for:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • A specific, measurable description of the nonconformance or event, linked to NCR, lot, part number, and configuration.
    • Evidence of immediate containment (quarantine, ship-hold, customer notification, screening) and who authorized it.
    • Traceability of affected product: where it is in WIP, stock, ship, or in service, and how you decided the exposure window.

    Without this, later claims about corrective action effectiveness are hard to defend. You cannot show what risk you were actually trying to retire.

    2. Root cause based on evidence, not assumption

    Effective corrective action in aerospace nearly always starts from a structured root cause analysis (8D, RCCA, 5-Whys, fishbone, fault tree, etc.). Auditable quality means:

    • A documented method (e.g., 8D / RCCA) and a clear separation between symptoms, direct cause, contributing causes, and systemic/root causes.
    • Use of objective data where possible: process history, inspection results, maintenance logs, training records, change history, and supplier data.
    • Explicit consideration of human factors and system interactions, not just blaming “operator error.”
    • Rationale for why alternative causes were rejected, especially when data is incomplete.

    In a brownfield plant, this often depends on how well MES, ERP, PLM, and QMS data can actually be correlated. Where data is missing or inconsistent, you must state that limitation instead of overstating confidence in the root cause.

    3. Corrective actions aligned to the verified root cause

    A corrective action is not just “more inspection” or “retraining” unless that directly addresses the verified cause. Auditors test effectiveness by assessing the logic between cause and action:

    • Each action should be explicitly mapped back to the specific root or contributing cause it mitigates.
    • Actions should move upstream in the process where possible (design, routing, tooling, programming, planning), not only add downstream checks.
    • Risk-based thinking: higher risk issues should drive more robust, systemic actions (error-proofing, design or spec changes, automation, supplier qualification changes).
    • Defined owners, due dates, and affected sites/lines/cells, especially when multiple facilities or suppliers share a process.

    If the root cause turns out to be incorrect, the right answer is to revise the analysis and the actions with full change history, not to stretch the narrative to fit the implemented fix.

    4. Integrated with change control and configuration management

    In aerospace, many corrective actions require formal change control. Auditors expect:

    • Links between the corrective action and controlled documents: drawings, specifications, digital work instructions, routings, NC programs, tooling, and test methods.
    • Evidence of appropriate approvals (engineering, MRB, quality, customer when required) before implementation on production hardware.
    • Configuration awareness: which part numbers, revisions, and programs are covered by the change and which are intentionally out of scope.
    • Alignment with long equipment and tool lifecycles: how changes are validated on legacy assets and across similar machines or cells.

    Full replacement of systems (e.g., a new MES or QMS just to “fix” CAPA) is rarely practical without major requalification, downtime risk, and integration work. More realistic is to layer better CAPA workflows and traceability on top of existing systems, with clear interfaces and data ownership.

    5. Defined verification and effectiveness criteria

    “Implemented” is not the same as “effective.” Aerospace auditors look for a plan that defines up front how you will prove the action worked:

    • Specific, time-bound effectiveness criteria: e.g., no repeat events of a defined category over X builds or Y flight hours, reduced scrap/rework on a given feature, improved capability index, etc.
    • Verification methods: targeted audits, focused inspections, process monitoring, capability studies, or review of field performance.
    • Clear trigger conditions for escalation when verification fails, including when to reopen the root cause analysis.

    Where data systems are fragmented, it is important to document exactly which data sources you used and their limitations, so auditors understand the confidence level in your effectiveness claim.

    6. Traceable, tamper-evident records and audit trails

    Auditable corrective action depends on the ability to reconstruct who did what, when, and based on which inputs. In practice this means:

    • Each NCR and CAPA has a unique identifier that is consistently referenced across QMS, MES, ERP, PLM, and supplier systems.
    • Time-stamped records of problem definition, containment, root cause analysis, action planning, approvals, implementation, and closure.
    • Controlled editing: you can add clarifications and corrections, but there is a preserved history of changes and previous states.
    • Clear linkage to training completion, updated work instructions, tooling changes, and other downstream impacts.

    Digital systems can help, but only if they are validated for their intended use, integrated cleanly, and governed properly. Otherwise, parallel spreadsheets or emails will create gaps that are difficult to defend during an AS9100-style audit.

    7. Consistent risk assessment and prioritization

    In aerospace, not every nonconformance justifies the same level of corrective action. Effectiveness includes putting effort where risk is highest:

    • Documented assessment of safety, regulatory, reliability, and customer impact.
    • Use of internal risk matrices or FMEAs to prioritize which issues require formal CAPA versus local corrections.
    • Traceability of how risk assessment influenced the type and scope of actions taken.

    Auditors will not expect zero issues, but they will expect a rational, repeatable framework for deciding where to invest in deeper investigation and systemic fixes.

    8. Embedded in everyday execution, not standalone paperwork

    Corrective actions are more effective and more auditable when they are visible to the people doing the work and reflected in actual processes:

    • Updated digital or paper work instructions and travelers that operators can easily access and understand.
    • Feedback loops from the shop floor and MRO environments (e.g., operator feedback, layered process audits) that identify when a corrective action is not practical or is being bypassed.
    • Training and qualification records tied to the changed process, especially in high-mix, low-volume (HMLV) aerospace work.

    Where systems are mixed (legacy MES, point QMS tools, manual travelers), it is important to define a single “system of record” for CAPA status and to ensure each execution system reflects the current state of the corrective action.

    9. Recognized closure with ongoing surveillance

    A correctively addressed issue should have a defined closure, but closure is not the same as forgetting. Effective and auditable practices include:

    • Formal closure criteria: all actions implemented, verification completed, and no open dependent changes.
    • Documented justification for closure, including reference to performance data over a defined surveillance window.
    • Use of internal audits, layered process audits, or customer scorecards to periodically revisit high-risk themes and confirm no silent recurrence.

    “Perpetually open” CAPAs with no progress are as problematic as prematurely closed ones. Both will be challenged in an AS9100 or customer audit.

    10. How this plays out in brownfield aerospace environments

    In most aerospace organizations, corrective actions must coexist with legacy QMS, ERP, MES, PLM, and supplier portals. This reality drives some practical constraints:

    • Full replacement of core systems just to achieve better CAPA performance usually fails or stalls because of validation cost, downtime risk, integration complexity, and long equipment lifecycles.
    • A more viable path is incremental digitization: standardizing problem-solving methods, defining a single CAPA record of truth, and then integrating existing systems so that NCRs, MRB decisions, and corrective actions share IDs and basic data.
    • Any new CAPA or NCR software must be validated for its intended use, integrated with document control and training records, and managed under change control to remain credible in audits.

    Ultimately, a corrective action in aerospace is considered effective and auditable when you can show a clear line from the original issue, through objective root cause analysis and risk-based actions, to sustained improvement, with every step traceable and explainable to a skeptical external reviewer.

  • What is the difference between corrective action and preventive action in aerospace?

    Corrective action is taken after a problem, nonconformity, escape, or adverse trend is identified. Its purpose is to remove the cause of that specific issue so it does not happen again.

    Preventive action is taken before a problem occurs. Its purpose is to remove the cause of a potential nonconformity or failure mode that has not yet occurred, but is reasonably foreseeable based on risk, trend data, process knowledge, audits, or similar evidence.

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    In practical aerospace terms:

    • Corrective action: A machined part fails inspection because a setup instruction was unclear. The organization investigates the cause, updates the instruction, retrains affected personnel, revises controls if needed, and verifies the issue does not recur.
    • Preventive action: Trend data shows increasing variation on a similar process, even though parts are still within tolerance. The organization tightens process controls, revises work instructions, or adds checks before an actual nonconformance occurs.

    What actually separates them

    • Trigger: Corrective action starts with a detected problem. Preventive action starts with a detected risk or credible precursor.
    • Evidence basis: Corrective action is tied to an actual event, record, or escape. Preventive action is tied to analysis, trends, audit observations, risk review, or process knowledge.
    • Objective: Corrective action prevents recurrence. Preventive action prevents occurrence.
    • Documentation burden: Both need documented rationale, but preventive action often fails when the risk basis is weak or too speculative.

    Important aerospace nuance

    In aerospace quality systems, the distinction is conceptually straightforward, but execution is often harder than the definition suggests. Many organizations are better at corrective action than preventive action because actual nonconformances generate clear records, owners, and urgency. Preventive action depends more on disciplined risk review, trend detection, cross-functional judgment, and follow-through.

    Also, not every fix is a true corrective action. Containment, rework, sorting, and concessions may address the immediate impact, but they do not count as corrective action unless the underlying cause is addressed and effectiveness is checked.

    Similarly, not every improvement project is preventive action. To qualify, it should be tied to a defined potential failure mode or risk, not just a general desire to optimize.

    Where organizations get this wrong

    • Treating containment as root cause elimination.
    • Closing actions without evidence that the change was implemented and remained effective.
    • Calling routine continuous improvement “preventive action” without a documented risk basis.
    • Using vague causes such as operator error without examining training, instructions, tooling, sequencing, design inputs, or system conditions.
    • Assuming software workflows alone improve CAPA quality. They can improve traceability, but weak investigations remain weak investigations.

    System and process implications

    In brownfield aerospace environments, corrective and preventive actions usually span multiple systems, not one clean workflow. The trigger may start in NCR, audit, MES, ERP, QMS, supplier quality, or maintenance records. The action itself may require controlled changes to documents, training records, process parameters, supplier controls, or inspection plans.

    That means success depends on more than having a CAPA module. It depends on:

    • Clear ownership across quality, engineering, operations, and IT.
    • Traceable links between issue records, root cause analysis, approved changes, and effectiveness checks.
    • Controlled updates to work instructions, routings, BOM-related data, inspection criteria, and training where applicable.
    • Validation of digital workflow changes when required by internal procedures or regulated product and process controls.

    Full replacement of legacy quality and execution systems is often not the practical answer. In aerospace, replacement programs can fail because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability across long equipment and product lifecycles. In many plants, a more realistic approach is to improve evidence flow and change control across existing systems first.

    Bottom line

    The difference is simple: corrective action responds to an actual problem, while preventive action responds to a credible potential problem. In aerospace, the harder part is not the definition. It is proving the cause was correctly identified, the change was controlled, and the action was effective in a mixed-system, highly traceable environment.

  • How should we report non-conformance metrics to leadership?

    Leadership reporting should focus on risk, flow, and cost, not just the count of NCRs. A useful report shows whether non-conformances are increasing operational risk, slowing throughput, driving rework or scrap, and exposing weaknesses in containment or corrective action.

    In practice, most leadership teams need a small set of metrics presented together because any single metric can be misleading. For example, a higher NCR count can mean worsening process control, but it can also mean better detection, broader inspection coverage, or cleaner reporting discipline. If you report counts alone, leadership can draw the wrong conclusion.

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    What to include

    • Volume and trend: NCRs opened, closed, and backlog over time, normalized where possible by production volume, lots, units, or work orders.

    • Severity and business impact: Separate minor issues from events with material impact on product, delivery, customer commitments, or downstream qualification work.

    • Containment effectiveness: Time to containment, open escapes, and whether suspect material remains in process, inventory, or shipment channels.

    • Aging: Open NCR aging by bucket, especially items awaiting disposition, MRB action, supplier response, or corrective action closure.

    • Recurrence: Repeat non-conformances by part, process step, supplier, cell, program, or defect code.

    • Cost and operational effect: Rework hours, scrap value, line disruption, schedule impact, premium freight, and other COPQ measures if the underlying data is credible.

    • Corrective action progress: CAPA conversion rate where applicable, overdue actions, and verification status of implemented fixes.

    • Source breakdown: Internal, supplier, incoming, in-process, final inspection, test, and field or customer-originated events.

    How to present it

    Use a short leadership view with operational drill-down behind it. The first page should answer five questions:

    1. Are we seeing more risk or less risk?

    2. Where is the risk concentrated?

    3. Are issues being contained quickly enough?

    4. Are the same problems coming back?

    5. What is the delivery and cost impact?

    That usually means combining lagging and leading indicators. Lagging indicators include scrap, escapes, and backlog. Leading indicators include recurrence, aging, overdue actions, and concentration in a specific process step or supplier.

    Show trends over time and segment by program, product family, line, supplier, or process area only where data definitions are stable. If definitions changed, state that clearly on the report. In regulated environments, leadership needs confidence that the metric means the same thing this month as it did last month.

    What to avoid

    • Do not use closure count as a proxy for quality improvement. Teams can close paperwork faster without reducing defect generation.

    • Do not report scrap, rework, and NCR counts from disconnected systems as if they are perfectly reconciled.

    • Do not hide backlog aging behind monthly averages. Aging distribution matters.

    • Do not compare plants or programs without normalizing for mix, inspection intensity, product complexity, and reporting discipline.

    • Do not reward low NCR reporting. That can suppress detection and damage traceability.

    Brownfield reporting reality

    In many plants, non-conformance data sits across QMS, MES, ERP, supplier portals, spreadsheets, and email-based workflows. That means leadership reports often have blind spots. Some sites can measure disposition cycle time accurately but not true recurrence. Others can estimate scrap cost but not fully capture rework labor or schedule disruption. Say that plainly.

    If your systems are not well integrated, report system boundaries with the metric. For example: internal NCRs from QMS, scrap from ERP inventory transactions, rework hours from MES only for selected work centers. That is better than presenting a clean but false enterprise number.

    Full replacement of legacy systems is usually not the right first answer. In regulated, long-lifecycle environments, replacement can fail because of validation burden, qualification concerns, downtime risk, integration complexity, and the need to preserve traceability and change control across existing processes. A phased reporting model, with clear definitions and evidence trails, is often more realistic.

    Governance matters as much as the dashboard

    Leadership metrics are only useful if the underlying process is controlled. Define ownership for each metric, lock the business rules, document exclusions, and manage changes formally. If a defect code structure, disposition workflow, or cost model changes, the trend line may no longer be comparable. That is not a dashboard problem. It is a governance problem.

    Also separate executive review from root cause analysis. Leadership needs concise indicators and decisions. Engineering and quality teams need the detailed Pareto, defect mode, process-step, and evidence-level analysis underneath.

    A practical rule is this: report non-conformance metrics to leadership as a balanced set of risk, aging, recurrence, and impact measures, with explicit notes on data quality and scope. If your report cannot explain what is happening operationally or what action is required, it is probably too shallow.

  • Which aerospace production decisions should never be fully automated by AI?

    No. In aerospace production, some decisions can be supported by AI, but should not be fully delegated to it as the final authority.

    The line is not whether a decision is important. The line is whether the decision changes product acceptability, process intent, airworthiness-relevant evidence, or risk ownership. If it requires accountable judgment, controlled sign-off, traceable rationale, or interpretation of incomplete evidence, full automation is usually a poor fit.

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    Decisions that should not be fully automated

    • Nonconformance disposition and MRB decisions. AI can help classify issues, retrieve similar cases, or summarize evidence. It should not independently decide use-as-is, rework, repair, scrap, or concession paths.

    • Engineering changes that affect approved product or process definition. Suggested updates to routings, work instructions, inspection plans, tooling, limits, or material substitutions need formal review, change control, and impact assessment.

    • Final product release decisions. Shipment, operation release, build completion, or stage-gate release should not depend on AI alone, especially where records are incomplete, data quality is uneven, or exceptions exist.

    • Acceptance or override of out-of-tolerance or ambiguous inspection results. AI may flag anomalies or prioritize review, but deciding that a part is acceptable despite conflicting evidence requires qualified human judgment.

    • Deviation, concession, and risk acceptance decisions. These assign responsibility for risk and usually require documented rationale across quality, engineering, and sometimes customer or regulator-facing processes.

    • Root cause conclusions in high-impact events. AI can propose hypotheses, cluster symptoms, and identify patterns. It should not be the sole mechanism that determines root cause for escapes, recurring failures, or safety-critical process breakdowns.

    • Training qualification or operator authorization decisions. AI can assess completion patterns or likely skill gaps, but should not alone authorize a person for critical tasks.

    • Supplier approval, disqualification, or critical source change decisions. AI scoring can inform decisions, but sole reliance is risky because supplier performance data is often partial, lagged, or context-dependent.

    • Cybersecurity or access-control exceptions affecting production or technical data. AI can detect abnormal behavior, but granting sensitive access or waiving controls should remain governed and reviewable.

    What AI can do safely if controlled well

    AI is often useful for recommendation, triage, detection, summarization, pattern finding, document comparison, and evidence retrieval. Those uses can reduce manual effort without transferring accountability.

    A practical rule is this: AI may prepare, rank, or suggest. A qualified person should still decide when the outcome affects conformity, traceability, release status, or risk acceptance.

    Why full automation breaks down in real plants

    In brownfield aerospace environments, decisions are rarely made from one clean data source. Evidence is spread across MES, ERP, PLM, QMS, spreadsheets, email, supplier portals, and machine or inspection systems. Data may be late, inconsistent, or missing lineage. Under those conditions, an AI decision can look confident while resting on incomplete or stale inputs.

    There is also a validation problem. If an AI model influences a controlled production decision, you typically need a defined intended use, test coverage, version control, monitoring, change management, and a way to explain or at least reconstruct why a recommendation was made. That burden grows quickly in regulated, long-lifecycle programs.

    This is one reason full replacement strategies often fail. Replacing MES, QMS, or established approval workflows with AI-first decisioning can trigger qualification burden, integration rewrites, retraining, downtime risk, and gaps in traceability. In many aerospace settings, coexistence is safer: keep system-of-record controls and human approvals, and add AI around them for analysis and throughput support.

    Use a risk-based boundary, not a blanket ban

    The better question is not whether AI should be used. It is where decision authority stops.

    • Low risk, reversible, high-volume tasks are better candidates for automation.

    • High consequence, low frequency, exception-heavy decisions are poor candidates for full automation.

    • If the decision creates or changes quality evidence, product status, approved process definition, or risk ownership, keep a human approver.

    • If the underlying data is fragmented or weakly governed, limit AI to assistance, not authority.

    So the short answer is: any aerospace production decision that determines conformity, release, deviation acceptance, or accountable risk should not be fully automated by AI. AI can support those workflows, but should not be the final unsupervised decision-maker.

  • Which AS9100 clauses specifically address control of non-conforming products?

    The primary clause is AS9100 clause 8.7, Control of nonconforming outputs. That is the clause that directly addresses how an organization identifies, contains, evaluates, disposes of, and records nonconforming product or process output.

    That said, if you are asking what clauses auditors and quality teams usually look at in connection with nonconforming product, the answer is broader than 8.7 alone.

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    Core clause

    • 8.7 Control of nonconforming outputs: This is the specific requirement for preventing unintended use or delivery of nonconforming product, defining disposition, obtaining required approvals where applicable, and retaining evidence of the nonconformity and resulting actions.

    Closely related clauses

    • 8.5.2 Identification and traceability: Relevant when affected parts, lots, serial numbers, or assemblies must be identified, segregated, and traced through rework, scrap, return, or concession workflows.
    • 8.5.1 Control of production and service provision: Relevant because nonconformance control depends on controlled execution methods, hold points, status visibility, and prevention of unintended processing.
    • 8.6 Release of products and services: Important because nonconforming product must not be released without the required review, authorization, and records.
    • 9.1.1 Monitoring, measurement, analysis and evaluation: Inspection and test results often trigger the nonconformance process, so weak measurement controls can undermine clause 8.7 execution.
    • 10.2 Nonconformity and corrective action: This is related but not identical. Clause 8.7 is about controlling the specific nonconforming output. Clause 10.2 is about investigating causes and preventing recurrence when corrective action is warranted.
    • 7.5 Documented information: Required records, disposition evidence, approvals, and revision-controlled procedures sit here.
    • 8.4 Control of externally provided processes, products and services: Relevant when the nonconformance originates at a supplier or outside processor and must be contained across organizational boundaries.

    Important distinction

    If your question is whether AS9100 has one clause that fully covers NCR, MRB, rework, scrap, deviation, concession, and corrective action end to end, the practical answer is no. Clause 8.7 is the anchor, but an effective nonconformance process usually spans multiple clauses and multiple systems.

    In brownfield operations, that often means the nonconformance record may begin in MES or inspection software, disposition may involve QMS or MRB workflows, traceability may depend on ERP or genealogy records, and release controls may sit elsewhere again. If those handoffs are weak, you can meet the wording of a procedure on paper while still having real execution gaps on the floor.

    What organizations usually need to show

    • Clear identification of nonconforming product or output
    • Containment to prevent unintended use or shipment
    • Defined disposition paths such as rework, repair if allowed, scrap, return, or acceptance under authorized concession or deviation where applicable
    • Appropriate approval authority for disposition
    • Records of the nonconformity, actions taken, and resulting decisions
    • Traceability to affected part numbers, lots, serial numbers, work orders, or assemblies as needed
    • Reverification after rework or correction before release

    How much of this is manual versus system-enforced depends heavily on process maturity, integration quality, and validation discipline. In regulated aerospace environments, full rip-and-replace strategies often fail because nonconformance handling is entangled with legacy ERP, MES, PLM, QMS, supplier portals, and customer-specific requirements. Replacing everything at once can increase validation effort, downtime risk, and traceability gaps rather than reduce them.

    So the short answer is: 8.7 is the specific clause, but in practice you should also review 8.5.1, 8.5.2, 8.6, 8.4, 9.1.1, 10.2, and 7.5 to understand how nonconforming product is actually controlled in an operating system.

  • What documentation does AS9100 require for non-conformance and corrective actions?

    AS9100 requires documented information, but not a single mandated template, for both nonconformities and corrective actions. In practice, you need records that show the issue was identified, contained or controlled, dispositioned appropriately, investigated when necessary, corrected, and reviewed for effectiveness where corrective action is required.

    For nonconformity management, organizations commonly maintain records such as:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • identification of the nonconformity, including what failed and where it was found
    • product, part, batch, serial, lot, work order, or process traceability needed to define scope
    • containment or segregation actions to prevent unintended use or shipment
    • evaluation of the nonconformity, including impact, severity, and whether other product or processes may be affected
    • disposition decisions such as rework, repair, use-as-is if allowed by your process and approvals, return to supplier, or scrap
    • authority for the disposition and evidence of review where required
    • verification that dispositioned product met requirements before release, if reworked or otherwise corrected

    For corrective action, the records usually need to show:

    • the source of the issue, such as NCRs, escapes, audit findings, customer complaints, supplier issues, or recurring internal failures
    • the problem definition and scope
    • root cause analysis or other cause evaluation appropriate to the significance of the issue
    • the action plan, including responsibilities and timing
    • implementation evidence
    • review of effectiveness after implementation
    • updates to risk, training, procedures, work instructions, inspection plans, or controls if those changes were part of the response

    What AS9100 expects in detail depends on the clause involved, the seriousness of the issue, customer requirements, and your own documented QMS processes. Not every nonconformance requires a full corrective action record. Many can be handled through nonconformance control and disposition alone. Corrective action is generally expected when the issue is systemic, recurrent, escaped to the customer, or indicates process control weakness.

    What AS9100 does not do

    AS9100 does not guarantee that one form, software workflow, or naming convention will satisfy every auditor or customer. It also does not remove the need for your organization to define who can disposition product, when MRB review is required, how root cause is determined, what triggers CAPA, and how effectiveness is verified. Those decisions must be controlled in your QMS and followed consistently.

    Common documentation expectations in real plants

    In regulated and long lifecycle environments, the record set often extends beyond a basic NCR and CAPA form. You may need links to affected travelers, inspection results, supplier records, concession or deviation records, training changes, document revisions, and evidence of release control. If your plant runs mixed systems, this evidence may be split across QMS, ERP, MES, PLM, and email or paper attachments. That is common, but it increases retrieval effort, audit friction, and the risk of incomplete traceability.

    Full replacement of legacy quality or execution systems is often not realistic just to improve NCR and CAPA documentation. In brownfield aerospace environments, replacement can fail because of validation burden, downtime risk, integration complexity, qualified process impacts, and the amount of historical traceability that must remain accessible. A more practical approach is often to tighten workflow controls, authority rules, and cross-system record linkage before attempting major platform changes.

    Minimum practical answer

    If you want the shortest accurate answer: AS9100 requires documented evidence that nonconforming outputs are controlled and that corrective actions, when needed, address causes and are reviewed for effectiveness. The standard expects traceable records, but the exact documents, fields, approvals, and system locations are defined by your QMS, customer requirements, and operational setup.

    This is a quality system requirement, not a compliance guarantee. Whether your documentation is sufficient depends on process definition, discipline in execution, retention practices, and whether records can be retrieved and defended consistently.