Contextualize: Turning data into understandable operational information

As laid out in the first post in the series, connecting your manufacturing systems is an essential first step toward data-driven and Agentic industrial operations. It allows information from machines, control systems, historians, MES platforms, laboratory systems and enterprise applications to move beyond the systems in which it was created. But making industrial data available does not automatically make it understandable, trustworthy or useful.

A temperature value may arrive in real time, but a consuming application still needs to know which asset produced it, where that asset is located, which process it supports, which batch or order was running, what material was being processed, and whether the value meets the required quality standard.

This is the purpose of the Contextualize stage: to turn raw, connected industrial data into governed operational information that people, applications, analytics and AI agents can interpret consistently.

The objective is to establish a shared representation of your manufacturing operations that reflects the relationships between assets, processes, products, materials, facilities and business outcomes.

This shared representation is centered around two complementary views of the same operational data:

• The Unified Namespace provides a hierarchical, event-driven view, organizing information according to structures such as enterprise, site, area, line and asset. 

• The semantic graph provides a non-hierarchical, relationship-based view, capturing the many-to-many connections and dependencies across assets, processes, materials, products, facilities and business systems.

Together, these dimensions provide the context and governance needed to establish trust in data before it reaches analytics, automation or AI.

Move from data availability to shared meaning

The Connect stage gives your systems access to operational data through a common real-time backbone. However, availability alone does not solve the problem of interpretation.

Different sites may use different names for the same type of asset. Two production lines may calculate the same operating state differently. A maintenance system may identify equipment using one naming convention while the MES, historian, and quality system use others.

Without a shared model, every consuming application must work out these relationships independently.

This produces several recurring problems:

• Analytics teams spend time cleaning and reconciling data before they can use it

• The same KPI is defined differently across sites

• Applications depend on undocumented naming conventions

• Data ownership and authority are unclear

• AI systems receive information without enough context to interpret it safely

You therefore need an information architecture that gives data a consistent structure and meaning before it is consumed downstream.

Build a unified namespace for operational structure

A Unified Namespace provides a shared, real-time representation of your manufacturing enterprise.

It organizes information into a consistent hierarchy and makes operational events and states accessible through a common namespace. Rather than requiring applications to query multiple source systems and reconstruct operational context, the namespace presents information according to an agreed enterprise model.

A typical hierarchy may reflect levels such as:

Enterprise → Site → Area → Line → Cell → Asset→ Sensor Data

Depending on your operations, you may also represent Production Orders, Batches, Process Phases, Materials, Recipes, Equipment States, Quality Events, Maintenance Conditions, Energy Consumption and Performance Indicators.

The purpose of the hierarchy is not merely to make MQTT topics look orderly. It is to provide a stable, shared structure through which systems can publish and consume operational information consistently.

For example, rather than exposing an isolated tag such as TT_101.PV, the value can be published as ProductTemperature within an operational hierarchy that identifies the site, production area, and process unit from which it originated. The payload can then provide additional context, such as the timestamp, measurement type, engineering unit, and data quality status.

This enables a consumer, such as an AI agent, to understand where the information came from and how it fits within the physical operation. The topic hierarchy, however, should not be expected to represent every possible relationship or dependency. This is where the semantic graph becomes important.

Use a semantic graph for richer relationships

A Unified Namespace is effective for organizing real-time information and expressing hierarchical relationships. Manufacturing operations, however, involve relationships that are not always hierarchical.

An asset may belong to one production line but support several products. A batch may use multiple materials, pass through different units, and generate quality results from several laboratory instruments. A process deviation may be associated with an equipment condition, a supplier lot, an operator action and a maintenance event.

These relationships form a network rather than a simple tree. A semantic graph allows you to represent that network explicitly.

This graph-based context makes it possible to navigate operational relationships without embedding every association in an individual application.

It also gives AI agents a more reliable basis for reasoning. Instead of receiving disconnected values, an agent can understand how an event relates to the asset, process, batch, material, quality requirement and business outcome involved.

Define your semantic data layer

A Unified Namespace and Semantic Graph become far more useful when built on a clearly defined semantic data layer.

Your semantic data layer should establish how your organization defines important concepts, how those concepts relate to one another and how they are represented as actual operational entities. It should consist of three connected elements:

1. A semantic model that defines your shared vocabulary

2. One or more ontologies that formalize specific operational domains

3. A knowledge graph that represents the actual instances and relationships in your operations

These elements should not be treated as separate modelling exercises. Together, they create the structure through which your systems, teams, and AI agents can interpret operational information consistently.

Establish a semantic model with a controlled vocabulary

Your semantic model establishes the common language used across the organization.

It defines your core business and operational terms, their meanings, and the expected relationships between them. Its purpose is to ensure that concepts such as equipment, work order, batch, material, product, process step, quality result or completion date have a consistent meaning across systems, sites and functions.

For example, your semantic model may establish that:

• An equipment item is a physical asset that performs or supports an operational function

• A work order is an authorized request to perform a defined activity

• A completion date refers to the date an activity was actually completed, rather than its scheduled completion date

• Production equipment is a specialized type of equipment

• A CNC machine, reactor or packaging machine is a more specific type of production equipment

This controlled vocabulary eliminates ambiguity and reduces the risk that different systems or teams use the same term to mean different things or different terms to describe the same thing.

You do not necessarily need to create this vocabulary from scratch.

Established standards such as ISA-95 provide commonly understood terminology for concepts such as enterprises, sites, areas, work centers, equipment, personnel, materials and production activities. Other standards and industry models may provide useful vocabulary for specific domains.

You can adopt these terms where they reflect your operations and extend them where your organization requires additional concepts. The goal is not to reproduce a standard in full, but to establish a shared language that your organization can apply consistently.

Create ontologies for your operational domains

Once you have defined your shared vocabulary, you can use it to create one or more ontologies.

An ontology provides a formal specification of a particular operational domain. It defines the types of entities that exist, their properties, the relationships between them, and any rules or constraints that apply.

A highly detailed ontology may appear comprehensive, but it can take years to design, validate and deploy. By the time it is complete, your processes, systems and requirements may already have changed.

Instead, begin with a minimal, reusable abstraction that captures the stable concepts and relationships shared across sites and functions, such as Site, Equipment, Work Order and Operator. You can then extend this foundation with domain-specific ontologies for areas such as Production, Quality, Maintenance and Supply Chain.

Each domain has its own information requirements and may represent the same concept at a different level of detail. The shared foundation ensures that these domain ontologies remain interoperable while still allowing each team to model the context it needs.

Discover and catalog your operational data

These ontologies can still interoperate because they are grounded in the same semantic model and controlled vocabulary. However, you should be careful not to model your entire enterprise in full complexity before delivering a practical use case.

Populate the ontology through a knowledge graph

The ontology defines the structure of your operational domain. The knowledge graph populates that structure with actual entities and relationships.

If your ontology defines that equipment has properties such as serial number, equipment type, location and operating status, the knowledge graph contains the real equipment instances, such as Reactor R-101 or Packaging Line 3.

If the ontology defines that an asset is located at a site, performs a process function, processes a material, or produces a measurement, the knowledge graph contains the specific relationships between those entities.

For example:

• Reactor R-101 is located in Production Area A

• Reactor R-101 performs Mixing

• Batch B-24017 runs on Reactor R-101

• Batch B-24017 consumes Material Lot M-8821

• Quality Result Q-771 evaluates Batch B-24017

This is where the abstract semantic structure becomes a concrete representation of your operational reality.

The knowledge graph should connect actual information from your MES, LIMS, CMMS, historian, ERP, Unified Namespace and other operational systems. It provides a navigable representation of how assets, processes, batches, materials, measurements, quality results and business outcomes relate to one another.

For an AI agent, this is especially important.

Rather than searching disconnected systems and attempting to infer relationships from names or timestamps, the agent can navigate explicit, governed connections between the entities involved. Your ontology defines which questions can be asked. Your knowledge graph provides the operational evidence needed to answer them.

Discover and catalog your operational data

You cannot govern or contextualize data that you do not know exists. Your architecture should therefore include mechanisms to discover and catalog operational data sources, schemas, topics, assets and relationships.

The catalog should help users answer practical questions such as what data exists for this asset or process, who owns the data or what transformations have been applied. This capability reduces the dependence on undocumented tribal knowledge and makes data more discoverable across the enterprise. 

For AI use cases, the catalog also helps establish whether the information available to an agent is complete, current and appropriate for the task.

Validate, transform and enrich data in motion

You also need to validate data as it moves through your architecture. Incoming events should be checked against the agreed interface contract. This can include detecting:

• Missing required fields

• Unexpected fields

• Incorrect data types

• Invalid units

• Out-of-range values

• Incorrect timestamps

• Unknown asset identifiers

• Unsupported schema versions

• Invalid topic structures

When a deviation is detected, your architecture should apply a defined response. Depending on the severity and use case, it may:

• Reject the message

• Quarantine it for review

• Route it to a deviation topic

• Transform it into a compliant format

• Add a data-quality indicator

• Notify the responsible owner

• Allow it to continue with a warning

• Prevent it from entering a quality-critical or AI-driven workflow

This prevents bad or inconsistent data from silently propagating into dashboards, analytics, models or automation. The goal is not to discard every imperfect value. It is to make data quality visible and apply controls appropriate to the risk.

Some source data will need to be transformed before it can conform to your enterprise information model. Transformation may include:

• Renaming fields

• Converting data types

• Standardizing units

• Aligning timestamps

• Mapping local asset names to enterprise identifiers

• Combining related source values

• Adding source-system metadata

You should apply these transformations through governed, reusable services rather than embedding different logic in every consuming application. This ensures that multiple applications receive the same interpretation of the same operational event.

Preserve metadata and lineage

Your consumers need to understand not only what a value is, but also where it came from and what happened to it before it reached them.

This means preserving metadata such as the source system, original source identifier, event and ingestion timestamps, data-quality status, schema version, transformation history, enrichment source, ownership, retention policy and security classification.

Lineage should allow you to trace an analytical result or AI-generated conclusion back to the operational evidence that supported it. In a quality scenario, for example, you may need to identify which process values were used, which batch and material records were included, which laboratory results were considered, what transformations were applied, which model or rule produced the finding, and whether any input carried a data-quality warning.

This level of traceability is essential for trusted decision-making and becomes even more important when an AI agent is involved in deviation investigation or quality assessment.

Govern change across the information model

Your manufacturing environment will continue to evolve. New assets will be commissioned, systems will be upgraded, topic structures and payloads will change, sites will adopt new applications and business requirements will develop over time.

Your governance model must therefore manage change without preventing progress.

You should define how new data products and schemas are proposed, reviewed, approved, versioned and introduced. You also need a clear approach for maintaining compatibility, retiring deprecated structures, notifying sites of changes, documenting local extensions, detecting namespace deviations and updating relationships in the semantic graph.

Automated deviation detection is especially valuable at enterprise scale. If a factory publishes an unexpected topic, omits a required field or introduces an unapproved asset name, the architecture should identify the issue early rather than allowing inconsistency to spread into downstream systems.

Governance should support reuse and interoperability, not become a centralized bottleneck. A federated model can allow sites and domain teams to manage their own extensions while operating within enterprise-wide standards and guardrails.

Create context that AI agents can trust

AI agents require more than access to large volumes of data. They need information that is structured, current, traceable, governed, semantically consistent, linked to the relevant operational entities, accompanied by quality and authority indicators, and constrained by appropriate access and usage policies.

An agent investigating a quality deviation should not have to infer that two differently named assets represent the same type of equipment, guess which system owns the approved batch record, or decide whether a missing field is meaningful. Those decisions should already be encoded in your information architecture.

Consider a quality investigation involving a pharmaceutical batch. The agent may need to evaluate process parameters from a reactor, batch-phase events from the MES, laboratory results from the LIMS, equipment history from the historian, calibration and maintenance records from the CMMS, material-lot information from the ERP, and approved specifications from a quality system.

The Connect stage makes these sources accessible. The Contextualize stage explains how the information relates, identifies which sources are authoritative, shows whether the data passed validation, and clarifies what each value means in the context of the batch and process.

This is how you establish trust before data reaches AI.

What you should have at the end of the contextualize stage

By the end of this stage, you should have:

• A governed Unified Namespace representing your operations in real time

• Enterprise naming, topic, and schema conventions

• A semantic graph connecting assets, processes, batches, materials, quality, and business information

• Automated discovery and cataloging of data sources

• Validation and deviation workflows for data in motion

• Reusable transformation and enrichment services

• Defined authoritative sources and data ownership

• Metadata and lineage that trace information back to its origin

• Versioning and change-management processes

• A trusted operational context layer that people and AI agents can understand

At this point, your data is no longer a collection of disconnected values and events. It has structure, relationships, ownership, quality indicators and operational meaning.

The next challenge is to use that trusted context to detect patterns, calculate consistent performance measures, and generate insights that can be compared across assets, lines, shifts and sites.

That is where Analyze begins.

Read the full whitepaper and discover each of the four stages in the Building a scalable data foundation for real-time operational intelligence whitepaper.