Connect981 – Content Dev

RSC Sphere: Quality, Compliance and Traceability

The Quality, Compliance and Traceability Sphere demonstrates how audit-grade credibility is built directly into execution workflows. It connects nonconformance, corrective action, inspection, traceability, and audit evidence into a continuous operational loop. The content emphasizes how quality systems must interact with live work rather than exist as parallel documentation processes. This sphere proves that compliance and execution can reinforce each other instead of competing for attention.

  • SHAP

    Core meaning

    SHAP (SHapley Additive exPlanations) is a family of model-agnostic techniques for explaining individual predictions of machine learning models by assigning each input feature a contribution value. These values are based on Shapley values from cooperative game theory, adapted to quantify how much each feature “adds” to the model output relative to a baseline.

    In practice, SHAP produces:

    – A per-feature contribution for a single prediction (local explanation)
    – Aggregated statistics across many predictions to show global feature importance patterns

    SHAP is used with many model types (tree-based, linear, neural networks) through different algorithmic variants, but the underlying principle is always to decompose the model output into a sum of feature contributions plus a baseline.

    Use in industrial and MES-related workflows

    In industrial operations and MES-integrated AI, SHAP is commonly used to:

    – Explain why an AI model predicted a specific quality outcome (e.g., high defect risk for a batch)
    – Show which process parameters most influenced a recommended setpoint or scheduling decision
    – Support human review of AI-assisted decisions in regulated environments by providing traceable, numerical feature contributions
    – Generate documentation or visualizations for engineering, quality, or validation teams to understand model behavior across historical production data

    For example, an AI model that predicts line downtime risk can be accompanied by SHAP values that quantify how recent maintenance history, current throughput, and environmental conditions each contributed to a given risk score.

    What SHAP includes and excludes

    SHAP includes:

    – A mathematical framework (additive feature attribution) grounded in Shapley values
    – Algorithms and tools that approximate these attributions for different model classes
    – Visualizations such as force plots, summary plots, and dependence plots derived from SHAP values

    SHAP does not include:

    – The underlying predictive model itself (it explains a model; it is not the model)
    – Data governance, validation, or change control processes
    – A full “explainability framework” on its own; it is one technical method within a broader explainability and oversight approach

    Common variants and implementations

    Several SHAP implementations are used in practice:

    – **Tree SHAP** for tree-based models such as gradient boosting and random forests
    – **Kernel SHAP** as a model-agnostic approximation suitable for many black-box models
    – **Deep SHAP** for certain neural network architectures

    Tooling is frequently accessed through open-source libraries that compute SHAP values and generate visual explanations, often integrated into data science notebooks or model monitoring dashboards.

    Site-context application: explainable and trustworthy AI with MES

    Within the context of AI models used alongside MES, SHAP is one of the technical explainability methods applied to:

    – Provide human-in-the-loop operators, engineers, and quality reviewers with a transparent breakdown of model recommendations
    – Support documented justification for model behavior during validation, periodic review, or investigations
    – Help detect shifts in model behavior over time by monitoring changes in feature attribution patterns

    In this setting, SHAP contributes to explainability but must be combined with clear use-case boundaries, data lineage documentation, model validation, and operational controls to support trustworthy use of AI in production environments.

    Related concepts and potential confusion

    – **Shapley values**: The game-theoretic concept SHAP builds on; SHAP operationalizes these for ML model explanations.
    – **Feature importance**: SHAP provides a consistent, theoretically grounded form of feature importance. Other methods (e.g., permutation importance, model-specific scores) may give different results and are not interchangeable.
    – **Global vs local explanations**: SHAP can be used for both, but its primary construct is local (per-prediction) attribution that can then be aggregated.

    SHAP is not the same as general “AI transparency” or “auditability”; it is a specific technique used to support those broader goals.

  • Quality Management System (QMS)

    A Quality Management System (QMS) is the formal, organization-wide set of policies, procedures, processes, roles, and records used to plan, control, and continually improve quality. It provides a structured way to define how products and services are specified, produced, inspected, released, and improved, and how compliance with applicable regulations and standards is documented.

    Core elements of a QMS

    Although implementations differ by industry and standard, most QMS implementations in manufacturing include:

    • Quality policy and objectives: Documented intent and measurable goals for quality and compliance.
    • Document and record control: Governance for creating, approving, revising, distributing, and retaining controlled documents and quality records.
    • Process definitions: Standard operating procedures (SOPs), work instructions, and workflows that describe how work is done and controlled.
    • Risk and change management: Methods to assess risk, manage changes to products, processes, equipment, and software, and evaluate their impact on quality.
    • Nonconformance and CAPA: Processes for identifying defects or deviations, investigating root causes, and implementing corrective and preventive actions.
    • Training and competency: Procedures to define required competencies, train personnel, and maintain training evidence.
    • Internal audits and management review: Periodic checks and leadership reviews to verify that the QMS is implemented, effective, and aligned with business and regulatory needs.
    • Supplier and incoming quality management: Controls over suppliers, materials, and external services.
    • Continuous improvement: Structured use of metrics, feedback, and lessons learned to refine processes and reduce quality risk.

    QMS in industrial and regulated environments

    In industrial operations, the QMS typically spans both operational technology (OT) and information technology (IT) systems. It often connects to or is implemented using digital systems such as:

    • MES and production systems for enforcing process controls, collecting in-process data, and managing electronic batch or route records.
    • ERP and supply chain systems for managing specifications, purchasing controls, and release status.
    • Electronic QMS software for managing documents, training, deviations, complaints, CAPA, audits, and change control.
    • Data and analytics tools for monitoring quality metrics, scrap, rework, and cost of poor quality.

    In regulated manufacturing sectors, the QMS is often structured to align with applicable standards or regulations. These may specify expectations for quality processes, documentation, and objective evidence, but the QMS itself is the organization’s system for meeting those expectations, not the standard or regulation.

    Operational meaning

    At an operational level, a QMS shows up as:

    • The controlled procedures and work instructions that operators follow on the shop floor.
    • The workflows used to log nonconformances, deviations, and out-of-spec events.
    • The approval and review steps required for process changes, new equipment, or software updates.
    • The checklists, forms, and electronic records used to demonstrate that defined quality controls were executed.
    • The audit trails, version history, and training records used during internal and external audits.

    Common confusion

    • QMS vs. QMS software: QMS software is a tool that supports parts of the QMS (such as CAPA, document control, or training). The QMS itself is broader and includes people, processes, governance, and records, whether managed on paper, electronically, or both.
    • QMS vs. certification: Having a QMS is not the same as having a certification to a quality standard. Certifications, where applicable, usually attest that an independent body has evaluated a QMS against defined criteria. The QMS is the underlying system being evaluated.
    • QMS vs. quality control (QC): QC refers to inspections and tests performed on materials, in-process product, or finished goods. A QMS includes QC but also defines how quality is planned, prevented, documented, and improved across the lifecycle.

    Tie to Industry 4.0 discussions

    In Industry 4.0 initiatives, the QMS is often a central reference for determining what data must be captured, which workflows need to be digitized, and which records must be retained as evidence. Digital or automated quality tools do not replace the QMS; they are configured to align with and support the existing or updated QMS so that regulatory and audit expectations continue to be met.

  • clause 4.3

    In the context of ISO 9001:2015, clause 4.3 is the requirement that an organization determine and document the scope of its quality management system (QMS). It describes what parts of the organization, which products and services, and which activities are covered by the QMS.

    What clause 4.3 covers

    Clause 4.3 commonly refers to the requirement to:

    • Define the boundaries and applicability of the QMS for the organization.
    • Consider internal and external issues, relevant interested parties, and the organization’s products and services when setting the scope.
    • Identify which requirements of ISO 9001 are applicable and justify any that are not applicable.
    • Maintain a documented statement of the QMS scope and ensure it is available and controlled.

    In industrial and regulated manufacturing environments, this usually appears as a written QMS scope statement describing which sites, business units, product lines, and support functions (for example design, purchasing, production, and service) are included.

    Operational meaning in manufacturing

    For manufacturers, clause 4.3 typically affects:

    • Certification boundaries: Which plants, operations, or services are included in an ISO 9001 certificate.
    • Process coverage: Whether functions such as design and development, calibration, maintenance, or contract manufacturing are within the QMS.
    • System integration: How MES, ERP, PLM, and quality systems are treated in scope for documented processes, controls, and records.
    • Evidence for audits: The documented QMS scope that auditors use to judge applicability of individual ISO 9001 requirements.

    Link to exclusions and applicability

    Clause 4.3 is often referenced when an organization determines that certain ISO 9001 requirements are not applicable. A common example is clause 8.3 on design and development where an organization performs only build-to-print manufacturing. In such cases, clause 4.3 requires that the organization:

    • Justify why the requirement does not apply based on the nature of its products and services.
    • Ensure that any non-applicable requirement does not affect the organization’s ability to provide conforming products and services or to enhance customer satisfaction.

    Common confusion

    • Clause 4.3 vs. certification scope statement: The clause 4.3 requirement leads to a documented scope, but the certificate issued by a third party may summarize or format that scope differently. The internal QMS scope must still meet all clause 4.3 requirements.
    • Clause 4.3 vs. exclusions list: Clause 4.3 is broader than a list of excluded requirements. It establishes overall QMS boundaries first, and only then supports decisions about which specific ISO 9001 requirements are not applicable within that scope.

    Use in audits and compliance discussions

    In audits or compliance reviews, clause 4.3 is used to confirm that the QMS scope is clearly defined, matches the organization’s actual activities, and provides a sound basis for judging whether all applicable ISO 9001 requirements are addressed. It is not a mechanism to selectively avoid requirements, but a structured way to align QMS coverage with the organization’s real operational context.

  • MRB

    Core meaning

    MRB commonly refers to the **Material Review Board**: a formal, cross‑functional team and process used to evaluate and disposition nonconforming material, parts, or product.

    In industrial and especially regulated manufacturing environments, MRB is both:

    – **An organizational body** (the board or team)
    – **A controlled process** (the workflow and records used to review and disposition nonconformances)

    Typical composition and scope

    An MRB typically includes representatives from:

    – Quality assurance / quality engineering
    – Manufacturing or operations engineering
    – Production / shop floor supervision
    – Design or product engineering (for form/fit/function decisions)
    – Supply chain or purchasing (for supplier‑related issues)

    The MRB process generally covers:

    – Review of nonconformances or defects
    – Technical assessment of risk to safety, performance, or compliance
    – Determination of allowed **dispositions** (e.g., rework, repair, use‑as‑is with justification, scrap, return to supplier)
    – Documentation and approval of the decision with traceability
    – Feedback into corrective and preventive actions (CAPA), change control, or supplier management

    MRB process in operations

    Within day‑to‑day operations, MRB is typically triggered when a part, assembly, batch, or document:

    – Fails inspection or test
    – Deviates from drawing, specification, or defined process
    – Is suspected to be nonconforming due to supplier notification or internal investigation

    In many plants, an MRB record or ticket is created in a quality management system (QMS), MES, or ERP, then routed for review. The MRB team evaluates:

    – Nonconformance description and classification
    – Affected configuration or serial numbers
    – Applicable requirements (drawings, specifications, procedures)
    – Historical occurrences and similar MRB cases

    The outcome is a documented disposition and, when appropriate, linkage to:

    – Deviation/waiver requests
    – Engineering change requests
    – Root cause analysis and CAPA
    – Supplier corrective action

    Boundaries and exclusions

    When used in this manufacturing context, **MRB does not refer to**:

    – General quality review meetings that do not include formal nonconformance disposition authority
    – Safety review boards or risk committees, unless they are explicitly chartered as the MRB for nonconforming material
    – Financial or budgeting “review boards” unrelated to material nonconformances

    Some organizations also use “MRB” informally to describe the **physical location** where nonconforming material is quarantined and held for review. Strictly speaking, this is shorthand; the core concept is the **governed review and disposition process**.

    Common confusion

    MRB is often confused with or conflated with related concepts:

    – **NCR (Nonconformance Report)**: the record that describes a nonconformance. The NCR is usually **input** to MRB; the MRB decision is the **output**.
    – **CAPA (Corrective and Preventive Action)**: the structured problem‑solving process. MRB may **trigger** CAPA but is not itself a full CAPA process.
    – **Deviation / concession / waiver**: a controlled permission to depart from requirements. MRB decisions frequently rely on or create these, but they are distinct artifacts.

    In regulated industries, MRB authority and membership are often defined in procedures. Misuse of the term to describe ad‑hoc decisions without formal authority or documentation can cause confusion during internal or external reviews.

    Site context: MRB in MES, analytics, and risk

    In environments using MES and integrated quality systems, MRB events and records commonly appear as:

    – Nonconformance or quality hold transactions
    – Disposition codes (rework, repair, scrap, use‑as‑is)
    – Links between work‑in‑process, inspection results, and MRB decisions

    For operations intelligence and risk analysis (for example, analyzing aircraft availability or AOG risk), MRB data can be used to:

    – Quantify the frequency and severity of nonconforming material
    – Analyze typical rework and repair cycle times driven by MRB
    – Identify patterns where MRB decisions correlate with schedule slippage or downstream defects

    In such usage, MRB remains the formal decision process around nonconforming material; analytics consume its data but do not change its definition.

  • PFMEA

    PFMEA, or Process Failure Mode and Effects Analysis, is a structured method used to identify, analyze, and prioritize potential failure modes in a manufacturing or operational process before and during production. It focuses on how a process can fail to meet requirements, the effects of those failures on the customer or downstream operations, and the controls used to detect or prevent them.

    What PFMEA includes

    In regulated and industrial manufacturing environments, a PFMEA typically:

    • Maps process steps for a product or family of products
    • Lists potential failure modes at each step (for example incorrect torque, missing component, contamination, mislabeling)
    • Describes potential effects of each failure (for example safety issue, functional failure, scrap, rework, field return)
    • Identifies potential causes (for example operator error, machine instability, inadequate work instructions, incorrect parameter settings)
    • Documents existing prevention and detection controls (for example poka-yoke devices, MES checks, in-process inspection, automated test)
    • Assigns rankings for severity, occurrence, and detection to estimate risk priority
    • Defines and tracks actions to reduce risk (for example process redesign, updated control plans, additional checks, parameter limits enforced in MES)

    PFMEA is often maintained as a living document throughout the product and process lifecycle. It is typically linked to control plans, work instructions, change control, and electronic systems such as MES, QMS, and PLM.

    Use in automotive and other regulated industries

    In the automotive industry, PFMEA is a core element of advanced product quality planning (APQP) and is referenced by standards such as IATF 16949. It is used together with design FMEA (DFMEA) to manage risk from design through production. Similar approaches are used in aerospace, medical device, and other regulated manufacturing sectors, often with sector-specific formats and ranking schemes.

    What PFMEA is not

    • It is not the same as a design FMEA, which focuses on product design risk rather than process execution risk.
    • It is not a control plan, but PFMEA content is frequently used to create and update the control plan.
    • It is not, by itself, evidence of compliance or certification. It is one source of documented risk analysis within a broader quality management system.

    Operational role in manufacturing systems

    From a systems and OT/IT perspective, PFMEA information is commonly used to:

    • Drive requirements for in-process checks and interlocks in MES or SCADA
    • Define critical process parameters and alarms logged by automation systems
    • Inform sampling plans, inspection points, and test coverage in QMS or LIMS
    • Support change impact assessments when equipment, materials, or methods are modified
    • Prioritize data collection and analytics around high-risk failure modes

    Common confusion

    • PFMEA vs DFMEA: PFMEA addresses how the manufacturing or service process can fail. DFMEA addresses how the product design can fail to meet requirements. In many organizations they are linked, but they target different types of risk.
    • PFMEA vs risk register: A risk register is a general list of risks at project, program, or organizational level. PFMEA is a structured, step-by-step analysis of process risks with quantitative rankings specific to a defined process.

  • customer focus

    Customer focus is a quality management principle that prioritizes understanding, meeting, and monitoring customer needs and expectations throughout an organization’s operations. In industrial and regulated manufacturing environments, it typically means designing, controlling, and improving processes so that products and services consistently meet specified customer requirements and applicable regulations.

    What customer focus includes

    In manufacturing and industrial operations, customer focus commonly refers to:

    • Identifying explicit requirements, such as drawings, specifications, contracts, and regulatory constraints.
    • Understanding implicit expectations, such as reliability, delivery performance, and support responsiveness.
    • Translating requirements into controlled processes, work instructions, and system configurations (for example, in MES, ERP, and quality systems).
    • Monitoring customer satisfaction through complaints, returns, audit findings, scorecards, and other feedback mechanisms.
    • Using data from operations, quality, and service to adjust processes and prevent recurrence of issues that affect the customer.

    Customer focus applies to both external customers (end users, OEMs, contract customers) and, in many operational practices, internal customers (such as downstream processes or facilities that depend on accurate, timely outputs).

    Customer focus in regulated manufacturing

    In regulated environments, customer focus must coexist with compliance obligations. Organizations are expected to:

    • Ensure that meeting customer needs does not conflict with regulatory or safety requirements.
    • Capture and control customer-specific requirements in documents, specifications, and validated systems.
    • Maintain traceability and records that demonstrate how customer requirements are met.
    • Use structured processes, such as change control and risk assessment, when customer needs change.

    Operationally, this often shows up as integrated workflows between customer order entry, engineering, document control, MES, and quality management systems to keep requirements aligned with what is actually produced.

    Relation to ISO 9001

    Customer focus is one of the seven quality management principles commonly associated with ISO 9001. In that context, it underpins requirements for understanding customer needs, meeting applicable requirements, enhancing customer satisfaction, and using feedback to improve the quality management system. How it is implemented can differ by organization, but it typically influences policy, objectives, process design, and performance metrics.

    Common confusion

    • Customer focus vs. customer service: Customer service is usually the direct interaction with customers (support, help desk, account management). Customer focus is broader and covers how the entire organization designs and runs its processes with the customer in mind.
    • Customer focus vs. “the customer is always right”: In regulated or safety-critical manufacturing, customer focus does not mean accepting requests that conflict with standards, regulations, or internal risk controls. It means clearly explaining constraints and working within them to meet legitimate requirements.

  • repair

    Operational meaning in manufacturing

    In regulated manufacturing, **repair** commonly refers to actions taken on a nonconforming product or component to make it usable, **without fully restoring it to the original design intent, specification, or performance level**.

    Typical characteristics include:
    – The item remains **non-ideal** relative to the original specification, even if it is safe and functional for a defined use.
    – The action may involve **adding, patching, reinforcing, or modifying** the item.
    – The result often has **restrictions or limitations** on use, lifetime, environment, or performance compared with the original design.
    – Additional **documentation, justification, and approvals** are usually required, especially in regulated environments.

    In many quality systems, repairs are controlled via **nonconformance, deviation, or concession** processes and may require engineering review, risk assessment, and customer or regulatory notification, depending on impact.

    How repair is used in real workflows

    In industrial and regulated contexts, repair activities may include:

    – **Patching or reinforcing** a damaged area (e.g., adding a sleeve, bracket, or filler material) rather than replacing the whole part.
    – **Adding a modification** (e.g., a shim, spacer, or overlay) to make an assembly fit or function when it does not meet the original tolerance.
    – **Limiting use** after repair (e.g., reduced pressure rating, shorter service life, restricted operating range) documented on the traveler, label, or asset record.
    – **Repairing returned products** (field returns, warranty claims) where the solution does not completely return the unit to “as-new” specification but makes it acceptable for specific service or downgraded use.

    These repairs are typically captured in:
    – The **QMS** (nonconformance and CAPA records),
    – The **MES** or shop-floor system (routing steps, holds, approvals), and
    – **Asset or maintenance systems** for equipment and tooling repairs.

    Boundaries and exclusions

    In this manufacturing and quality context, repair **does include**:
    – Actions on **nonconforming product** or equipment intended to restore **basic usability or safety**.
    – Modifications that create a **de-rated or restricted-use** condition compared to the original design.

    Repair **does not necessarily include**:
    – Routine, planned **preventive maintenance** on in-spec equipment (that is usually called maintenance, not repair).
    – Full restoration of a product or asset to its **original specification and performance** using approved processes (that is often treated as rework or refurbishment, depending on context).

    Common confusion with rework and related terms

    In regulated manufacturing, repair is often contrasted with **rework**:

    – **Rework**: Uses the **original, approved manufacturing process** (or a pre-validated variant) to bring a nonconforming product **fully back into specification**, consistent with the original design intent.
    – **Repair**: Uses **alternative or additional actions** to make the product **usable**, but it **does not fully restore** the original specification or design intent and may impose **limits on use or performance**.

    Related distinctions:
    – **Scrap**: Nonconforming material that is not reworked or repaired and is removed from use.
    – **Refurbish / overhaul**: Broader restoration of used equipment or products to a defined condition, which may be “like new” or a specified service state, often after time in service rather than initial manufacturing.

    Using the term **repair** precisely is important for:
    – Correct classification of nonconformance actions in QMS and MES,
    – Appropriate **risk analysis and documentation**, and
    – Ensuring that any **use limitations** or de-ratings are clearly tracked and communicated.

    Site context: repair in regulated operations

    Within regulated industrial operations, repair decisions intersect with:

    – **Quality management**: Nonconformance handling, deviations, and approvals prior to release.
    – **Validation and qualification**: Assessing whether the repair changes validated conditions, critical parameters, or requires additional testing.
    – **Traceability and record-keeping**: Recording what was repaired, how, by whom, and under what authorization, often linked to serial numbers or batch records.
    – **Risk and safety management**: Evaluating how the repair affects hazards, failure modes, and allowable service conditions.

    In integrated MES/ERP/CMMS environments, repair events are often visible as specific **work orders, service orders, or nonconformance dispositions**, with clear distinction from rework, scrap, and standard maintenance activities.

  • IAQG

    IAQG stands for International Aerospace Quality Group. It is an industry group made up of aviation, space, and defense companies that collaborates to develop and maintain common quality management system requirements and supporting guidance for the aerospace sector.

    What IAQG does

    Within industrial and regulated manufacturing environments, IAQG is best known as the organization responsible for sponsoring and maintaining the AS9100 series of aerospace quality management system standards. These build on generic quality frameworks, such as ISO 9001, with sector-specific requirements for aviation, space, and defense production and services.

    IAQG activities commonly include:

    • Defining and updating aerospace quality management system standards (for example, AS9100, AS9110, AS9120).
    • Developing supporting standards and guidance for configuration management, software quality, and special processes in aerospace supply chains.
    • Providing common frameworks for oversight of certification bodies and audits related to IAQG standards.
    • Promoting harmonized quality expectations between prime contractors and their suppliers across regions.

    Operational relevance in manufacturing

    For manufacturers in the aviation, space, and defense sectors, IAQG standards often influence how quality management systems, MES, ERP, and document control processes are structured. Examples include:

    • Defining documented procedures and records required for production, inspection, and traceability under AS9100-based systems.
    • Shaping supplier quality requirements and flowdown clauses in purchase orders and technical data packages.
    • Informing audit checklists and internal assessment criteria used to evaluate plant operations against aerospace expectations.

    Scope and boundaries

    IAQG itself is not a regulatory authority and does not issue certifications. Instead, it publishes standards and guidance that are used by accredited certification bodies and by organizations implementing aerospace quality management systems. Adoption of IAQG standards is often driven by customer or contractual requirements in aviation, space, and defense markets.

    Common confusion

    • IAQG vs AS9100: IAQG is the group; AS9100 is one of the standards the group sponsors. An organization can be certified to AS9100, but it is not “certified to IAQG.”
    • IAQG vs ISO: IAQG develops aerospace sector standards that typically build on ISO frameworks (for example, ISO 9001). IAQG is not part of ISO, although its standards are designed to align with ISO structures where practical.