Unified Namespace (UNS) Architecture: Topic Structure + Examples (MQTT)

Published on March 1, 2026 | By Nick | Categories: Digital Transformation & IIoT

If you’re new to the term, here’s the short version: a Unified Namespace (UNS) is a pub/sub information architecture for industrial data. It’s not a product. It’s not a dashboard. And it’s definitely not “just an MQTT broker”.

In this post, I’ll focus on the part most teams get stuck on: the architecture — what needs to exist, how to structure your topics, and how to keep your UNS usable (rather than turning into a data swamp).

What “architecture” means in a Unified Namespace

When people say “UNS architecture”, they usually mean four things:

  • Transport/broker layer: how events move around (MQTT is common).
  • Namespace structure: how you organise context (enterprise/site/line/station).
  • Payload contracts: what’s inside messages (schema, units, timestamps, quality).
  • Governance: who is allowed to publish what, and how you keep it consistent over time.

MQTT is popular because it’s lightweight and flexible. But that flexibility is also the trap: you can publish anything you want on any topic. Without a shared structure and payload contract, you’ll create a system that is technically “connected” but operationally useless.

UNS is not a broker (and why that distinction matters)

A broker is a piece of infrastructure. A UNS is an information model and distribution pattern. You can implement a UNS on top of multiple broker technologies. MQTT is one of them, and it’s a great fit for many manufacturing environments.

Think of it like this:

  • MQTT answers: “How do we move messages?”
  • UNS answers: “What do those messages mean, where do they live, and who can rely on them?”

If you treat the broker as “the UNS”, you’ll usually end up with a flat pile of topics that nobody trusts. If you treat the UNS as an architecture, you can scale to dozens of producers and consumers without reinventing integrations every time.

The core building blocks (practical, not theoretical)

1) MQTT brokers (often more than one)

Most real deployments don’t have a single broker sitting in one place forever. You often end up with brokers at different levels:

  • Edge/cell/machine level: local broker close to equipment for resilience and low latency.
  • Site level: broker that aggregates multiple lines/cells.
  • Enterprise level: broker (or broker cluster) for cross-site visibility and enterprise consumers.

This isn’t “over-engineering” — it’s how you avoid a single point of failure and how you manage bandwidth, latency and intermittent connectivity. Your namespace can be composed and extended as you move up levels.

2) Producers (publishers)

Producers create authoritative events/states. Examples:

  • Edge applications that read PLC tags and publish normalised values
  • Connectors that publish MES events (e.g. job start/stop, routing, quality checks)
  • Quality systems that publish holds, defects, NCRs/NCMRs
  • Maintenance systems that publish downtime reasons, work orders, and completion events

3) Consumers (subscribers)

Consumers subscribe and act. Examples:

  • Dashboards / BI (Power BI, Grafana, custom)
  • Historians and time-series storage
  • Alerting and escalation workflows
  • AI assistants / RAG tools (answer questions from procedures + live context)
  • Integration services (sync to ERP, planning tools, warehouse systems)

4) A “translation/normalisation” layer

Raw PLC tags are not a UNS. A UNS typically needs a layer that:

  • maps tag names into a shared topic hierarchy
  • normalises units and naming (e.g. “TempC” vs “Temperature”)
  • adds timestamps and quality
  • converts legacy formats into consistent payloads

This is where most value is created, because this is where “integration once” becomes possible.

Topic structure: the part that makes or breaks your UNS

Using ISA-95 as the backbone for the UNS topic structure

One practical way to keep a Unified Namespace consistent (especially as more producers come online) is to align your topic hierarchy with ISA-95.

ISA-95 is widely used as a reference model for how manufacturing organisations and systems are structured. You don’t need to “implement ISA-95 perfectly” to benefit from it — you just need a stable backbone that matches how factories actually think: enterprise/site/area/line/cell/unit.

ISA-95 levels (quick mapping)

  • Level 4 — Enterprise / ERP scope
  • Level 3 — Site/operations management (MES scope)
  • Level 2 — Area/supervisory control (SCADA scope)
  • Level 1 — Cell/equipment/sensors and control (PLC/edge scope)

In an UNS, this helps you create a topic structure where the context is predictable and scalable, and where you can reason about plant-level vs enterprise-level subscriptions.

ISA-95-ish topic hierarchy (example)

Here’s an example that keeps the spirit of ISA-95 and works well in MQTT:

enterprise/{enterprise}/site/{site}/area/{area}/line/{line}/cell/{cell}/unit/{unit}/
  state/
  events/
  alarms/
  metrics/

If your environment uses different terms (e.g. work_center, station, asset), that’s fine — the key is that the hierarchy remains consistent and that each level has a clear meaning and owner.

The goal of topic structure is simple: encode context in a predictable way, so any consumer can find what they need without knowing the producer implementation details.

There isn’t one perfect hierarchy, but there are strong patterns. A good hierarchy usually answers these questions:

  • Which enterprise/site is this data from?
  • Which area/line/cell/station produced it?
  • Is it a state, an event, an alarm, or a KPI?
  • What is the asset or process being described?

A practical baseline hierarchy

This is a good starting point for many manufacturers:

enterprise/{enterprise}/site/{site}/area/{area}/line/{line}/cell/{cell}/station/{station}/
  state/
  events/
  alarms/
  metrics/

Notes:

  • state is the current value (e.g. machine mode, last cycle time, running/stopped).
  • events are discrete facts (job started, job completed, defect recorded).
  • alarms are abnormal conditions and acknowledgements.
  • metrics are computed for KPIs (OEE components, FPY, throughput).

Alternate hierarchy: asset-centric

If you’re very asset-focused, an alternative is:

enterprise/{enterprise}/site/{site}/assets/{assetId}/
  state/
  events/
  alarms/
  metrics/

This works well when assets move or when line/station identity is messy. The tradeoff: you must maintain a reliable asset registry (and mapping to physical context).

Where “work orders” and “products” fit

Don’t cram everything into the same branch. A common pattern is to keep operational context separate:

enterprise/{enterprise}/site/{site}/production/orders/{orderId}/events
enterprise/{enterprise}/site/{site}/production/products/{productCode}/spec

That makes it easier for enterprise consumers to subscribe to “all order events” without knowing line topology.

Payloads: don’t let MQTT freedom destroy semantics

Topics are only half the story. The payload carries the meaning.

A good UNS payload convention makes downstream tools dramatically easier to build. A simple approach is to standardise on JSON with a small set of required fields:

{
  "ts": "2026-03-01T06:21:00Z",
  "value": 6.8,
  "unit": "pH",
  "quality": "good",
  "source": "PLC-L3-Station2",
  "meta": {
    "tag": "PH_Reading",
    "note": "optional"
  }
}

For events, use an event envelope:

{
  "ts": "2026-03-01T06:21:00Z",
  "eventType": "DowntimeStarted",
  "asset": "Line3.Station2",
  "payload": {
    "reason": "Material shortage",
    "workOrder": "MO-18427"
  }
}

Does it have to be JSON? No. But you need something consistent. Otherwise, every consumer becomes a bespoke integration again.

State vs event vs metric payloads

  • State should be compact and frequent (changes / sampled).
  • Events should be durable, meaningful, and easy to replay.
  • Metrics should carry definition metadata (window, aggregation, version).

Plant-level visibility vs enterprise-level visibility (how to support both)

This is a common UNS question: “How do I implement a hierarchy that supports plant-level and enterprise-level visibility?”

The answer is: don’t try to cram everything into one subscription pattern. Provide stable subscription points:

  • Plant-level apps subscribe to: .../line/+/+/state/# (or similar)
  • Enterprise apps subscribe to: enterprise/{enterprise}/site/{site}/+/+/metrics/#
  • Cross-site apps subscribe to: enterprise/{enterprise}/+/+/production/orders/+/events

The trick is to keep the hierarchy predictable. If you need to change it, version it rather than “breaking” consumers silently.

Governance (the part everyone avoids — and then pays for)

UNS governance sounds boring until you’ve got 20 producers publishing 20 different “machine states” to 20 different places.

Governance is simply answering:

  • Who can publish? (which systems are authoritative for which topics)
  • What are the contracts? (schemas, units, naming conventions)
  • How do we change things? (versioning, deprecation, migration windows)
  • How do we validate? (linting topics, schema validation, monitoring)

Anti-pattern: “anything anywhere”

MQTT makes it easy to publish anything anywhere. That’s both the superpower and the failure mode. A UNS only works long-term when you restrict publishing paths and enforce a shared model.

Practical governance you can actually implement

  • Create a simple namespace spec (a 2–5 page document) with examples.
  • Assign ownership per domain (production, quality, maintenance).
  • Enforce broker ACLs so only approved producers can publish to critical paths.
  • Set up monitoring for “unknown topics” and schema violations.

Common UNS mistakes (and how to avoid them)

  • Flat topics (no context). Fix by encoding site/line/station consistently.
  • No payload standard. Fix by publishing envelopes for state/events.
  • Mixing concerns (raw tags + metrics + business events in one branch). Fix by separating namespaces.
  • Governance after the fact. Fix by starting with a minimal spec and enforcing it.
  • Assuming the UNS replaces everything. It complements MES/SCADA/historians; it doesn’t magically eliminate them.

A simple reference implementation roadmap

  1. Pilot one line: publish a small set of state + events you know you need.
  2. Prove consumers: dashboard + alerting + one integration (e.g. downtime workflow).
  3. Write the spec: freeze naming, payload envelopes, and ACL policy.
  4. Scale producers: replicate the pattern across stations/lines.
  5. Add enterprise consumers: BI, reporting, analytics, and AI assistants.

Want an UNS functional specification template?

If you’re implementing a Unified Namespace and want a practical spec template (topic hierarchy, payload contracts, ownership, ACLs), contact me, and I’ll share a starting point.

Disclaimer: For educational purposes only. Every factory environment is different.

Why a UNS is a strong foundation for AI agents in manufacturing

Most “AI agent” discussions jump straight to models and prompts. In manufacturing, the bigger issue is usually context: what’s happening right now, where it’s happening, and what it means.

A Unified Namespace helps because it provides a standardised, governed event and state layer that agents can subscribe to. Instead of building one-off integrations for each use case, you give agents a consistent way to observe operations.

UNS + AI agents: the simple mental model

  • UNS = what’s happening (events + state in a consistent structure)
  • RAG / knowledge base = what to do about it (SOPs, work instructions, QMS docs)
  • Agent workflows = who to notify / what system to update / what action to trigger

In other words: RAG can answer questions from documents, but a UNS gives you the live operational signals that tell you when to ask the question and which context matters (site/line/station/order).

Concrete examples

  • Downtime event (e.g. “Line 3 downtime > 8 minutes”) — create a maintenance ticket, pull the right troubleshooting steps from SOPs, and notify the right team.
  • Material shortage event — alert planning, surface alternates/notes, and update order status.
  • Quality hold / defect cluster — trigger containment workflow and attach the correct inspection procedure.

Why this reduces hallucination risk

Agents fail when they’re fed ambiguous, inconsistent data. A well-governed UNS reduces that risk by enforcing:

  • consistent topic structure (context is predictable)
  • payload contracts (schemas/units/quality)
  • ownership of sources (which system is authoritative)

If you’re exploring AI agents for manufacturing, you may also like: Private RAG knowledge assistant and AI solutions.