Connect981 – Content Dev

Glossary Tag: risk detection

  • as-built record

    Core meaning

    An **as-built record** is a documented description of the actual configuration, materials, and construction of a product, system, or facility at the time it is completed or released.

    It captures what was **actually built and installed**, which may differ from the original design or engineering intent. In regulated manufacturing, as-built records are typically retained as part of product history or device history documentation.

    Typical contents in manufacturing

    In industrial and regulated environments, an as-built record commonly includes:

    – Final bill of material (BOM) with actual part numbers and revisions used
    – Lot, batch, or serial numbers of critical materials and components
    – Configuration details (options, software versions, parameter sets)
    – Records of deviations, nonconformances, or waivers that changed the design or process
    – Approved engineering changes applied during build (e.g., ECNs, ECRs)
    – Key process data that define the built state (e.g., torque values, calibration data, test results)
    – Identification of the specific unit(s) to which the record applies (serial number, unit ID, tail number, etc.)

    The level of detail depends on the product, risk classification, and regulatory expectations.

    Use in MES, ERP, and traceability

    In integrated manufacturing IT/OT landscapes:

    – **MES (Manufacturing Execution System)** typically holds or generates the as-built record at the unit, serial, or batch level. It may include:
    – Material genealogy (which material lots and components went into each finished unit)
    – Route and operation history
    – Operator IDs, timestamps, and equipment used
    – Test, inspection, and release decisions

    – **ERP (Enterprise Resource Planning)** usually contains the **as-planned** and **as-designed** structures (standard BOMs, routings, costing), and may store high-level as-built information (e.g., shipped configuration, top-level serials) but not full process detail.

    For high-traceability industries such as aerospace, medical devices, and pharmaceuticals, the combination of MES data and supporting quality records commonly constitutes the authoritative as-built record for a product or batch.

    Boundaries and what it is not

    – **As-built vs. as-designed:**
    – *As-designed* describes the intended configuration from engineering.
    – *As-built* documents the configuration that was actually produced.

    – **As-built vs. as-planned/as-intended process:**
    – *As-planned* describes the standard process route or work instructions.
    – *As-built* includes the actual route followed, including rework, holds, or alternative operations.

    – **As-built vs. real-time monitoring data:**
    – Real-time OT/SCADA data streams support the record but are not, by themselves, the as-built. The as-built record is the curated, contextualized, and retained representation of the final state.

    An as-built record is typically not a marketing datasheet or general product specification; it is a formal, traceable record tied to specific manufactured units or installations.

    Common confusion and related terms

    – **As-built drawing:** A drawing or model updated to reflect the final constructed state. It is often one element of the broader as-built record but does not, by itself, capture full material genealogy or process history.
    – **Device history record (DHR) / batch record:** In some regulated sectors, these formal record types include or essentially are the as-built record, augmented with quality and release documentation.
    – **Configuration record:** Focuses on the configuration of a unit (options, software, parameters). An as-built record usually includes the configuration record plus the underlying materials and process evidence.

    Site context: aerospace material usage and genealogy

    In aerospace manufacturing, an as-built record typically links:

    – Each aircraft or major assembly serial number
    – The exact material lots, components, and subassemblies installed
    – The manufacturing and inspection operations performed (with dates, equipment, and personnel)
    – Any concessions, deviations, or repairs accepted during build

    MES is commonly used to capture this unit-level genealogy and operation history, while ERP maintains higher-level inventory and costing views. Together, they support the as-built record required for long-term traceability and investigations.

  • Rework Routing

    Rework routing is the defined sequence of operations, checks, and approvals used to correct a nonconforming part, assembly, or batch and determine whether it can return to the normal production flow. In manufacturing systems, it describes where the item goes, what work is performed, what evidence is recorded, and who must review or approve the disposition.

    Rework routing is commonly managed in an MES, digital traveler, quality management workflow, or ERP-connected production system. It may include added work instructions, inspection steps, material review board decisions, quality holds, re-test requirements, and traceability records linking the rework activity to the original work order or serial number.

    The term should not be confused with normal production routing, which defines the planned manufacturing path for conforming work. It also differs from shipping or network routing. Rework routing is specifically tied to correcting or evaluating work that has deviated from the expected process or specification.

  • Traceability Graph

    A traceability graph is a data structure or visual model that represents traceability as connected relationships rather than as a simple linear list. In manufacturing and regulated operations, it commonly shows how parts, lots, serial numbers, process steps, equipment, documents, test results, inspections, nonconformances, and finished units are linked across the product lifecycle.

    Unlike a basic history log, a traceability graph focuses on connections between entities. Each node typically represents an item, record, event, or asset, and each edge represents a relationship such as consumed by, assembled into, processed on, inspected by, or linked to. This makes it possible to follow lineage backward to sources and forward to affected products or records.

    What it includes

    • Material and component genealogy, such as lot-to-batch or part-to-assembly relationships

    • Process execution links, such as routing steps, machine usage, operator actions, and timestamps

    • Quality and compliance evidence, such as inspection results, deviations, CAPA references, and approvals

    • Cross-system references, such as connections among MES, ERP, PLM, QMS, and maintenance records

    A traceability graph does not refer only to a chart or dashboard. The term may describe the underlying graph-style data model, the stored relationship network, or a user-facing visualization built from that network.

    Operational meaning

    In day-to-day operations, a traceability graph is used to answer questions that span multiple records and systems. Examples include identifying which finished units contain a suspect lot, which work orders used a specific machine setting, or which inspection records support an as-built configuration. It is especially relevant where traceability must extend across manufacturing execution, quality, supplier inputs, and service history.

    Common confusion

    A traceability graph is often confused with genealogy, digital thread, or audit trail.

    • Genealogy usually focuses on parent-child material lineage, while a traceability graph can include broader relationships such as documents, equipment, people, and quality events.

    • Digital thread is a broader concept for connected data across the lifecycle. A traceability graph can be one technical way to represent part of that thread.

    • Audit trail records who changed what and when. A traceability graph may link audit trail records, but it is not limited to change logging.

    Why the graph model matters

    Graph-based traceability is commonly used when relationships are many-to-many and not strictly sequential. This is typical in high-mix manufacturing, serialized production, rework loops, outsourced processing, and regulated quality workflows where one event can affect multiple records and one product can inherit evidence from many sources.

  • Identifier mapping

    Identifier mapping is the association between identifiers used in different systems, data models, or business processes to represent the same real-world object, record, or entity. In manufacturing and regulated operations, it commonly refers to linking IDs such as part numbers, material codes, equipment IDs, batch numbers, supplier IDs, work order numbers, or employee records across MES, ERP, PLM, QMS, LIMS, and other connected systems.

    The purpose of identifier mapping is to preserve referential consistency when data moves between systems that do not share the same native key structure. A mapping may be one-to-one, one-to-many, many-to-one, or conditional, depending on how the source and target systems are designed. It can be maintained in middleware, master data services, integration logic, data warehouses, or application-level configuration.

    What it includes

    • Cross-references between internal and external IDs for the same entity

    • Mappings between legacy and current identifiers after migration or system replacement

    • Translation of plant-specific, supplier-specific, or system-specific codes into a common reference

    • Rules for handling alternate identifiers, revisions, prefixes, formatting differences, or composite keys

    What it does not mean

    Identifier mapping is not the same as changing the identifier itself. It does not require a single universal ID, and it is not identical to data transformation in general. Data transformation may change values, formats, or structures, while identifier mapping specifically concerns which identifier in one context corresponds to which identifier in another.

    How it appears in operations

    In practice, identifier mapping often appears in integrations where one system must recognize records created or controlled elsewhere. Examples include linking an ERP material number to an MES item ID, matching a supplier lot reference to an internal batch record, or associating a PLM part revision identifier with the manufacturing record used on the shop floor. Accurate mapping supports traceability, genealogy, transaction posting, and consistent reporting across systems.

    Common confusion

    Identifier mapping is commonly confused with master data management, record matching, and field mapping.

    • Master data management governs authoritative data and ownership. Identifier mapping is one mechanism used within or alongside it.

    • Record matching is the process of determining whether two records refer to the same entity. Identifier mapping is the stored relationship once that correspondence is established.

    • Field mapping defines how data fields align between systems, such as source and target columns. Identifier mapping is narrower and focuses on the IDs that represent entities.

    Manufacturing example

    A company may store the same serialized component under one identifier in PLM, another in ERP, and a third in MES. Identifier mapping links those values so that engineering, production, quality, and traceability records can refer to the same component without assuming the systems use identical keys.

  • risk heatmap

    A risk heatmap is a visual tool that plots identified risks on a matrix, usually using likelihood on one axis and impact on the other. It is commonly used to summarize the relative priority of operational, quality, compliance, cybersecurity, supply chain, or project risks.

    The term usually refers to the chart itself, not the full risk management process. A heatmap helps teams see which risks appear low, medium, or high based on a chosen scoring method. In manufacturing and regulated environments, it may be used in management reviews, program reviews, CAPA discussions, supplier oversight, or risk register reporting.

    What it includes

    • A defined set of risk criteria, often impact and likelihood
    • A scoring method, whether qualitative, quantitative, or mixed
    • A visual grid or color-coded matrix
    • Individual risk items plotted from a risk register or assessment

    A risk heatmap does not by itself identify root cause, assign mitigations, or prove risk is controlled. It is a representation of assessed risk at a point in time.

    How it is used in operations

    In practice, a risk heatmap often pulls together risks such as supplier delays, equipment downtime, nonconformance trends, data integrity issues, validation gaps, or OT cybersecurity exposure. Teams may use it to compare risks across production lines, sites, programs, or processes and to decide which items need escalation or closer monitoring.

    Some organizations also maintain separate heatmaps for inherent risk and residual risk. In that usage, inherent risk reflects exposure before controls, while residual risk reflects exposure after current controls are considered.

    Common confusion

    Risk heatmap vs. risk register: a risk register is the underlying list of risks, scores, owners, and actions. A heatmap is one visual way to display part of that information.

    Risk heatmap vs. control dashboard: a control dashboard tracks current control performance or status. A heatmap summarizes assessed risk levels, which may or may not be based on live operational signals.

    Risk heatmap vs. severity matrix: a severity matrix may focus only on consequence or hazard classification. A risk heatmap usually combines at least two dimensions, most often likelihood and impact.

    Limitations

    Risk heatmaps are useful for communication, but they simplify complex conditions. Different scoring scales, inconsistent definitions, or subjective ratings can make comparisons unreliable. For that reason, the heatmap is commonly used alongside a defined risk register, review criteria, and supporting evidence.

  • Early warning signal

    An early warning signal is an indicator that suggests a process, system, product, or operation may be moving toward an undesired condition before a failure, deviation, or disruption is fully visible. It is used to detect emerging risk or abnormal change early enough for investigation or response.

    In manufacturing and regulated operations, an early warning signal commonly refers to a measurable pattern, event, threshold breach, or trend that appears ahead of more serious outcomes such as downtime, nonconformance, scrap, schedule misses, supply shortages, or compliance issues. It can come from equipment data, process parameters, quality results, operator observations, maintenance history, inventory status, or system alerts.

    An early warning signal is not the same as a confirmed root cause or a final diagnosis. It indicates elevated likelihood or developing instability, not proof that a specific failure will occur. Some signals are predictive and data-driven, while others are rule-based or observational.

    How it appears in operations

    • A temperature or vibration trend that rises before machine failure

    • An increase in rework, defect escapes, or process variability before a formal nonconformance spike

    • Repeated minor schedule slips that precede a larger throughput problem

    • Declining supplier delivery performance that suggests future material shortages

    • Audit trail gaps, overdue reviews, or document exceptions that indicate control weakness

    In digital environments, early warning signals may be surfaced through dashboards, alarms, exception workflows, SPC trends, maintenance analytics, MES events, ERP planning signals, or quality management reports.

    Common confusion

    Early warning signal is often confused with an alarm, a KPI, or a root cause.

    • Alarm or alert: usually a direct notification triggered when a defined condition is met. An early warning signal may exist before any alarm threshold is crossed.

    • KPI: a performance measure used to track results. A KPI can serve as an early warning signal, but not every KPI is intended for early detection.

    • Root cause: the underlying reason an issue occurred. An early warning signal points to possible emerging problems but does not by itself explain why they are happening.

    • Leading indicator: often closely related. In many operational contexts, an early warning signal is a type of leading indicator focused on detecting deterioration or risk.

    Scope and limits

    The term includes both quantitative and qualitative indicators, as long as they are used to recognize developing issues before the main event. It does not require advanced analytics or machine learning. A manual observation logged by an operator can be an early warning signal if it reliably precedes a later problem.

    The term generally excludes signals that are only visible after the event has already happened, such as final scrap totals, confirmed downtime duration, or completed deviation records, unless those measures are being used to predict a subsequent event in a broader chain.

  • FMEA (Failure Modes and Effects Analysis)

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

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

    Where it applies

    FMEA is commonly applied in several ways:

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

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

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

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

    How it is used operationally

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

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

    Common confusion

    FMEA is often confused with related terms:

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

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

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

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

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

  • risk-based escalation

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

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

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

  • Forecasting

    Forecasting is the process of estimating a future condition based on available information such as historical data, current operating signals, known constraints, and expected changes. In manufacturing and industrial operations, it commonly refers to predicting demand, material requirements, production load, maintenance needs, quality trends, or capacity utilization over a defined time horizon.

    Forecasting is not the same as planning or scheduling. A forecast is an estimate of what is likely to happen. Planning uses that estimate to decide what actions to take, and scheduling turns those decisions into time-based execution.

    Where it applies in operations

    Forecasting appears across both business and plant-level workflows, including:

    • demand forecasting for sales, order volume, or customer consumption

    • materials forecasting to anticipate component and raw material needs

    • capacity forecasting for labor, equipment, tooling, and line loading

    • maintenance forecasting based on usage, condition, or failure patterns

    • quality forecasting to identify likely scrap, rework, or nonconformance trends

    • inventory forecasting to estimate stock levels, shortages, or excess

    In integrated environments, forecasting often feeds ERP, MRP, MES, APS, or analytics systems. For example, a demand forecast may drive material planning, while a capacity forecast may highlight upcoming bottlenecks on a constrained work center.

    Common methods

    Forecasts may be generated using simple averages, trend analysis, seasonality models, statistical methods, or machine learning. They may also include judgment from planners, production teams, procurement, or program managers when historical data alone does not reflect upcoming changes such as engineering revisions, customer schedule changes, or supplier disruption.

    The output can be quantitative, such as units per week or machine hours per month, or qualitative, such as expected risk level or likely shortage exposure.

    Common confusion

    Forecasting vs. planning: forecasting estimates future conditions; planning selects responses.

    Forecasting vs. scheduling: scheduling assigns work to dates, shifts, lines, or resources.

    Forecasting vs. prediction: the terms are often used interchangeably, but forecasting usually implies a structured time-based estimate for business or operational use.

    Forecasting vs. MRP: MRP is a planning calculation. It may use forecasts as one input, but it is not itself the forecast.

    Operational note

    Forecasts are usually updated on a recurring cadence because conditions change. In regulated or tightly controlled environments, the forecast itself is typically an analytical input, while the governed records remain the approved plans, orders, routings, specifications, and execution history.

  • Fee-at-Risk

    Fee-at-Risk commonly refers to the portion of a contractor or supplier fee that is contingent on meeting specified contractual performance conditions. It is not the full contract value or the underlying cost reimbursement itself. Instead, it is the part of compensation that may be reduced, withheld, or earned based on how actual performance compares with agreed criteria.

    In regulated manufacturing, aerospace, defense, and complex operations, Fee-at-Risk often appears in service agreements, outsourced processing, program execution contracts, and other performance-based commercial arrangements. The conditions tied to the fee may relate to delivery, quality, schedule adherence, responsiveness, documentation quality, traceability, uptime, or similar measurable requirements.

    How the term is used operationally

    Operationally, Fee-at-Risk shows up as a financial mechanism linked to defined metrics, milestones, or service levels. Examples include:

    • a supplier fee portion tied to on-time delivery performance

    • a program management fee contingent on meeting schedule or readiness milestones

    • a service provider fee linked to quality, turnaround time, or evidence completeness

    The exact structure varies by contract. Some arrangements use a fixed percentage of fee placed at risk, while others define scoring formulas, threshold levels, or milestone-based release conditions.

    What it includes and excludes

    Fee-at-Risk includes the contingent fee component of an agreement and the performance criteria used to determine whether that amount is earned. It may be associated with incentive fee, award fee, or performance-based fee structures, depending on the contracting model.

    It does not usually mean:

    • the entire contract price is variable

    • the supplier is automatically noncompliant if the fee is reduced

    • a regulatory penalty or fine imposed by an authority

    • ordinary warranty holdbacks, unless the contract explicitly structures them that way

    Common confusion

    Fee-at-Risk is often confused with penalties, liquidated damages, or retainage. These are related but not identical concepts. Fee-at-Risk usually refers to compensation that is conditionally earned based on performance. A penalty is typically framed as a charge for failure. Retainage is usually a withheld amount pending completion or acceptance. In some contracts, these mechanisms may coexist.

    It can also be confused with general business risk. Here, the term is narrower: it refers specifically to the contract fee component exposed to performance outcomes.

    Why it matters in manufacturing systems

    Where MES, ERP, quality, and supplier management systems are used, Fee-at-Risk may depend on data drawn from those systems, such as shipment timing, nonconformance rates, lot traceability, closure times, or documentation status. In that sense, the term is commercial in origin but often relies on operational records and system evidence to support fee determination.