Connect981 – Content Dev

FAQ Tag: master data

  • 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.

  • How do NCRs relate to corrective and preventive actions (CAPA) in aerospace quality systems?

    No. An NCR is not the same as a CAPA, and in most aerospace quality systems not every NCR should automatically become a CAPA.

    An NCR documents a detected nonconformance: what failed, where it was found, what product or process was affected, and what immediate controls were taken such as containment, segregation, rework evaluation, scrap, or escalation for review. Its main purpose is product and record control.

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

    CAPA is the broader problem-solving and control process used when the issue is significant enough to require formal root cause analysis, action planning, implementation, effectiveness verification, and documented change control. Its main purpose is to prevent recurrence of the same problem and reduce the chance of similar failures elsewhere.

    How they typically relate

    In practice, an NCR is often the event record that can feed a CAPA decision. A common flow is:

    1. A nonconformance is detected and logged as an NCR.
    2. The affected material, part, assembly, or record is contained and dispositioned through the defined quality process.
    3. The organization reviews the NCR for severity, repeat occurrence, escape risk, customer impact, process weakness, and trend signals.
    4. If the review shows a systemic issue or meaningful risk, the NCR is escalated into a CAPA or linked to an existing CAPA.
    5. The CAPA then manages root cause, corrective actions, implementation evidence, effectiveness checks, and any resulting document, process, or training changes.

    That distinction matters because you can close an NCR after the specific nonconforming item is controlled, while the linked CAPA may stay open much longer until the organization has evidence that the underlying issue was actually addressed.

    When an NCR should trigger CAPA

    That depends on your procedures, risk criteria, and regulatory or customer context, but common triggers include:

    • Repeated NCRs with the same or closely related cause
    • Major escapes to a downstream operation, customer, or field environment
    • Evidence that the problem is systemic rather than isolated
    • Breakdown in procedures, training, inspection strategy, tooling control, or data integrity
    • High-risk product characteristics or special process concerns
    • Supplier nonconformances that indicate persistent control failure

    By contrast, a one-off NCR with a clearly isolated cause may not justify a standalone CAPA if the issue can be resolved through normal correction, documented disposition, and local process correction within approved controls.

    Important tradeoffs

    Opening CAPA on every NCR usually creates noise, backlog, weak investigations, and delayed closure without improving quality. Not opening CAPA when a pattern is emerging creates the opposite risk: repeated defects, poor learning, and weak evidence that the system is controlling recurrence.

    The practical challenge is thresholding. If the criteria are too loose, the system becomes administrative. If they are too strict, real systemic failures stay buried inside isolated NCR records. Mature organizations define escalation rules, ownership, timing, and evidence requirements clearly so the handoff from NCR to CAPA is consistent and auditable.

    System and data considerations

    In brownfield aerospace environments, NCR and CAPA records often sit across QMS, MES, ERP, PLM, and sometimes supplier portals. That creates real failure modes:

    • The NCR is closed in one system, but the CAPA remains unlinked in another.
    • Disposition, rework, or concession decisions are not tied back to the root cause record.
    • Revision changes in work instructions or inspection plans are implemented without clear traceability to the CAPA.
    • Trend analysis is weak because defect codes, locations, and causes are inconsistent across plants or suppliers.

    So while the process relationship is conceptually straightforward, execution depends heavily on data discipline, workflow design, and integration quality. Full replacement of legacy quality and execution systems is often not realistic in aerospace because of validation cost, qualification burden, downtime risk, and existing system dependencies. In many plants, the safer path is controlled coexistence with better record linkage, governed master data, and clearer evidence trails.

    For aerospace quality systems, the safest general rule is this: use the NCR to control and document the specific nonconformance, and use CAPA when the facts show the need for systemic corrective action and effectiveness verification.

  • How does Connect 981 differ from a traditional QMS for managing NCRs?

    Usually, the difference is this: a traditional QMS is centered on controlled quality records, formal workflows, and documentable evidence, while Connect 981 is typically used to improve how NCR work is executed on the shop floor and across connected operations.

    That does not mean Connect 981 automatically replaces a QMS. In regulated manufacturing, it often coexists with the QMS, MES, ERP, and sometimes PLM. Which system owns the NCR record, approvals, disposition steps, attachments, and downstream actions depends on your process design, integration quality, and validation approach.

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

    Practical difference

    • Traditional QMS: Usually focused on governance, controlled workflows, approvals, CAPA linkage, audit trails, and quality records management.

    • Connect 981: Usually focused on operational execution, contextual data capture, routing, role-based work coordination, and connecting NCR activity to production, inspection, materials, and operator workflows.

    So if your question is whether Connect 981 is “the same thing” as a QMS for NCRs, the answer is no.

    It is better understood as an execution-oriented layer that can make NCR handling faster, more traceable, and more connected to real plant activity, assuming the implementation is done well. A traditional QMS, by contrast, is usually where organizations anchor formal quality governance and retained evidence.

    What changes in practice

    Compared with a conventional QMS-only NCR process, Connect 981 may help with:

    • capturing nonconformance details closer to the point of occurrence

    • linking NCRs to work orders, travelers, parts, operations, or inspection events

    • routing actions across production, quality, engineering, and supplier workflows

    • improving visibility into rework, hold status, bottlenecks, and aging NCRs

    • reducing manual re-entry between paper, spreadsheets, email, and disconnected enterprise systems

    Those are operational advantages, not compliance guarantees. If the underlying data is incomplete, the process is inconsistent, or integrations are weak, a connected workflow can still produce bad records faster.

    Where the boundary matters

    The important question is not whether Connect 981 or the QMS is “better” in the abstract. It is which system should own each part of the NCR lifecycle.

    For example, some organizations keep:

    • initial capture and shop floor containment in Connect 981

    • formal quality review, disposition approval, and CAPA linkage in the QMS

    • inventory and cost effects in ERP

    • drawing or specification references in PLM or document control systems

    Others may consolidate more steps into a single platform, but that is harder in brownfield environments. Full replacement strategies often fail where equipment, workflows, and quality systems have been qualified over many years. The burden is not just software migration. It includes validation effort, retraining, integration rewrites, downtime risk, record continuity, and change control across regulated processes.

    Tradeoffs and limits

    Using Connect 981 for NCR management can improve execution, but it also introduces design decisions and risks:

    • Integration dependency: If ERP, MES, QMS, and supplier systems are not well connected, users may still duplicate data or work from conflicting statuses.

    • Ownership ambiguity: If system-of-record rules are unclear, audit trails and decision accountability can become fragmented.

    • Validation burden: Any workflow that affects controlled records, approvals, or traceability may require formal validation and disciplined change control.

    • Process maturity limits: Software will not fix weak disposition rules, inconsistent MRB practices, or poor root cause discipline.

    • Adoption risk: If operators and quality staff find the workflow slower than current practice, workarounds will appear quickly.

    So the real difference is not only feature-level. It is architectural and operational. A traditional QMS manages formal quality control structures. Connect 981 is more useful when the problem is delayed capture, disconnected plant execution, poor handoffs, or weak visibility around NCR flow.

    In many regulated operations, the strongest approach is coexistence: keep the QMS where it is already entrenched as the controlled quality backbone, and use Connect 981 to close execution gaps around NCR creation, triage, traceability, and follow-through. Whether that is viable depends on your interfaces, master data quality, workflow governance, and willingness to define clear system boundaries.

  • What are signs that a CAPA is not addressing the true root cause?

    Yes. There are usually observable signs that a CAPA is treating symptoms instead of the true root cause.

    A CAPA is often off target when the corrective action closes the immediate event but the same problem, or a close variant of it, returns under normal operating conditions. In regulated manufacturing, this can remain hidden for a while if closure is based on paperwork completion rather than verified process performance.

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

    Common signs the root cause has not been addressed

    • The issue recurs in the same area or migrates elsewhere. Repeat nonconformances, audit findings, escapes, deviations, or rework patterns are the clearest warning. The exact symptom may change, but the failure mechanism is often still present.

    • The action is mostly retraining, reminders, or procedural reinforcement. Training may be necessary, but by itself it is often a weak corrective action if the real problem is unclear work instructions, poor fixture design, wrong system data, uncontrolled variation, workload pressure, or missing error-proofing.

    • The stated cause is generic. Phrases like “operator error,” “human error,” “lack of attention,” or “procedure not followed” are usually incomplete unless the CAPA explains why the process allowed that error and what changed to prevent recurrence.

    • The investigation does not reconcile conflicting evidence. If scrap, inspection, maintenance, supplier, and production records tell different stories and the CAPA chooses one without resolving the conflict, the cause may be assumed rather than demonstrated.

    • Containment is mistaken for correction. Sorting inventory, adding extra inspection, or holding shipments may reduce immediate risk, but those actions do not remove the underlying process failure.

    • Effectiveness checks are weak or too short. If effectiveness is verified only by task completion, a single clean lot, or a short observation period, the CAPA may close before enough evidence exists to show sustained improvement.

    • The action does not match the failure mode. For example, if the issue is caused by revision control, master data mismatch, equipment drift, or supplier variability, a local SOP update alone is unlikely to be sufficient.

    • Only one function is involved in a cross-functional problem. Many root causes sit across quality, manufacturing engineering, maintenance, planning, IT, supplier quality, and document control. A CAPA owned by one group without input from the others often misses system interactions.

    • Metrics improve briefly, then regress. Short-term improvement followed by backsliding often means the process depended on attention and urgency, not on a durable control.

    • There is no clear causal chain from evidence to action. A sound CAPA should show how observed facts support the root cause and why the selected action should prevent recurrence. If that chain is missing, closure may be administrative rather than technical.

    • Known system constraints are ignored. If operators still work around MES prompts, paper travelers, ERP master data errors, equipment limitations, or supplier documentation gaps, the CAPA may not have touched the real source of failure.

    What a stronger CAPA usually includes

    A stronger CAPA usually has three features: evidence, mechanism, and verification.

    • Evidence: The investigation uses actual records, trend data, genealogy, device history, revision history, calibration status, and process observations, not just interviews.

    • Mechanism: The root cause explains how the failure happened, not just who was present when it happened.

    • Verification: Effectiveness checks look for sustained prevention across enough time, lots, shifts, products, or suppliers to be meaningful.

    That said, the standard of evidence depends on process complexity, product risk, event severity, and data quality. Some plants have strong traceability and event history; others are still reconciling paper, spreadsheets, and disconnected systems. That affects how confidently root cause can be proven.

    Brownfield reality

    In mixed legacy environments, CAPA failures are often tied to fragmented evidence. The real issue may sit between systems: ERP item data, MES routing logic, PLM revisions, QMS records, maintenance logs, and supplier documents may not align. In that situation, teams can close a CAPA on the most visible symptom because the full evidence trail is slow to assemble or not trusted.

    That is one reason full replacement strategies often fail as a CAPA response in long-lifecycle regulated operations. Replacing MES, ERP, PLM, or QMS to fix one quality signal usually creates qualification burden, validation work, downtime risk, and new integration points. In many plants, targeted controls, better evidence linkage, and narrower process changes are more realistic than broad system replacement. Whether that is enough depends on the actual failure mechanism and the maturity of change control.

    Practical test

    If you want a simple check, ask four questions:

    1. Would this issue still happen if a different operator, shift, or supplier were involved?

    2. What process condition made the failure possible?

    3. What changed in the process or system to make recurrence less likely?

    4. What objective evidence will prove that over time?

    If the answers are vague, person-dependent, or based only on completion of tasks, the CAPA may not be addressing the true root cause.

  • How long should we monitor a process to verify CAPA effectiveness?

    There is no fixed number of days, weeks, or lots that fits every CAPA. You should monitor long enough to show that the problem has not only stopped temporarily, but remains controlled through normal operating variation.

    In practice, the monitoring period should be based on four things: how often the process runs, how serious the original issue was, how likely the failure mode is to recur, and how quickly your indicators would reveal regression. A high-volume process may produce enough evidence in days or weeks. A low-volume, high-mix, or seasonal process may require multiple runs, batches, work orders, or months to generate meaningful evidence.

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

    What is usually a defensible approach?

    Set the effectiveness period before closure, and define it in measurable terms. For example, monitor for a specified number of production cycles, lots, inspections, maintenance intervals, or calendar periods, with explicit acceptance criteria tied to the original failure mode.

    • For frequent, lower-risk processes: enough cycles or time to demonstrate the issue does not recur under routine conditions.

    • For infrequent or high-mix processes: enough comparable occurrences to show the corrective action works across realistic variation, not just one successful run.

    • For higher-risk issues: longer monitoring, tighter review, and often additional checks on adjacent processes, training, documentation, and data integrity.

    If the CAPA addressed a systemic cause, not just a local defect, the monitoring scope should also be systemic. For example, if the root cause involved routing control, revision control, supplier data, inspection logic, or training records, effectiveness cannot be verified only by checking one workstation or one lot.

    How do you know the period is long enough?

    A monitoring period is usually long enough when all of the following are true:

    • The process has run enough times to expose normal variation.

    • The original problem indicators remain within the expected range.

    • No related escape, recurrence, or compensating workaround appears elsewhere.

    • Required procedural, system, and training changes are actually in use, not just approved on paper.

    • The evidence is traceable and reviewable.

    If your process data is weak, delayed, manually compiled, or fragmented across MES, ERP, QMS, spreadsheets, and inspection systems, you may need a longer period because the signal is less reliable. Monitoring duration is partly a data-readiness issue, not just a calendar issue.

    Common mistakes

    • Closing the CAPA after one clean batch or one audit with no recurrence.

    • Using a calendar-based window that is too short for a low-frequency process.

    • Tracking only the original defect count and ignoring rework, scrap, deviations, operator overrides, or inspection burden that may hide the problem.

    • Failing to confirm that changes in work instructions, master data, training, or system rules were deployed consistently.

    • Treating software configuration changes as instantly effective without checking integration behavior and exception handling.

    Brownfield reality

    In many plants, CAPA effectiveness monitoring depends on evidence pulled from multiple legacy and newer systems. That can work, but only if ownership, mappings, and change control are clear. Full replacement of QMS, MES, ERP, or inspection systems is usually not the practical answer just to improve CAPA monitoring. In regulated, long-lifecycle environments, replacement often fails or stalls because of validation effort, qualification burden, downtime risk, integration complexity, and traceability requirements. A narrower approach is usually more realistic: define the evidence sources, close data gaps, and validate the reporting logic used for effectiveness checks.

    So the short answer is: monitor until you have enough traceable evidence to show sustained control for the specific failure mode under real operating conditions. For some CAPAs that may be a few weeks. For others it may be several production cycles, multiple lots, or a much longer period. If you cannot explain why the chosen window is sufficient, it probably is not.

  • Who should have authority to approve scrap, repair, or concession dispositions?

    It should be approved by the roles formally designated in your quality system and product governance process, not by whoever discovered the issue or whoever is under the most schedule pressure.

    In practice, that usually means:

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

    • Scrap: often approved by authorized quality personnel, and sometimes operations leadership as well, if the part is clearly non-recoverable and local procedures allow it.
    • Repair: typically requires engineering authority in addition to quality review, because repair changes how the product is brought back to an acceptable condition and may affect form, fit, function, reliability, or future maintenance.
    • Concession or use-as-is: usually requires a formal review board or delegated authority that includes quality and engineering, and may also require customer or design authority approval depending on contract terms, product criticality, and whether the nonconformance affects requirements.

    The short answer is: authority should follow documented delegation, competency, and risk classification, with clear evidence of who approved what and under which procedure.

    What should not happen

    Operators, supervisors, planners, or buyers should not independently approve repair or concession dispositions unless your controlled procedures explicitly delegate that authority and the individuals are qualified to exercise it. In regulated environments, informal approvals create obvious traceability and change control problems, and they can invalidate downstream assumptions in inspection, genealogy, costing, and customer reporting.

    It is also risky to assume that scrap is always a simple local decision. Scrap may trigger material accountability, customer notification, supplier recovery, serialized asset updates, or impact analysis for work orders already linked in MES, ERP, PLM, or QMS.

    What determines the right approval model

    • Product criticality and safety significance
    • Whether the disposition changes design intent or process intent
    • Customer, contract, or design authority requirements
    • Internal delegation rules in the QMS
    • Competency and training records for approvers
    • Whether the item is serialized, traceable, or already installed in a higher-level assembly
    • System capability to enforce routing, signatures, and evidence retention

    If these conditions are not well defined, approval authority becomes inconsistent across shifts and sites. That is a governance problem, not just a workflow problem.

    Brownfield system reality

    In many plants, the actual approval path is split across QMS, MES, ERP, email, and engineering records. That is common, but it increases the chance of mismatched statuses, missing signatures, and weak evidence trails. A digital workflow can help enforce role-based approvals, but only if master data, role mapping, and system integrations are reliable.

    Full replacement of legacy quality or execution systems is often not the practical answer. In regulated, long-lifecycle environments, replacement can fail because of validation effort, qualification burden, downtime risk, integration complexity, and the need to preserve historical traceability. More often, the workable approach is to tighten disposition authority rules and connect existing systems well enough that approvals, records, and status changes remain synchronized.

    Practical rule

    If a disposition could affect product acceptance, configuration, traceability, customer obligations, or future airworthiness or serviceability decisions, approval should sit with authorized quality and engineering functions under controlled procedures, with escalation to customer or design authority where required.

    If your process cannot show who had authority, what evidence they reviewed, and which system became the system of record, then the approval model is not mature enough yet.