Connect981 – Content Dev

Glossary Tag: risk detection

  • Configuration versioning

    Configuration versioning is the practice of assigning identifiable versions to a system, application, device, process, or equipment configuration as it changes over time. It commonly refers to keeping a controlled history of settings, parameters, logic, mappings, templates, and other non-code configuration items so current and prior states can be identified and compared.

    In industrial and regulated environments, configuration versioning is used to understand what configuration was active at a given time, who changed it, when it changed, and what changed between versions. This can apply to MES rules, ERP integration mappings, PLC or SCADA parameters, electronic forms, work instruction settings, quality workflows, user-role configurations, and similar controlled setup data.

    Configuration versioning does not mean any change is automatically approved or released. It is about maintaining version identity and history. Approval workflows, change control, and document control may be related, but they are separate controls.

    What it typically includes

    • Version numbers, revision IDs, or other unique identifiers for a configuration state

    • Records of additions, removals, or edits to configuration items

    • Date, time, and user attribution for changes

    • Comparison between versions

    • Rollback or restoration to a prior known configuration, where supported

    • Linkage to deployment, release, or change records in broader governance processes

    Common confusion

    Configuration versioning is often confused with document version control and source code version control. Document version control applies to files such as SOPs, specifications, or controlled forms. Source code version control applies to software code. Configuration versioning focuses on operational settings and structured system behavior that may exist outside code files or formal documents.

    It is also distinct from a full audit trail. An audit trail may record every event or field-level change. Configuration versioning usually emphasizes named, recoverable configuration states and their revision history.

    Manufacturing context

    In manufacturing systems, configuration versioning commonly appears where system behavior must remain stable and explainable across production runs, quality events, or integration updates. Examples include versioned routing parameters in MES, revised inspection plan settings, changes to label templates, or updates to ERP-to-MES field mappings. The goal is to preserve a reliable record of which configuration was in effect for a given operation or period.

  • AI-assisted root cause analysis

    AI-assisted root cause analysis commonly refers to the use of artificial intelligence techniques to help investigate why a problem occurred in a process, system, or operation. In manufacturing and regulated environments, it is typically used to support analysis of deviations, nonconformances, downtime events, yield loss, alarm patterns, or recurring quality issues by finding patterns, correlations, sequences, or anomalies across available data.

    It is a support method, not the root cause itself and not a guarantee that the suggested cause is correct. The output is usually a ranked set of likely contributing factors, evidence links, or investigation leads that people review alongside process knowledge, documented procedures, and formal quality methods.

    What it usually includes

    • Analysis of data from MES, ERP, QMS, historians, CMMS, SCADA, LIMS, or maintenance logs

    • Pattern detection across events such as scrap spikes, machine faults, parameter drift, changeovers, or supplier-related defects

    • Use of machine learning, statistical models, rules, knowledge graphs, or generative AI to summarize evidence and propose likely causes

    • Tracing possible relationships among materials, equipment states, operators, work orders, batches, or process settings

    What it does not mean

    • It does not replace structured problem-solving methods such as 5 Whys, fishbone analysis, fault tree analysis, or formal RCCA workflows.

    • It does not prove causation simply because it finds correlation.

    • It is not the same as corrective action, CAPA execution, or verification of effectiveness.

    • It is not limited to generative AI chat tools. Many implementations use analytics models or rules engines without a conversational interface.

    How it appears in operations

    Operationally, AI-assisted root cause analysis often appears as a feature in quality, manufacturing, reliability, or analytics software. A system may ingest event records, process parameters, genealogy, maintenance history, and inspection results, then highlight common precursors or probable drivers of an issue. For example, it may associate recurring surface defects with a specific material lot, machine setting range, tool wear pattern, or sequence of alarms before failure.

    In regulated manufacturing, the value of the term usually depends on traceable inputs, retained evidence, and clear distinction between system-generated suggestions and human conclusions.

    Common confusion

    AI-assisted root cause analysis is often confused with predictive maintenance, anomaly detection, or incident summarization. Predictive maintenance focuses on forecasting failures before they occur. Anomaly detection flags unusual behavior. Incident summarization condenses records or logs. AI-assisted root cause analysis is narrower: it focuses on explaining why a specific problem likely happened.

  • CMMS (Computerized Maintenance Management System)

    CMMS (Computerized Maintenance Management System) commonly refers to software used to manage maintenance operations for physical assets such as machines, utilities, tools, facilities, and support equipment. It typically stores asset records and helps organizations plan, assign, track, and document preventive, corrective, and sometimes predictive maintenance work.

    A CMMS is primarily focused on maintenance execution and maintenance records. Common functions include work order management, preventive maintenance scheduling, asset hierarchies, spare parts and inventory tracking, labor assignment, downtime or failure history, and maintenance reporting. In regulated manufacturing, CMMS data may also support equipment history, calibration-related coordination, and documented evidence of maintenance activity, but the term itself does not mean a full quality system or compliance platform.

    What it includes

    • Asset and equipment master records

    • Preventive maintenance schedules and task lists

    • Corrective maintenance work orders and service logs

    • Spare parts, storeroom, and reorder tracking

    • Maintenance labor, contractor, and resource planning

    • Failure, downtime, and repair history for equipment

    What it does not necessarily include

    A CMMS does not automatically include broader manufacturing execution, production scheduling, enterprise finance, or formal quality management capabilities. Some platforms overlap with EAM, ERP, MES, or calibration systems, but those are separate concepts even when integrated in one software environment.

    How it appears in operations

    In day-to-day workflows, a CMMS is often where maintenance teams receive or create work orders, schedule recurring service, record parts used, capture technician notes, and close completed tasks. It may exchange data with ERP for purchasing and inventory valuation, with MES or SCADA for equipment events, or with quality systems when maintenance affects equipment status or production readiness.

    Common confusion

    CMMS vs. EAM: EAM, or Enterprise Asset Management, usually has a broader scope that can include lifecycle planning, capital assets, procurement, and multi-site asset governance. CMMS often refers to the maintenance-focused subset.

    CMMS vs. MES: MES manages production execution, routing, traceability, and shop-floor process control. CMMS manages maintenance work on the equipment and infrastructure used in production.

    CMMS vs. ERP: ERP manages enterprise-wide business processes such as finance, purchasing, and inventory accounting. A CMMS may connect to ERP, but it is not the same system.

  • Model card

    A model card is a structured document that summarizes what an artificial intelligence or machine learning model is, what it was designed to do, how it was evaluated, and what limits or risks should be understood before use. It commonly refers to a human-readable description that travels with the model or is linked to it in a repository, application, or governance workflow.

    In industrial and regulated environments, a model card is typically used as supporting documentation for transparency and internal review. It can help teams understand the model’s purpose, input and output expectations, training or reference data characteristics at a high level, performance measures, known constraints, and operational assumptions. It is documentation about the model, not the model itself.

    What it usually includes

    • The model’s name, version, and owner or maintaining team

    • Intended use cases and users

    • Out-of-scope or prohibited uses

    • Input data expectations and output format

    • Summary of how the model was trained or configured

    • Evaluation approach and reported performance metrics

    • Known limitations, failure modes, or bias considerations

    • Operational dependencies such as data quality, thresholds, or human review requirements

    How it appears in operations

    Model cards often appear in AI governance records, MLOps repositories, validation packages, supplier documentation, or approval workflows tied to analytics and decision-support tools. For example, a manufacturer using a machine learning model for visual inspection or maintenance prediction may keep a model card alongside version-controlled deployment records so quality, engineering, and IT stakeholders can review the model’s stated purpose and limits.

    Common confusion

    A model card is often confused with related artifacts, but they are not the same:

    • Data sheet or dataset documentation: describes the dataset rather than the model.

    • System documentation: covers the broader application, workflow, or architecture, not just the model.

    • Validation report: provides evidence from testing or qualification activities, while a model card is a summary-oriented description.

    • Algorithm specification: may describe logic or mathematics in depth, whereas a model card is usually broader and more operational.

    Boundary of the term

    The term commonly refers to documentation for AI or machine learning models, including predictive, classification, detection, or generative models. It does not by itself imply regulatory approval, production readiness, cybersecurity assurance, or fitness for a specific quality-critical decision. Those determinations depend on the surrounding governance, validation, and operational controls.

  • First-Pass Containment

    First-pass containment commonly refers to the immediate actions taken to isolate, identify, and control potentially nonconforming product, material, or process output as soon as an issue is detected. Its purpose is to prevent further use, shipment, or processing of affected items while the organization verifies scope and decides on next steps.

    In manufacturing and regulated operations, first-pass containment is an initial control step, not a final disposition. It may include stopping a line or operation, segregating stock, placing inventory on hold, tagging affected units, blocking transactions in MES or ERP, or increasing inspection on suspect lots. The exact actions vary by process and quality system.

    The term generally includes short-term actions performed before full root cause analysis is complete. It does not by itself mean the issue has been corrected, that corrective action is complete, or that all affected material has been fully identified.

    What it includes

    • Immediate control of suspect product or process output

    • Temporary measures to reduce further escape or use

    • Initial scoping of affected lots, serial numbers, work orders, or time windows

    • Communication to operations, quality, and sometimes suppliers or customers when relevant

    • System-level holds or status changes to preserve traceability and prevent movement

    What it does not include

    • Formal root cause determination

    • Permanent corrective action

    • Final material review or disposition

    • Verification that recurrence risk has been eliminated

    Operational meaning

    In daily workflows, first-pass containment often appears as the first documented response after a defect, test failure, process deviation, or supplier issue is found. Quality teams may open an NCR, place affected inventory in quarantine, trigger additional inspections, and use traceability records to identify where else the issue could exist. In digital environments, containment can also involve transaction locks, alerts, genealogy review, and status changes across MES, ERP, or QMS records.

    Common confusion

    First-pass containment is often confused with correction, corrective action, and disposition.

    • Correction is the action taken to fix a detected problem or affected item.

    • Corrective action addresses the underlying cause to reduce recurrence.

    • Disposition determines what happens to the affected material, such as rework, scrap, return, or use-as-is approval where applicable.

    Containment comes earlier and is mainly about immediate control.

  • Sensitivity analysis

    Sensitivity analysis is a method for evaluating how much an output changes when one or more inputs, assumptions, or parameters are varied. It is commonly used in manufacturing, quality, planning, and analytics to understand which factors have the greatest influence on a result.

    In practice, the term usually refers to testing a model, calculation, forecast, or process metric by changing selected variables and observing the effect. Examples include changing demand assumptions in a planning model, adjusting process parameters in a yield model, or examining how scrap rate, cycle time, or supplier lead time affects cost or schedule performance.

    Sensitivity analysis does not by itself prove cause and effect, validate a model, or determine the single correct operating setting. It is an analytical technique for understanding responsiveness, uncertainty, and relative influence.

    Where it applies

    In industrial and regulated operations, sensitivity analysis may appear in:

    • production planning and capacity scenarios

    • cost, margin, and inventory modeling

    • quality and process-improvement studies

    • risk assessments and contingency planning

    • engineering and process development work, including design of experiments and simulation

    It can be performed with simple spreadsheet models or with more formal simulation, statistical, or optimization tools.

    Common confusion

    Sensitivity analysis is often confused with scenario analysis and design of experiments.

    • Scenario analysis usually compares a defined set of combined conditions, such as best case, expected case, and worst case.

    • Sensitivity analysis focuses on how the output responds when specific inputs are changed, often one at a time or across a defined range.

    • Design of experiments (DoE) is a structured experimental method used to study factor effects and interactions in real or simulated processes.

    It is also not the same as measurement sensitivity, which refers to how responsive an instrument or detection method is.

    Manufacturing example

    A planner may test how a 5 percent change in forecast demand, supplier lead time, or machine uptime affects required inventory and promised ship dates. A quality engineer may assess how variation in temperature, dwell time, or torque changes predicted defect rates. In both cases, the goal is to identify which inputs matter most and where tighter control or better data may be needed.

  • NCR response time

    NCR response time commonly refers to the elapsed time between the creation of a nonconformance report or nonconformance record (NCR) and a defined response point in the organization’s workflow.

    The exact endpoint varies by company or system. It may mean time to initial review, time to containment decision, time to disposition, or time to formal closure response. Because of that, the term is best understood as a timing metric for nonconformance handling, not as a single universal standard.

    What it includes

    In manufacturing and quality systems, NCR response time is usually tracked as a workflow measure tied to how quickly an issue is acknowledged and acted on after a defect, deviation, or nonconforming condition is identified. Depending on local definitions, it can include:

    • time from NCR creation to quality review
    • time to assign ownership
    • time to implement immediate containment
    • time to complete disposition or investigation
    • time to issue a supplier response in supplier-related NCR workflows

    It does not automatically mean full corrective action completion unless the process explicitly defines it that way.

    What it is not

    NCR response time is not the same as overall CAPA cycle time, MRB turnaround time, or rework completion time, although those measures may be related. It is also not the same as defect rate or scrap rate. Response time measures speed of handling an NCR, while those other metrics measure quality outcomes, downstream decisions, or production impact.

    How it appears in systems and workflows

    In MES, QMS, ERP-integrated quality modules, or supplier portals, NCR response time often appears as a timestamp-based KPI or SLA-style internal target. Typical workflow events used to calculate it include record creation date, first review date, disposition date, and closure date.

    Teams may use it to monitor backlog, escalation risk, aging nonconformances, and responsiveness across internal departments or suppliers. In regulated environments, the metric is often important because delayed responses can affect segregation, traceability, investigation timing, and evidence quality.

    Common confusion

    NCR response time is commonly confused with NCR resolution time. Response time usually refers to how quickly the NCR receives attention or a defined first action. Resolution time usually refers to how long it takes to complete the full process through disposition, correction, or closure.

    It can also be confused with CAPA response time. An NCR may trigger CAPA, but the two are not identical. NCR handling addresses a specific nonconformance record, while CAPA addresses corrective and preventive actions at a broader system or root-cause level.

  • Hold Tag

    A hold tag is a physical tag, label, status marker, or digital system indicator used to show that an item, batch, container, asset, or work step is on hold and must not move forward until the hold is reviewed, resolved, or released by an authorized person or process.

    In manufacturing and regulated operations, a hold tag commonly serves as a control to prevent unintended use, shipment, processing, installation, or disposition of something that requires further attention. The reason may relate to quality, documentation, inspection status, deviation review, material identity, maintenance condition, or another operational concern. The term refers to the marking or status itself, not to the investigation or approval workflow behind it.

    What it includes

    • Physical tags or labels attached to parts, containers, pallets, tools, or equipment
    • Electronic hold statuses in MES, ERP, WMS, QMS, or maintenance systems
    • Temporary restrictions that block use, movement, release, or further processing
    • Identification of the reason, date, source, or responsible function when that information is part of the tag or record

    What it does not mean

    A hold tag does not by itself determine final disposition. It does not mean the item is scrap, nonconforming, rejected, or unsafe in every case. It simply indicates that normal use or progression is restricted pending review or release. In some organizations, hold tags are also used for administrative or documentation issues, not only for product defects.

    How it appears in operations

    Operationally, a hold tag may be applied when incoming material fails inspection, a batch is awaiting test results, a machine is removed from service, or a work order cannot continue because a required approval is missing. In digital workflows, the same concept may appear as a blocked lot, restricted inventory status, quality hold, maintenance hold, or routing stop.

    Common confusion

    Hold tag is often confused with quarantine, NCR status, lockout/tagout, and red tag. A hold tag commonly indicates restricted use or movement pending review. Quarantine usually refers to controlled segregation of suspect or restricted material. An NCR documents a nonconformance and related workflow. Lockout/tagout is a specific energy-isolation safety control for equipment, which is different from a general production or quality hold. A red tag in 5S is typically used to identify unnecessary items for workplace organization, not necessarily product or process holds.