Connect981 – Content Dev

Glossary Category: Operations and Quality Signals

Exception policy
An exception policy is a documented set of rules that defines when a standard requirement, control, process step, or system rule may be temporarily bypassed or handled differently, and how that exception is requested, approved, recorded, and reviewed.

In industrial and regulated environments, the term commonly refers to governance around deviations from normal practice, not the exception itself. The policy sets the criteria, authority, duration, documentation, and oversight for exceptions. It may apply to areas such as quality procedures, production workflows, access controls, data handling, training requirements, change control, or supplier processes.

An exception policy usually includes what qualifies as an exception, who can approve it, what evidence must be captured, how risk is assessed, how long the exception remains valid, and when it must be re-evaluated or closed. In digital systems, it may also define how exceptions are logged in MES, QMS, ERP, ticketing, or workflow tools so they remain traceable.

An exception policy does not, by itself, approve a specific deviation. It is the governing framework for handling exceptions consistently. A one-time approved departure from a requirement is usually an exception request, deviation, waiver, concession, or similar record, depending on the process and industry.

Operational meaning

In practice, an exception policy appears where normal controls need a defined path for authorized override without losing accountability. Examples include:
- temporary use of an alternate inspection step when equipment is unavailable
- time-limited system access beyond a standard role
- approved processing outside the usual workflow because of supply or scheduling constraints
- documented acceptance of a temporary control gap while a corrective action is in progress
The policy is typically linked to evidence trails such as approval records, timestamps, justification, affected orders or batches, and expiration or review dates.

Common confusion

Exception policy is often confused with deviation, waiver, concession, or nonconformance.
- An exception policy defines the rules for handling exceptions.
- A deviation or exception record is the individual instance where normal requirements are not followed.
- A waiver or concession often refers to formal acceptance of a requirement departure under defined conditions.
- A nonconformance usually describes failure to meet a requirement, whether planned or unplanned.
In information security, the same term may focus on exceptions to security controls or policy requirements. In quality and manufacturing, it more often relates to controlled departures from approved procedures or specifications. The core idea is similar across disciplines: exceptions are not unmanaged workarounds, but documented departures handled under defined rules.
April 9, 2026
brownfield environments
Brownfield environments are existing industrial sites, facilities, or systems that are already built and in operation, where new equipment, automation, or software must be integrated into what is already there. In manufacturing, this typically includes legacy OT assets, established production lines, installed control systems, and supporting IT infrastructure that cannot simply be replaced.

In contrast to greenfield projects, which start from a clean slate, brownfield work focuses on modifying, extending, or upgrading current systems while production, quality, and compliance obligations continue.

Key characteristics in industrial and regulated settings
- Existing assets and constraints: Legacy PLCs, DCS, SCADA, MES, and custom integrations that may have limited documentation or vendor support.
- Continuous operations: Changes must be implemented around live production schedules and validation needs, often with tight maintenance windows.
- Mixed technology generations: Old and new hardware, operating systems, networks, and applications must coexist securely and reliably.
- Regulatory and quality impact: Modifications may trigger requalification, revalidation, or updates to procedures, records, and training.
- Physical and network limitations: Existing layouts, cable routes, panels, and IP schemes restrict how new systems can be deployed.
Operational meaning

In practice, working in a brownfield environment affects how organizations plan and execute initiatives such as:
- Introducing new OT security controls or segmenting existing networks.
- Integrating new MES or historian systems with legacy controllers and databases.
- Upgrading plant-floor equipment while maintaining validated states in regulated plants.
- Applying supply chain and procurement controls for replacement parts and vendors when original suppliers are no longer available.
Engineering, IT, quality, and operations teams typically need coordinated change control, impact assessment, and testing strategies that account for installed base variability and historical configurations.

Common confusion
- Brownfield vs. greenfield: Greenfield environments are new builds with no existing production or systems to integrate with. Brownfield involves modification of existing, running facilities.
- Brownfield site (environmental) vs. operational brownfield: Outside industrial operations, “brownfield” can also refer to land with prior industrial use and possible contamination. In manufacturing systems and OT/IT discussions, the term more often refers to existing plants and installed systems, not environmental remediation status.
Relation to supply chain and risk controls

In frameworks such as NIST SP 800-53, brownfield environments influence how supply chain and cybersecurity controls are applied. For example, controls on vendor selection, component authenticity, and system integrity must be adapted to replacement parts, upgrades, and integrations into an existing installed base rather than only to new greenfield projects.
April 9, 2026
quality ratio
Quality ratio commonly refers to a calculated indicator that compares a measure of conforming output to a measure of total output or potential output. It is used to express quality performance as a proportion, rate, or percentage rather than as an absolute count.

What a quality ratio usually measures

In industrial and regulated manufacturing environments, the term is most often used for ratios such as:
- Good units / total units (e.g., non-defective parts divided by all produced parts)
- Accepted lots / total lots (e.g., lots that pass inspection divided by all lots inspected)
- Conforming time / total production time (e.g., time producing in-spec product divided by total run time)
- In-spec measurements / total measurements (e.g., test results within tolerance divided by all tests performed)
These ratios can be expressed as decimals (0 to 1), percentages (0% to 100%), or indices, depending on how they are used in reports and dashboards.

Role in metrics, indicators, and KPIs

Within performance frameworks such as ISO 22400, a quality ratio is typically treated as an indicator or a derived metric rather than raw data. It is calculated from underlying measurements such as unit counts, defect counts, test results, or inspection decisions. Depending on local governance, a specific quality ratio may be designated as a key performance indicator (KPI) if it is critical to business or regulatory objectives.

How quality ratio appears in operations and systems

In practice, quality ratios may be:
- Calculated in MES, LIMS, SPC, or quality management systems based on production and inspection data
- Included in OEE or similar performance dashboards as the “quality” or “yield” component
- Used in shift, batch, or lot summaries to quantify the share of conforming vs nonconforming output
- Aggregated by product, line, plant, or supplier for trend analysis and reporting
The exact definition and formula of a quality ratio should be documented so that users understand what is in the numerator, what is in the denominator, how rework or re-tests are treated, and what time or scope filters apply.

What quality ratio is not
- It is not a specific, single standard formula. Different organizations or standards may define different quality ratios for their purposes.
- It is not the same as cost of poor quality (COPQ), although a quality ratio may be one input to COPQ calculations.
- It is not a qualitative assessment or narrative description of quality; it is a numeric, computed metric.
Common confusion
- Quality ratio vs yield: In many plants, “yield” and “quality ratio” are used interchangeably when referring to good output divided by total output. In other contexts, yield may include or exclude specific categories (e.g., reworkable units), while quality ratio may follow a different local definition.
- Quality ratio vs defect rate: Defect rate typically measures defects or defective units divided by total units, while a quality ratio often measures the complementary side (good units divided by total units). Both are ratios but focus on different perspectives of the same data.
Link to the ISO 22400 context

In the context of ISO 22400 and similar performance standards, a quality ratio is an example of a derived indicator: it is calculated from primary measurements (such as unit counts, test results, and inspection outcomes) and used as part of a broader performance model. The standard provides structure for such indicators but does not define a single universal “quality ratio” formula for all organizations.
April 9, 2026
Calculation layer
A calculation layer is the part of a software, data, or automation architecture where raw inputs are transformed into derived values such as KPIs, status indicators, rollups, formulas, and decision-support metrics. In manufacturing and regulated operations, it commonly sits between source systems and the places where users consume results, such as dashboards, reports, MES screens, quality records, or analytics tools.

The term usually refers to logic that applies formulas, aggregation rules, thresholds, unit conversions, time-window calculations, or contextual business rules to data from equipment, historians, MES, ERP, LIMS, QMS, or other operational systems. It does not usually refer to the original data source itself, and it is not the same as the presentation layer that only displays results.

What it includes
- Derived production metrics such as throughput, scrap rate, downtime totals, or cycle time.
- Quality-related calculations such as defect percentages, yield, trend indicators, or specification comparisons.
- Business rules that combine data from multiple systems, for example linking work order status from ERP with actual execution data from MES.
- Reusable logic used consistently across reports, dashboards, and operational applications.
What it does not necessarily include
- Raw data collection from machines, sensors, or enterprise systems.
- User interface components that only visualize data.
- Long-term storage by itself, unless the platform combines storage and calculation functions.
- Scientific or engineering modeling in the broader sense, unless that modeling is specifically implemented as part of operational data processing.
How it appears in operations

In practice, a calculation layer may be implemented in a historian, MES, analytics platform, middleware stack, data warehouse, or semantic model. For example, a plant may calculate OEE-related values from machine states, production counts, and planned schedule data rather than storing those values directly at the source. In a quality context, it may calculate lot-level acceptance metrics or trend signals from inspection results.

Separating calculations from source capture can make definitions more consistent across systems, but the exact architecture varies. Some organizations calculate close to the equipment or MES level, while others centralize logic in reporting or integration platforms.

Common confusion

Calculation layer vs. data layer: the data layer stores or moves data, while the calculation layer applies logic to produce derived meaning from that data.

Calculation layer vs. presentation layer: the presentation layer shows values to users, while the calculation layer determines how those values are computed.

Calculation layer vs. business rules engine: a business rules engine may be part of a calculation layer, but it can also support broader workflow decisions that are not purely numerical calculations.
April 9, 2026
Autonomous decision-making
Autonomous decision-making commonly refers to a system’s ability to evaluate inputs, apply rules or models, choose among available actions, and carry out a response without a person approving each individual decision in real time.

In industrial and manufacturing settings, this usually applies to software, control systems, or connected equipment that can act on production, quality, maintenance, scheduling, or process data. The decision logic may be simple, such as threshold-based rules, or more complex, such as optimization or machine learning models.

The term includes both the decision itself and the automated execution of the selected action when that execution is part of the system design. It does not mean the system operates without any human involvement at all. People still commonly define objectives, limits, escalation paths, permissions, and oversight.

Where it appears in operations

Autonomous decision-making can appear in workflows such as:
- adjusting machine parameters within approved ranges based on sensor readings
- routing work or exceptions to different queues based on business rules
- triggering maintenance actions from condition-monitoring data
- holding or releasing material based on predefined quality logic
- reordering materials when stock and demand conditions meet set criteria
In integrated environments, these decisions may span OT and IT systems, such as a control layer reacting to process conditions while MES, ERP, or quality systems record the event and resulting status changes.

What it is not

Autonomous decision-making is not the same as basic automation that follows a fixed sequence with no meaningful selection among alternatives. It is also not the same as decision support, where a system recommends an action but a person must approve or execute it.

Not all autonomous decision-making uses artificial intelligence. Many industrial implementations rely on deterministic rules, setpoints, recipes, exception logic, or optimization routines.

Common confusion
- Automation: a broader term for automatic execution. Autonomous decision-making is a narrower case where the system chooses an action based on current conditions.
- Decision support: provides recommendations or alerts for human review. Autonomous decision-making allows the system to act within defined boundaries.
- Autonomy: often used more broadly to describe the overall level of independent operation of a machine or software system. Autonomous decision-making is one capability within that broader concept.
- AI: may enable autonomous decisions, but the terms are not interchangeable.
Manufacturing context

In regulated or quality-sensitive operations, autonomous decision-making is commonly bounded by approved rules, traceable data, exception handling, and escalation conditions. The practical concern is usually not whether decisions are automatic, but which decisions may be delegated to systems, under what limits, and how the resulting actions are recorded.
April 9, 2026
furnace load
A furnace load commonly refers to the complete set of parts, fixtures, and any auxiliary materials (such as quench baskets or trays) that are placed into an industrial furnace for a single heat-treatment, sintering, brazing, or firing cycle.

What a furnace load includes

In industrial and regulated manufacturing environments, a furnace load typically includes:
- The workpieces or product being processed (e.g., machined components, castings, forgings, weldments)
- Loading hardware and fixtures (racks, baskets, trays, jigs, spacers)
- Any load-specific accessories that influence thermal behavior (e.g., load thermocouples, shielding, packing media)
- Associated processing parameters for that run, such as recipe, setpoints, ramp/soak profile, and atmosphere settings recorded for that load
The term is usually applied at the batch or lot level in batch furnaces, but it can also describe the subset of product moving through a continuous furnace at one time or during a defined time window.

Operational meaning

Operationally, a furnace load is a key unit of planning, execution, and traceability in heat-treatment and other thermal processes. It is often used to:
- Plan capacity and scheduling, based on how many parts or trays can be loaded per cycle
- Define and record process conditions applied to a specific group of parts
- Associate quality results, such as hardness tests, microstructure evaluations, or NDT findings, back to a specific thermal cycle
- Group parts for lot-level release or hold when deviations, alarms, or equipment issues occur during the cycle
In MES, ERP, or quality systems, the furnace load may be represented as a batch, lot, or work order operation, with each part or sub-lot linked to that load record for genealogy and compliance purposes.

What it is not
- It is not the electrical or fuel power draw of the furnace (that is often called electrical load or thermal load in utilities/engineering contexts).
- It is not the furnace itself or a permanent fixture; it refers to what is charged into the furnace for a given run and the configuration of that charge.
Common confusion

Furnace load vs. thermal load: In process engineering, thermal load can mean the amount of heat energy the furnace must deliver to reach and maintain conditions. Furnace load, in manufacturing and quality contexts, more often means the physical grouping of parts and fixtures being processed.

Furnace load vs. production lot: A production lot may span multiple furnace loads if capacity limits require splitting, or a single furnace load may contain multiple lots or customer orders. For traceability, systems usually record explicit links between lot identifiers and furnace-load identifiers.

Relation to scrap and quality

In heat treatment and other special processes, defects discovered on one or more parts from a furnace load may trigger investigation or containment at the load level. Because all parts in a load share the same thermal cycle and configuration, manufacturers often analyze nonconformances, scrap, and rework in terms of affected furnace loads and their associated recipes, fixtures, and equipment status.
April 9, 2026