Connect981 – Content Dev

Glossary Tag: risk detection

  • cloud service provider

    A cloud service provider is an organization that delivers computing resources over a network from shared cloud infrastructure. These resources can include servers, storage, databases, networking, applications, and security services that customers access remotely rather than operating on their own on-premises hardware.

    Scope and types of cloud service providers

    In industrial and manufacturing environments, cloud service providers commonly offer:

    • Infrastructure as a Service (IaaS): Virtual machines, storage, and networking used to host MES, data historians, or analytics platforms.
    • Platform as a Service (PaaS): Managed databases, event streams, and application platforms used to build custom manufacturing or quality applications.
    • Software as a Service (SaaS): Hosted applications such as quality management systems, electronic logbooks, maintenance systems, or production analytics tools.

    The provider owns and operates the underlying data centers, hardware, and core software platforms, and is responsible for base-level security, availability, and capacity of those services. Customers retain responsibility for how they configure, use, and validate those services within their regulated manufacturing processes.

    Operational meaning in regulated manufacturing

    In regulated industrial operations, a cloud service provider typically:

    • Hosts production, quality, engineering, and supply chain applications or data services used by plants and corporate teams.
    • Implements technical controls such as identity and access management, logging, encryption, and network segregation.
    • Provides audit logs, configuration options, and documentation that customers may use as part of their own validation, cybersecurity, and compliance programs.
    • May align with reference frameworks (for example, FedRAMP baselines or similar security programs) without removing the customer’s need for plant-level validation, integration testing, and supplier oversight.

    Cloud service providers are usually managed as critical suppliers or vendors, with contracts, service-level expectations, and security assessments governed by the manufacturer’s supplier management process.

    Common confusion

    • Cloud service provider vs. SaaS vendor: A SaaS vendor delivers a specific application over the cloud. That vendor may itself rely on another underlying cloud service provider for infrastructure.
    • Cloud service provider vs. hosting provider: Traditional hosting providers may offer fixed servers with limited self-service capabilities. Cloud service providers generally offer elastic, programmable infrastructure and standardized services (APIs, managed databases, etc.).

    Relation to security frameworks such as FedRAMP

    Some cloud service providers offer services that align with government or industry security frameworks. In manufacturing, these services are often selected for handling sensitive technical data, production records, or quality documentation. Such alignment usually indicates a defined set of security and control practices at the provider level, but it does not, by itself, establish compliance for a specific plant, product, or process. Organizations still need to perform their own risk assessments, validation, and ongoing oversight of the provider.

  • Boundaries and Applicability

    Boundaries and Applicability commonly refers to the explicit definition of what a system, process, requirement, or assessment covers, where it applies, and what is out of scope. In industrial and regulated manufacturing environments, it is used to avoid ambiguity about responsibilities, system coverage, and regulatory obligations.

    Core meaning

    When organizations describe boundaries and applicability, they are usually addressing two related questions:

    • Boundaries: The scope limits of something, such as a production process, OT/IT system, quality procedure, or risk assessment. This often includes which sites, lines, products, data flows, or functions are included or excluded.
    • Applicability: The situations, conditions, or entities to which a requirement, standard, control, or procedure applies. This may reference product families, process steps, regulatory classifications, or system configurations.

    Together, boundaries and applicability clarify the domain in which certain rules, controls, or behaviors are expected, and where they are not.

    Operational context in manufacturing

    In industrial and regulated settings, boundaries and applicability are typically documented in:

    • Quality and compliance procedures: Defining which plants, product ranges, or process variants a SOP covers, and which are explicitly excluded.
    • MES/ERP and OT/IT system descriptions: Stating which production areas, equipment, data types, and interfaces are within the scope of a system implementation or change, and which remain out of scope.
    • Risk, safety, and cybersecurity assessments: Describing the physical and logical boundaries of the system or process being analyzed, and the assets, networks, and users to which controls apply.
    • Regulatory and standards alignment: Explaining when specific regulatory requirements or industry standards apply to a product, process, or site based on criteria such as market, classification, or customer requirements.

    Clear boundaries and applicability help avoid overlap or gaps between systems and procedures, reduce conflicting instructions, and support consistent application of controls and records across sites and lines.

    What it typically includes

    Well defined boundaries and applicability statements often specify:

    • Physical scope: Sites, buildings, areas, production lines, equipment, or utilities.
    • Organizational scope: Departments, roles, or functions responsible or affected.
    • Process and product scope: Process steps, product families, variants, or batches covered.
    • System and data scope: Applications, interfaces, data types, and environments (e.g., test vs production).
    • Temporal scope: When the definition applies, such as effective dates or lifecycle phases.
    • Explicit exclusions: Items or situations that are intentionally left outside the scope.

    Common confusion

    • Scope vs. boundaries and applicability: “Scope” is often used as a single word for what is covered. “Boundaries and applicability” is a more explicit way to describe scope limits (boundaries) and the conditions or entities to which something applies (applicability).
    • Requirements vs. applicability: A requirement describes what must be done; applicability describes when, where, or to whom that requirement is relevant.

    Use in documentation and audits

    In procedures, system descriptions, validation packages, and risk assessments, a dedicated section on boundaries and applicability is often used to:

    • Clarify which operations and systems are covered by the document or activity.
    • Support consistent interpretation during internal reviews and external audits.
    • Provide a reference when evaluating change impact, nonconformances, or deviations.

    This term is descriptive and does not imply any specific standard or regulatory framework, but it is commonly used in quality systems, safety management, and OT/IT governance documentation.

  • IT–OT convergence

    IT–OT convergence commonly refers to the intentional integration and coordination of information technology (IT) systems with operational technology (OT) systems in industrial and manufacturing environments. It focuses on treating business information systems and plant-floor control systems as a connected ecosystem rather than separate technology stacks.

    What IT–OT convergence includes

    In regulated and industrial operations, IT–OT convergence typically includes:

    • Connecting enterprise IT systems (such as ERP, PLM, LIMS, and quality systems) with plant-floor OT systems (such as PLCs, DCS, SCADA, historians, and MES).
    • Aligning data models, standards, and interfaces so production, quality, maintenance, and business data can be exchanged and used consistently.
    • Coordinating governance, cybersecurity policies, and change control across both IT and OT environments.
    • Implementing shared architectures and platforms, for example using industrial networks, edge computing, and secure gateways to bridge plant and enterprise networks.
    • Defining joint roles and responsibilities for IT and OT teams, including support, incident response, and lifecycle management for shared systems.

    IT–OT convergence is not a single product or standard. It is a combination of architecture, integration approaches, and organizational practices that connect technology and data across traditional IT and OT boundaries.

    Operational meaning in manufacturing

    At an operational level, IT–OT convergence shows up in activities such as:

    • Integrating MES and ERP so production orders, material data, and quality results flow automatically between business and shop-floor systems.
    • Streaming data from sensors, controllers, and historians into analytics, reporting, and operations-intelligence platforms managed by IT.
    • Applying unified access control, patching, backup, and monitoring practices to both servers in the data center and industrial devices on the plant floor, with appropriate OT-specific constraints.
    • Supporting traceability and genealogy requirements by combining equipment event data with batch records, electronic device history records, or electronic batch records.

    Common confusion

    IT–OT convergence is often discussed alongside related concepts:

    • Industry 4.0 / smart manufacturing: IT–OT convergence is one enabling aspect of these initiatives but is more specific, focusing on how IT and OT systems and teams connect and collaborate.
    • IIoT (Industrial Internet of Things): IIoT emphasizes connected devices and data collection. IT–OT convergence is broader and includes governance, organizational integration, and enterprise-to-plant processes, not just device connectivity.
    • Network convergence: Combining IT and OT networks is one technical element of IT–OT convergence, but the term also covers applications, data, security practices, and organizational alignment.

    Relevance in regulated and compliant environments

    In regulated manufacturing, IT–OT convergence is closely linked to topics such as:

    • Data integrity and consistent handling of electronic records across enterprise and plant-floor systems.
    • Coordinated cybersecurity controls for both IT and OT assets, often aligned with industrial security standards.
    • Change management and validation practices that span MES, ERP, control systems, and interfaces between them.
    • Audit readiness, where evidence may rely on data and logs from both IT and OT systems.

    When planned and governed appropriately, IT–OT convergence provides a structured way to treat industrial control systems and enterprise information systems as parts of a single, managed operational ecosystem.

  • Tier-1 supplier

    A Tier-1 supplier is a company that delivers products, assemblies, or services directly to an original equipment manufacturer (OEM). In industrial and regulated manufacturing environments, Tier-1 suppliers typically provide complex, production-ready components or systems that integrate parts, materials, or services from lower-tier suppliers.

    Key characteristics of a Tier-1 supplier

    In most manufacturing supply chains, a Tier-1 supplier:

    • Has a direct commercial relationship with the OEM, including contracts, purchase orders, and direct performance reporting.
    • Delivers parts, assemblies, software, or services that are installed on, or directly support, the OEM’s final product.
    • Often manages and coordinates a network of Tier-2 and lower-tier suppliers that provide subcomponents, raw materials, or specialized processing.
    • Is usually responsible for meeting defined quality, traceability, and regulatory requirements set by the OEM and applicable standards.
    • May participate in design collaboration, change management, and advanced quality planning with the OEM.

    Operational role in industrial and regulated environments

    Within industrial operations, Tier-1 suppliers are often treated as strategic partners because their performance directly affects the OEM’s production, compliance posture, and delivery schedules. Typical operational responsibilities include:

    • Maintaining process controls and quality systems that satisfy OEM and industry standards.
    • Providing required documentation, such as certificates of conformance, inspection records, and traceability data.
    • Coordinating logistics, advanced shipping notices, and packaging requirements aligned with the OEM’s receiving and MES/ERP processes.
    • Managing sub-tier suppliers and outsourced processing to ensure end-to-end material and process traceability.

    What Tier-1 supplier does and does not include

    • Includes: Direct suppliers to the OEM that provide finished parts, integrated assemblies, major subsystems, software, or critical services (such as specialized testing or overhaul) tied to the final product.
    • Excludes: Suppliers that only provide inputs to other suppliers (Tier-2, Tier-3, etc.) and do not have a direct contractual or delivery relationship with the OEM.

    Common confusion

    • Tier-1 vs Tier-2 supplier: A Tier-2 supplier typically delivers to a Tier-1, not to the OEM. Tier-1 integrates and delivers to the OEM.
    • Tier-1 vs strategic supplier: Some OEMs call high-impact suppliers “strategic” regardless of tier. A Tier-1 designation is about position in the supply chain, not necessarily strategic importance.
    • Tier-1 vs prime contractor: In defense and aerospace, the prime contractor is often the OEM. Tier-1 suppliers deliver directly to the prime but are not the prime contractor themselves.

    Examples in manufacturing

    • An aerospace structures company that delivers fully assembled wings directly to an aircraft OEM is a Tier-1 supplier, even though it buys materials and machined parts from multiple Tier-2 and Tier-3 suppliers.
    • An electronics manufacturer providing certified avionics units directly to an aircraft or defense OEM, integrating circuit boards and software from lower-tier suppliers, is also a Tier-1 supplier.

  • Critical-to-Quality (CTQ)

    Core meaning

    Critical-to-Quality (CTQ) commonly refers to a product, service, or process characteristic that must meet a defined, measurable target to satisfy customer, user, or regulatory quality requirements.

    In industrial and regulated manufacturing environments, CTQs translate high-level needs (for example, safety, efficacy, reliability, or usability) into specific, observable measures that can be designed, controlled, and monitored on the shop floor or in supporting systems.

    Typical attributes of a CTQ include:

    – It is directly traceable to a customer, patient, user, or regulatory need.
    – It is measurable with a clear unit, method, and frequency of measurement.
    – It has defined specification limits or acceptance criteria.
    – Its failure is considered significant from a quality, safety, or compliance standpoint.

    Use in manufacturing workflows

    In manufacturing operations and quality systems, CTQs are used to:

    – Define key product characteristics such as dimensions, purity, potency, or mechanical strength.
    – Identify key process parameters (KPPs) that strongly affect product quality, such as temperature profiles, line speed, fill volume, or torque.
    – Structure control plans, inspection plans, and in-process checks around the characteristics that matter most.
    – Configure MES, LIMS, SCADA, or historian tags to capture, store, and trend the data tied to CTQs.
    – Support deviation investigations, root cause analysis, and continuous improvement by focusing analysis on CTQ performance.

    CTQs are often documented in design specifications, control plans, product quality profiles, or process FMEAs, and then implemented as specific data fields, limits, or alarms within OT/IT systems.

    Boundaries and what CTQ is not

    A CTQ:

    – Is a selected subset of all possible characteristics; not every measured attribute is necessarily CTQ.
    – Is defined at a level that can be practically measured and controlled.
    – Is usually stable over time but may be revised when customer requirements, regulations, or product designs change.

    CTQ does **not** refer to:

    – General process performance metrics (for example, OEE, throughput, or uptime) unless explicitly linked to a critical quality requirement.
    – Generic quality system elements such as SOPs, training, or documentation, although these support achieving CTQs.

    Relationship to other quality concepts

    CTQs are often derived from higher-level requirements such as:

    – Voice of the customer (VOC) or user requirements.
    – Regulatory requirements, standards, or product registration dossiers.
    – Internal reliability or safety targets.

    They are closely related to, but distinct from:

    – **Critical Quality Attributes (CQAs):** Common in regulated industries, especially life sciences. CQAs are a formal subset of quality attributes that must be controlled within limits to ensure product quality. Many CQAs are CTQs, but CTQ is a broader, cross-industry term.
    – **Critical Process Parameters (CPPs) or KPPs:** Process inputs that significantly affect CTQs or CQAs. CPPs/parameters describe *how* the process runs; CTQs describe *what must be achieved* in the output.

    Common confusion and misuse

    – **”Everything is CTQ”:** Labeling too many metrics as CTQ weakens the concept. CTQs should be limited to the characteristics with the highest impact on customer or regulatory outcomes.
    – **Confusing CTQ with general KPIs:** KPIs such as cycle time or equipment utilization are important but are not CTQs unless tied directly to a critical quality requirement.
    – **Using CTQ only at design time:** In practice, CTQs should remain visible in daily operations through control charts, alarms, and reports, not just in design documents.

    Site context application

    Within industrial operations and manufacturing systems, CTQs are a bridge between requirements and execution:

    – Product and process CTQs are captured in specifications and quality risk assessments.
    – MES and quality systems implement CTQs as data fields, required checks, interlocks, and limits.
    – Operations intelligence tools monitor CTQ data to detect trends, support investigations, and inform improvement projects.

    This usage ensures that OT/IT systems focus on monitoring and controlling the characteristics that are most critical to compliant, reliable manufacturing outcomes.

  • Containment

    Core meaning

    Containment commonly refers to temporary actions taken to isolate, control, or limit the impact of a detected problem, nonconformance, or risk. In industrial and manufacturing environments this usually involves preventing suspect product, data, or processes from progressing further in the value stream until the issue is understood and longer‑term corrective actions are defined.

    Containment may apply to:
    – Physical product (e.g., batches, lots, units, materials)
    – Digital records (e.g., electronic batch records, MES transactions, quality data)
    – Processes or equipment (e.g., temporarily stopping, bypassing, or restricting use)

    It is generally time‑bound and scoped, and it does not by itself eliminate the underlying root cause.

    Use in manufacturing and regulated operations

    In regulated and quality‑critical manufacturing, containment is used when a deviation, defect, or process failure is detected or suspected. Typical activities include:

    – **Identifying scope of impact**: Determining which lots, batches, orders, time windows, or equipment may be affected.
    – **Isolating product**: Quarantining or blocking release of in‑process or finished goods, often through inventory holds in MES or ERP.
    – **Controlling process flow**: Stopping production, disabling specific routes or recipes, or adding additional checks at certain operations.
    – **Protecting downstream operations and customers**: Preventing suspect material from reaching subsequent process steps, customers, or patients.

    Containment is typically documented in deviation reports, nonconformance records, or CAPA workflows in quality systems.

    Containment in OT/IT and MES contexts

    In operations technology (OT) and manufacturing execution systems (MES), containment often appears as system‑enforced controls, for example:

    – **Hold statuses and quarantine**: Automatically putting lots, batches, or work orders on hold based on alarms, test failures, or operator input.
    – **Electronic segregation**: Routing suspect material to dedicated inspection or rework operations instead of normal processing.
    – **Access and usage restrictions**: Temporarily disabling recipes, equipment, or test plans in MES or related systems until an investigation is complete.
    – **Data containment**: Flagging or excluding suspect measurement data from release decisions, analytics, or compliance reports.

    Integration with ERP and quality management systems allows containment actions in one system (e.g., a quality hold) to propagate and block related transactions elsewhere.

    Boundaries and what containment is not

    Containment:
    – **Is**: A short‑term control to prevent further impact while an issue is being investigated.
    – **Is not**: The same as corrective action or preventive action; it does not remove the root cause.
    – **Is**: Often the first step after a problem is detected.
    – **Is not**: A permanent process change, redesign, or improvement strategy.

    In many formal problem‑solving methods, containment is required before root cause analysis proceeds, to ensure ongoing production does not worsen the situation.

    Common confusion and related terms

    – **Containment vs. correction**: Correction is the act of fixing a specific detected nonconforming item (e.g., reworking a defective unit). Containment is broader and focuses on controlling all potentially affected items or processes, including those not directly inspected.
    – **Containment vs. corrective action (CA)**: Corrective action addresses the root cause so the problem does not recur. Containment only limits immediate risk and may be removed once effective corrective actions are in place.
    – **Containment vs. preventive action (PA)**: Preventive action addresses potential problems that have not yet occurred. Containment reacts to a problem that is already known or suspected.

    Recognizing these distinctions is important for accurate use of quality system terminology and for structuring investigations and documentation.

    Use in risk and safety management

    In a broader risk and safety context, containment can also describe:

    – **Physical containment**: Using barriers, enclosures, or zones to confine hazards (e.g., chemicals, biologics, energized equipment) to controlled areas.
    – **Procedural containment**: Implementing temporary work instructions, access controls, or emergency measures to prevent hazard propagation.

    In regulated environments, such measures are often linked to formal risk assessments and incident management processes.

  • corrigendum

    A corrigendum is an officially published correction to an existing document, such as an international standard, regulation, technical report, or specification. In industrial and regulated environments, it commonly refers to a correction issued by a standards body or publisher to fix identified errors without republishing the entire document as a new edition.

    What a corrigendum includes

    A corrigendum typically addresses issues such as:

    • Typographical or formatting errors that may affect interpretation
    • Incorrect references, figures, tables, or cross-references
    • Minor technical errors, such as mis-stated parameter values, variable names, or units
    • Clarifications where the original wording is misleading or internally inconsistent

    The corrigendum is normally published as a short stand-alone document that specifies exactly what text, figure, or reference is replaced, deleted, or inserted in the original document.

    What a corrigendum does not usually cover

    A corrigendum generally does not introduce major new requirements, restructure the document, or change the overall scope or concept of the standard or procedure. Substantive changes of that kind are more often handled in separate amendments or full revisions.

    Operational meaning in industrial and regulated environments

    In manufacturing, OT/IT, and quality-managed environments, corrigenda are part of document control and standards management. Typical impacts include:

    • Tracking which standards and technical documents are in use, including their edition and any corrigenda applied
    • Updating internal procedures, specifications, or system configurations when a corrigendum corrects a value or requirement that affects operations
    • Adjusting validation, verification, or test documentation if a corrected requirement changes acceptance criteria or calculations
    • Maintaining evidence that the organization is aware of and has evaluated relevant corrigenda as part of change control

    For example, if a cybersecurity standard used for OT system design issues a corrigendum that corrects a misprinted network security parameter, engineering and compliance teams may need to review configurations, risk assessments, and related work instructions.

    Relationship to amendments and revisions

    Standards and formal documents may evolve through several mechanisms:

    • Corrigendum: Corrects identified errors or inconsistencies, usually without changing the overall technical intent.
    • Amendment: Adds, removes, or modifies specific requirements or sections, often to address new technology, practices, or interpretations.
    • Revision (new edition): Replaces the previous edition and may significantly restructure or expand the content.

    Organizations that rely on external standards for MES/ERP integration, automation, safety, or quality should track all three types of changes as part of formal document control.

    Common confusion

    • Corrigendum vs. errata: In some publishing contexts, errata are informal or publisher-level error lists, while a corrigendum is an official, controlled correction issued under the same governance as the original document. Usage can vary by organization.
    • Corrigendum vs. amendment: A corrigendum focuses on corrections to what should have been in the original document. An amendment intentionally changes or adds content after publication.

    Link to standards such as IEC 62443

    For standards like IEC 62443, individual parts may remain in force for many years while receiving targeted corrigenda and amendments. Plants and system integrators that reference specific parts of such standards in their OT cybersecurity, validation, or quality systems often need to:

    • Record the exact part, edition, and any associated corrigenda or amendments
    • Assess whether corrections affect existing designs, risk assessments, or controls
    • Apply change control and revalidation processes when necessary

    In this context, a corrigendum is treated as an official change record that must be evaluated and, when relevant, incorporated into controlled documentation and systems.

  • Pilot phase

    A pilot phase is a limited, controlled trial period used to test a new process, system, product change, or operating method before broader rollout. In manufacturing and regulated operations, it commonly refers to a planned introduction in a narrow scope such as one line, one site, one product family, or a small user group.

    The purpose of a pilot phase is to observe how something performs under real operating conditions while containing impact, cost, and disruption. It is not the same as full production deployment, and it is not just a lab test or a software sandbox. A pilot typically uses actual workflows, users, and operational data, but within defined boundaries.

    What it usually includes

    • A defined scope, such as a single workcell, shift, supplier, or department

    • Specific objectives and success criteria

    • Monitoring of performance, usability, data quality, and process fit

    • Documentation of issues, deviations, and change requests

    • A decision point on whether to expand, revise, pause, or stop the rollout

    How it appears in operations

    In practice, a pilot phase may be used for MES deployment, digital work instructions, new inspection workflows, ERP-MES integration changes, automation projects, traceability enhancements, or revised standard work. For example, a plant may pilot electronic batch or routing records on one production line before extending them across the facility.

    In regulated environments, the pilot phase is often managed with tighter change control, documented scope limits, and closer review of evidence generated during the trial. The term itself does not imply approval, validation, or permanent release. Those outcomes depend on the organization’s own processes and requirements.

    Common confusion

    Pilot phase is often confused with proof of concept, prototype, and beta test.

    • A proof of concept is usually earlier and narrower, focused on whether an idea can work at all.

    • A prototype is an early model or draft version, often not used in live operations.

    • A beta test is more common in software and often emphasizes user feedback before general release.

    • A pilot phase usually sits closer to real operations and is meant to test readiness for scaled use.

    What it does not mean

    A pilot phase does not automatically mean a process is production-ready, compliant, validated, or standardized across the organization. It also does not require that every feature or workflow be final. Its main role is to reduce uncertainty before a larger commitment is made.

  • raw data

    Raw data commonly refers to unprocessed values captured directly from a source, such as sensors, machines, operator inputs, or IT/OT systems, before those values are cleaned, transformed, aggregated, or interpreted.

    What raw data includes

    In industrial and manufacturing environments, raw data typically includes:

    • Time-stamped sensor readings (for example, temperature, pressure, speed)
    • Machine status codes and event logs from PLCs, SCADA, or MES
    • Unaggregated production counts, scrap counts, and cycle times
    • Operator entries such as checklists, comments, or manual measurements
    • Transaction-level records from MES, ERP, LIMS, or quality systems

    Raw data is usually stored in historians, databases, log files, or message streams before any significant business logic is applied.

    What raw data does not include

    Raw data does not include values that have been substantially processed or interpreted, such as:

    • Indicators that combine multiple raw data points into a single derived metric
    • Key performance indicators (KPIs) such as OEE, on-time delivery, or defect rate
    • Aggregated reports (for example, hourly, shift, daily summaries)
    • Statistical calculations like averages, control limits, or capability indices

    Once rules, calculations, or contextual enrichment are applied, the result is no longer considered raw data, even if the original values are retained.

    Operational role in manufacturing systems

    In OT and IT environments, raw data is the foundation for monitoring, analysis, and compliance activities. It is:

    • The input to indicators and KPIs used in performance dashboards and reports
    • The evidence base for traceability, genealogy, and deviation investigations
    • The feedstock for advanced analytics, such as predictive maintenance models
    • A key element of data integrity and audit trails in regulated operations

    Effective governance often distinguishes raw data from transformed data so that users understand which values are directly measured and which are calculated or modeled.

    Relation to ISO 22400 concepts

    In the context of ISO 22400, raw data corresponds to basic measurements captured from equipment and systems. These measurements can then be transformed into indicators by adding calculations or context, and a subset of those indicators may be designated as KPIs for operational or business decision-making. The standard emphasizes structural distinctions but does not, by itself, guarantee how any site defines or governs its raw data.

    Common confusion

    • Raw data vs. indicators: Indicators typically aggregate or calculate values from raw data and may include business rules or contextual information, while raw data remains as-captured.
    • Raw data vs. logs: Logs are often collections of raw data, but a log file may also contain derived or formatted entries; individual log entries can still be raw data if they directly reflect unprocessed measurements or events.
    • Raw data vs. cleansed data: Once data has been filtered, corrected, or normalized, it is no longer strictly raw, even if it retains the same basic structure as the original measurements.