Connect981 – Content Dev

Glossary Tag: signal detection

  • Back-testing

    Back-testing is the evaluation of a model, decision rule, forecast method, or detection logic against historical data to estimate how it would have performed if used in the past. In industrial and manufacturing settings, it commonly refers to testing analytics, alert thresholds, predictive rules, or planning logic on prior production, quality, maintenance, or supply chain data.

    It is a retrospective method. It uses existing records rather than live operation. Because of that, back-testing can help assess whether a rule appears stable, sensitive, or overly noisy before it is used in production workflows. It does not prove future performance, and it is not the same as real-time validation in current operations.

    Where it appears in manufacturing systems

    Back-testing may be used in systems and workflows such as:

    • quality analytics, for example testing whether a signal would have detected past drift or nonconformance earlier

    • maintenance analytics, for example checking whether a predictive rule would have flagged equipment issues before failure events

    • planning and inventory models, for example comparing forecast logic against historical demand and supply outcomes

    • alerting and monitoring, for example tuning thresholds against prior process, machine, or historian data

    • risk scoring or exception management, for example testing whether a scoring method would have identified past high-risk lots, orders, or suppliers

    What it includes and excludes

    Back-testing commonly includes historical input data, the rule or model being evaluated, and a comparison between predicted or triggered results and known outcomes. The historical data may come from MES, ERP, QMS, SCADA, historians, CMMS, or related systems.

    It does not by itself include model training, live deployment, or operational change control, although it may support those activities. It also does not guarantee that a model is suitable for current conditions if equipment, materials, routing, product mix, or business rules have changed since the historical period being tested.

    Common confusion

    Back-testing is often confused with simulation, validation, and benchmarking.

    • Back-testing uses real historical data and known outcomes.

    • Simulation uses assumed or generated scenarios, which may or may not match actual past conditions.

    • Validation is broader and may include back-testing, live testing, and review of data quality and assumptions.

    • Benchmarking compares performance against a reference or peer, rather than replaying history through a model.

    In finance, back-testing is strongly associated with investment strategy evaluation. In manufacturing and industrial analytics, the term more commonly refers to replaying historical operational data to evaluate detection logic, forecasts, or decision rules.

  • Spurious correlation

    Spurious correlation commonly refers to an apparent relationship between two variables that looks statistically meaningful but does not reflect a true underlying connection. The pattern may appear in charts, reports, or analytics outputs even when one variable does not meaningfully influence the other.

    In manufacturing and industrial operations, spurious correlation can appear when teams compare process, quality, maintenance, or production data and find a pattern that is coincidental, indirect, or caused by an unobserved third factor. For example, a plant may see a correlation between operator shift and defect rate, but the real driver could be product mix, machine condition, inspection timing, or missing data.

    A spurious correlation is not the same as proven causation. It also does not automatically mean the data is wrong. It means the observed association may be misleading if used without validation, domain context, or control for confounding factors.

    How it shows up in operations and systems

    • BI dashboards showing two KPIs moving together over time

    • MES, ERP, or historian data merged without enough context about timing, routing, or lot structure

    • Quality investigations that rely on trend matching alone

    • Predictive analytics or machine learning models that select variables with statistical signal but low operational meaning

    Common causes include small sample sizes, seasonal patterns, shared time trends, poor data alignment, hidden variables, and repeated slicing of data until a pattern appears.

    Common confusion

    Spurious correlation is often confused with correlation in general. Correlation only describes that variables move together; it does not explain why. It is also different from a root cause. A root cause is a validated explanation for an observed effect, while a spurious correlation is an association that may not hold up under deeper analysis.

    It can also be confused with confounding. Confounding is one common reason a correlation becomes spurious, but the terms are not identical. Confounding refers specifically to a third factor that distorts the observed relationship.

    Why the term matters

    In regulated and quality-sensitive environments, decisions based on spurious correlation can distort investigations, escalation priorities, process adjustments, and reporting. The term is commonly used as a caution in analytics, continuous improvement, and performance monitoring to distinguish observed signal from validated operational cause.

  • ISO/IEC 27001:2022

    ISO/IEC 27001:2022 is the 2022 edition of the international standard that specifies requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). It provides a structured framework for managing information security risks for all types of organizations, including manufacturers operating regulated production and OT/IT environments.

    The standard covers how an organization defines the scope of its ISMS, assesses information security risks, selects and applies controls, and monitors performance and improvement. It is technology neutral and can be applied to on-premises systems, cloud services, operational technology (OT), and integrated IT/OT architectures.

    Key elements

    ISO/IEC 27001:2022 commonly refers to:

    • ISMS requirements: Clauses that define management-system practices such as context, leadership, planning, support, operation, performance evaluation, and improvement.
    • Annex A reference controls: A catalog of information security controls organized into themes such as organizational, people, physical, and technological controls. These are references for risk treatment, not a mandatory checklist.
    • Risk-based approach: The requirement to identify information security risks, define risk criteria, choose treatments, and document decisions in a statement of applicability.
    • Continuous improvement: Expectations for monitoring, internal audits, management review, and corrective actions to keep the ISMS effective and up to date.

    Use in industrial and regulated manufacturing environments

    In manufacturing, ISO/IEC 27001:2022 is commonly used to structure information security around systems such as MES, ERP, historians, lab systems, and OT networks. Typical applications include:

    • Defining how access to production and quality systems is governed and logged.
    • Aligning network segregation, remote access, and patching practices for OT assets with formal risk assessments.
    • Coordinating information security with quality management, document control, and audit readiness processes.
    • Supporting supplier and customer expectations around information security governance, without implying any specific certification outcome.

    Relation to other ISO/IEC 27000-series documents

    ISO/IEC 27001:2022 sits within the broader ISO/IEC 27000 family of information security standards. For example:

    • ISO/IEC 27002 provides guidance on implementing controls conceptually aligned with the Annex A controls of ISO/IEC 27001:2022.
    • Other 27000-series documents address topics such as OT security, incident management, and sector-specific guidance.

    Organizations often use 27001 as the management-system core and reference additional 27000-series standards for more detailed practices.

    Common confusion

    • Standard vs. certification: ISO/IEC 27001:2022 is a written standard. Certification is a separate process conducted by external bodies. The term “ISO 27001” is often used loosely to mean both, which can cause misunderstanding.
    • “Four categories” of controls: Training materials sometimes group Annex A controls into a small number of categories for teaching purposes. ISO/IEC 27001:2022 itself defines its own control structure and naming; it does not formally define a “four category” model.
    • 27001 vs. 27002: ISO/IEC 27001:2022 defines ISMS requirements and references control themes. ISO/IEC 27002 provides detailed implementation guidance for controls. They are related but not interchangeable.

    Context of the 2022 edition

    The 2022 edition updates and replaces earlier editions of ISO/IEC 27001. It aligns its Annex A controls with the revised ISO/IEC 27002 structure, streamlines and renames several controls, and reflects current practices in areas such as cloud services and modern networked environments. When organizations refer to “ISO 27001” in current projects or contracts, they often mean ISO/IEC 27001:2022 unless an earlier edition is explicitly specified.

  • Concession Volume

    Concession volume commonly refers to the quantity of material, parts, assemblies, or finished units covered by an approved concession. In manufacturing and quality contexts, a concession is a documented acceptance of a specified nonconformance under defined conditions, and the concession volume sets the numerical scope of that acceptance.

    This term helps define boundaries. It indicates how many affected items may be shipped, used, processed, or accepted under the concession. It does not, by itself, describe the technical deviation, the reason for acceptance, or the disposition decision criteria. Those details are usually recorded elsewhere in the concession or related quality records.

    How it is used in operations

    In practice, concession volume may appear as a count of pieces, batches, serial-numbered units, lots, or another controlled quantity measure. The exact unit depends on how the product is identified and controlled in the organization.

    • For discrete manufacturing, it may be the number of parts or assemblies covered.

    • For lot-controlled material, it may be a lot, batch, or a defined subset of that lot.

    • For serialized products, it may refer to specific serial numbers rather than a general count.

    Systems such as QMS, MES, or ERP may reference concession volume when tracking nonconforming product, release decisions, genealogy, and downstream use restrictions.

    What it includes and excludes

    Concession volume includes only the quantity explicitly authorized by the approved concession. It does not automatically extend to future production, similar parts, or additional nonconforming units unless those are also documented and approved.

    It also should not be confused with broader production volume, shipment volume, rework volume, or scrap volume. The term is limited to the quantity within the approved scope of concession treatment.

    Common confusion

    Concession volume is often confused with concession rate or concession frequency. Concession volume is the amount of product covered by a specific concession, while concession rate refers to how often concessions occur or what share of output they represent.

    It can also be confused with deviation quantity. In some organizations the terms are used similarly, but a deviation often refers to permission before manufacture or processing, while a concession commonly refers to acceptance of a known nonconformance after it exists. Usage varies by company and industry.

    Example

    If 25 parts in a lot have a minor documented nonconformance and quality approval allows those 25 specific parts to be accepted for use, the concession volume is 25 parts, not the full lot unless the full lot is explicitly included.

  • Mapping table

    A mapping table is a structured list that shows how one set of values, fields, identifiers, or codes corresponds to another set. In manufacturing and enterprise systems, it commonly refers to configuration or reference data used to translate information between applications, data models, or process steps.

    A mapping table can be as simple as linking an ERP item code to an MES material identifier, or as detailed as converting defect codes, unit-of-measure values, work center names, status codes, or supplier IDs across systems. It is used to support consistent data exchange, reporting, and system interoperability.

    What it includes

    • Field-to-field relationships between systems

    • Code translations, such as status, reason, defect, or location codes

    • Value normalization rules, such as standard names or approved abbreviations

    • Cross-reference records used in integrations, migrations, or reporting layers

    What it does not mean

    A mapping table is not the same thing as the integration logic itself. It usually holds the reference relationships that the integration, ETL process, middleware, MES, ERP, or analytics layer uses. It is also not necessarily a full data model, master data record, or transaction history.

    Operational meaning in manufacturing systems

    In regulated and multi-system environments, mapping tables often appear wherever data must stay aligned across MES, ERP, PLM, QMS, LIMS, or warehouse systems. Examples include mapping part revisions between PLM and ERP, associating shop-floor equipment IDs with enterprise asset records, or translating nonconformance codes into reporting categories.

    Because mapping tables influence how records are interpreted, they are often treated as controlled configuration data. Changes to them can affect traceability, reporting consistency, interface behavior, and downstream business rules.

    Common confusion

    Mapping tables are commonly confused with lookup tables, crosswalks, and master data:

    • Lookup table: usually provides allowed values or descriptive labels within one system.

    • Crosswalk: often means a direct correspondence list between two coding schemes and may be used as a synonym for mapping table.

    • Master data: is the authoritative business data itself, while a mapping table links or translates between representations of that data.

  • Labeling

    Labeling commonly refers to the process of creating, approving, printing, and applying identifiers or required information to materials, components, finished goods, samples, containers, and shipping units. In manufacturing and regulated operations, a label is not just a sticker or printed tag. It is a controlled carrier of information used to identify an item, communicate status, support handling, and maintain traceability.

    Depending on the operation, labeling can include human-readable text, barcodes, 2D codes, serial numbers, lot or batch numbers, part numbers, revision levels, dates, storage conditions, quality status, and shipping data. The term can apply to both physical labels and directly marked identifiers when they serve the same operational purpose.

    What it includes

    • Item, material, lot, batch, or serial identification
    • Status labels such as quarantine, accepted, rejected, or in-process
    • Packaging and shipping labels
    • Work-in-process and kitting labels
    • Labels generated from ERP, MES, WMS, LIMS, or quality systems
    • Controlled templates, approval logic, and print records where used

    What it does not mean

    Labeling does not usually mean product branding, marketing design, or consumer-facing package artwork unless the discussion is specifically about commercial packaging operations. In industrial settings, the term usually refers to operational identification and traceability rather than promotional labeling.

    Operational meaning

    In day-to-day workflows, labeling appears at receiving, inventory moves, production issue, kitting, work order execution, inspection, nonconformance handling, packaging, and shipment. A labeling process may pull master and transaction data from business or shop-floor systems so that the label reflects the current item identity and status. Because labels often drive scanning and downstream decisions, errors in labeling can affect traceability, inventory accuracy, routing, and release controls.

    For example, a lot label on raw material may link the received material to supplier data and inspection status, while a finished-goods label may carry serial, revision, and shipment information needed by downstream systems.

    Common confusion

    Labeling is often confused with marking, identification, and packaging.

    • Labeling usually means applying a separate information carrier such as a printed label or tag.
    • Marking often refers to direct identification placed on the item itself, such as laser etching or ink marking.
    • Identification is broader and includes any method used to distinguish an item, whether by label, mark, record, or system reference.
    • Packaging refers to the physical containment or protection of goods, while labeling communicates information on or with that package.

    Why it matters in regulated manufacturing

    In regulated and quality-controlled environments, labeling is commonly tied to document control, revision management, approved data sources, and traceability records. The exact content and control level vary by industry, process, and product risk, but the general purpose remains consistent: to ensure the right item carries the right information at the right point in the workflow.

  • Formula versioning

    Formula versioning is the controlled tracking and management of changes to a manufacturing formula over time. A formula version identifies a specific approved or recorded state of a recipe, blend, bill of ingredients, or process formula so the organization can distinguish one definition from another.

    In manufacturing, this commonly includes changes to ingredient or material quantities, units of measure, processing parameters, yield assumptions, substitutions, specifications, effective dates, and approval status. It may also include links to related records such as work instructions, quality documents, ERP or MES master data, and change control records.

    Formula versioning is not the same as simply overwriting a formula master record. The key distinction is that prior states remain identifiable, and each version can be tied to when it was created, who changed it, why it changed, and where it was used. In regulated or traceability-sensitive environments, this supports consistent execution, review, and historical reconstruction.

    How it appears in operations

    Formula versioning often appears in ERP, MES, LIMS, PLM, or quality systems as version numbers, revisions, effective dates, status labels, and approval workflows. For example, a plant may release a new formula version for a coating mix with an updated solvent ratio while keeping the prior version available for historical batch records and investigation.

    • Current version: the formula presently released for use
    • Pending version: a change under review or not yet effective
    • Obsolete or retired version: no longer released for execution but retained for history
    • Effective dating: controls when a version may be used in production

    What it includes and excludes

    Formula versioning commonly refers to the version control of product formulations or process formulas used to manufacture a material or product. It may apply to discrete, batch, and process manufacturing, especially where composition matters.

    It does not usually mean versioning of every related document or every production instruction, although those items may be governed alongside the formula. A formula version can be linked to document revisions, but it is not identical to document control in general.

    Common confusion

    Formula versioning vs. recipe versioning: These terms are sometimes used interchangeably, but they are not always identical. A formula usually focuses on composition or material relationships, while a recipe may also include sequence, timing, equipment steps, and execution logic.

    Formula versioning vs. BOM revision: A bill of materials revision is usually associated with product structure in discrete manufacturing. A formula version is more often used where proportions, yields, or batch scaling are central.

    Formula versioning vs. document revision control: Document revision control manages files such as SOPs or specifications. Formula versioning manages the manufacturing definition itself, even when related documents are attached.

  • Shadow mode

    Shadow mode commonly refers to operating a new system, application, model, rule set, or workflow in parallel with a live production process while preventing it from directly affecting real-world outcomes. It allows the new logic to observe the same inputs as the active system and produce outputs for comparison, validation, or monitoring, but those outputs are not used to control equipment, release transactions, or make official process decisions.

    In manufacturing and regulated operations, shadow mode is often used when introducing analytics, scheduling logic, alerting rules, inspection models, MES changes, or integrations between OT and IT systems. For example, a new downtime-classification model might process live machine events and generate classifications in the background while the current reporting method remains the official source.

    What it includes

    • Parallel processing of live or near-live data
    • Output generation for comparison, testing, or performance evaluation
    • Isolation from production actions such as equipment control, inventory updates, quality disposition, or official record changes
    • Use during rollout, validation, tuning, or migration activities

    What it does not mean

    Shadow mode does not usually mean that a system is partially controlling production. If the new system can directly trigger actions, write to the system of record, or change operator instructions in effect, it is generally no longer operating only in shadow mode. It is also not the same as a software sandbox with synthetic data, because shadow mode typically uses real operational inputs.

    Common confusion

    Shadow mode is commonly confused with pilot, simulation, and parallel run.

    • Pilot: a limited live deployment where the new system may actually be used in production for a subset of lines, users, or processes.
    • Simulation: testing with modeled or historical data rather than live production inputs.
    • Parallel run: can mean two systems are both active for business continuity, and in some organizations both may influence operations. Shadow mode usually implies the new side is non-controlling.

    Operational relevance

    In plant and enterprise systems, shadow mode is used to compare outputs before cutover, measure variance from current logic, detect data-mapping issues, and understand whether a new process would behave acceptably under real conditions. It can apply to MES workflows, ERP integrations, quality event classification, predictive maintenance alerts, scheduling recommendations, and other decision-support or execution-adjacent functions.

    Because definitions vary by team, organizations often document exactly what is shadowed, what data is read, what outputs are stored, and which systems remain authoritative during the shadow period.