HiveMQ Glossary

The lightweight publish/subscribe protocol, standardized by OASIS and ISO, that HiveMQ’s Connect layer runs on. By decoupling publishers from subscribers through the broker, the protocol lets HiveMQ Platform move industrial data reliably across edge, on-prem and cloud, at a scale of millions of connections, without brittle point-to-point integrations. To learn more, explore our MQTT page.

A design pattern, not a product, used for organizing all data-producing and data-consuming systems within an organization. The Unified Namespace (UNS) provides a single, structured, event-driven view of business operations. It is ideally built on MQTT’s publish/subscribe model.

An architecture where decoupled systems communicate by producing and consuming events in real time through a broker rather than polling for updates. It's the foundation that makes both the UNS and real-time agentic response possible.

The distributed foundation beneath every other layer: acquiring data from OT and IT systems, transforming it into consistent formats, and transmitting it in real time across edge, site and cloud.

Pulling raw operational data from PLCs, sensors, SCADA and IT systems like ERP and MES: the first step in making that data available to the streaming layer.

Converting disparate data formats into consistent structures as data moves, rather than waiting for it to land in a central repository first.

Connecting data across system boundaries by taking industrial data captured over protocols like MQTT and handing it off to ERP, MES, databases and other destination systems, mapped to the topics and structures each one expects, so events that originated in isolated systems resolve into one coherent operational picture.

A data streaming design architecture that processes and validates data at the edge, close to where it’s created, while still coordinating a single, governed view centrally. Execution stays distributed; visibility and governance stay centralized.

An international standard for integrating enterprise and control systems, defining a hierarchical model (enterprise, site, area, line, cell) commonly used as a starting point for UNS topic structures.

The integration of operational technology (plant-floor systems) and information technology (enterprise systems) onto shared, interoperable data infrastructure. It's a prerequisite for any enterprise-wide UNS or AI initiative.

Enforcing trust in data as it streams, validating it in real time and preserving its context, instead of inspecting it for quality only after it lands somewhere central.

The architectural principle of extracting insight and acting on industrial data where it's created, rather than centralizing everything first, so intelligence stays distributed at the edge while a shared namespace still gives the organization one unified, real-time view across every site.

Adding structure, meaning and governance to raw industrial data as it moves, so the same data means the same thing to every system and person that touches it.

The shared vocabulary of an organization: the definitions and relationships that ensure “equipment,” “work order” or “customer” mean the same thing across every department and system.

A formal, machine-readable set of rules built on the semantic model, defining what entities exist, how they relate and what constraints govern them. The rulebook for a knowledge graph. To learn more, read our whitepaper, Building Ontology-Driven Intelligence for Industrial AI Agents.

The actual data: a network of entities and relationships structured according to an ontology’s rules, turning an abstract model into a queryable representation of operational reality.

The three-tiered stack of semantic model, ontology and knowledge graph that turns distributed industrial data into structured knowledge both people and AI can act on.

The categories of entities that make up an ontology - such as Machine, Operator, Work Order or Batch - each a class of things with shared characteristics.

The defined relationships between object types, such as “Operator operates Machine,” that let systems reason precisely about how entities connect.

The operations an ontology permits, such as Start Production Run or Schedule Maintenance, along with the preconditions and state changes they require. The structural basis for governed autonomy.

An industry term with multiple competing definitions. In an agentic-AI context, it typically means an entity-centric agent maintaining one operational asset’s complete state and history, distinct from a 3D simulation model.

A searchable, browsable interface to an organization’s ontology, data models and data products: how both people and AI agents discover what data exists and what it means.

A complete, auditable record of what data an agent or system accessed, when, and what was done to it, required for explainability and regulatory compliance.

Operational data that has been streamed, validated, and contextualized to the point where an AI system can reason over it without first needing human interpretation or cleanup.

An operating model where individual plants run and decide locally while the enterprise keeps shared visibility, governance, and alignment across every site from one place.

AI that reads live signals from PLCs, sensors, SCADA and other plant systems, reasons over them in real time and responds within the limits its governance sets, from flagging an operator for approval to executing a scoped process change, rather than passively generating a dashboard for a human to interpret.

Autonomy within defined boundaries: an agent can only take actions its ontology permits, against entities it has access to, when preconditions are met.

The response an AI agent triggers back into an operational workflow, with a person in control and a full audit trail - distinct from a monitoring tool, which only raises an alert.

The execution environment an agent runs in: the “Run” stage of the agent lifecycle, where it senses live data, reasons over context and takes governed action, distinct from the reasoning model itself.

A graduated framework - from monitoring-only, to recommend-with-approval, to constrained autonomous execution to broad autonomous authority - that matches an agent’s authority to the risk of its decisions.

An operating mode where an agent recommends an action but a person must approve it before it executes. For example, an AI agent detects an abnormal vibration pattern in a production line and recommends shutting down the machine, but a maintenance engineer must approve the action before it is executed. It's the default state for agentic AI still in public preview.

A principle where people are treated as collaborative agents in the workflow, not fallback exception-handlers, with defined escalation paths, handoffs and response-time targets.

Coordinating multiple specialized agents, including monitoring, diagnostic, predictive, optimization, coordination and learning agents, so their actions reinforce one shared objective instead of competing.

The functional categories of industrial AI agents: Monitoring (what’s happening), Diagnostic (why), Predictive (what’s next), Optimization (what to adjust), Coordination (resolving conflicts) and Learning (improving all of the above over time).

A feedback structure where an agent’s decisions connect back to their outcomes, so the agent accumulates operational knowledge instead of just executing isolated tasks.

The requirement that every autonomous action include a clear, human-readable record of the reasoning behind it that is understandable to domain experts, not just AI specialists.

Granting an agent only the specific data and system access its function requires, so agentic AI doesn’t reopen the OT/IT security isolation traditional architectures relied on.

An automated safeguard that detects abnormal agent behavior and reduces its authority pending human review. For example, an agent adjusting parameters far outside historical norms might be restricted to monitoring-only until a person reviews it.

A formalized statement of goals and constraints that every agent in a multi-agent system reads from, so agents negotiate trade-offs against one shared standard instead of optimizing for competing local metrics.

A three-stage model for agentic maturity: Diagnostic Intelligence (agents observe and alert), Prescriptive Intelligence (agents recommend) and Autonomous Intelligence (agents decide, execute, and learn without approval for routine operations).

Two ways to structure multi-agent systems: one dedicated agent per entity (deep context, more overhead) versus fewer agents each serving many entities (efficient, less contextual depth). Most industrial deployments end up hybrid.