Building a Unified Namespace shouldn’t start in a spreadsheet. Yet that’s how many teams still do it—manually mapping MQTT topics, debating naming conventions, and trying to impose structure after thousands of messages are already flowing.
Litmus Unify 2.0 takes a different approach. Instead of designing your Unified Namespace on paper, it builds from live MQTT data so you can review, govern, and refine your namespace as it emerges.
Litmus Unify 2.0 is the latest release of Litmus Unified Namespace built on an enterprise-class MQTT engine that acts as a single source of truth for real-time OT-IT data exchange. The 2.0 release adds Explore UNS, a visual workspace where incoming MQTT topics are parsed into a standardized hierarchy you can review, accept, reject, and govern directly. Instead of describing your namespace on paper, you see it form from live data and shape it as you go.
If you're an OT/IT integration architect or data engineer responsible for keeping operational data consistent across sites, this is the part of the release that will change your day-to-day.
At a high level, this release focuses on visibility, governance, and reliability:
Explore UNS: A dedicated workspace with two complementary views for building and validating your namespace.
Namespace governance workflow: Accept or reject topics as nodes in a hierarchy, with status changes that propagate through the tree so one action can settle a whole branch.
Raw topic inspection: See exactly what's arriving from your publishers before any classification is applied.
Deeper MQTT observability: A broad set of Prometheus metrics covering connections, throughput, latency, retained messages, and session lifecycle.
High-availability scaling: Helm support for running multiple HA proxy replicas.
More predictable sessions and delivery: Cleaner session expiry, correct handling of special-character topic names, reliable retained-message delivery to new subscribers, and tighter coupling between publisher state and broker state.
Litmus Unify2.0 View
Explore UNS lets you configure and manage a standardized UNS hierarchy that represents your enterprise as levels of classes for example, enterprise/site/area/production unit. Each level reflects your physical or data structure, so the way data is gathered stays decoupled from the way it's consumed. A data engineer can pull line-level production data without needing to know the sensor or device it came from.
The mechanism is straightforward: Unify parses the metadata of incoming messages and generates a UNS structure that shows the relationships between data elements as a hierarchy. Explore UNS then gives you two views, “Namespace and Raw” to move from raw ingestion to a governed model.
The Namespace view displays a dynamically generated hierarchy that reflects the classification rules you've defined. Every node carries a status as New, Accepted, Neglected, or Rejected and your job is to review the structure and decide what belongs in the Unified Namespace.
Not every MQTT topic belongs in your production namespace. One of the fastest ways to create an unusable UNS is to publish everything and hope consumers figure it out later. Explore UNS introduces an explicit governance workflow so teams can decide what becomes part of the enterprise namespace and what doesn’t.
Two propagation rules make this quick to work through, and they move in opposite directions:
Accepting a node also accepts its parent nodes up the hierarchy.
Rejecting a node also rejects its child nodes down the hierarchy.
Because a single action can change the status of many nodes, review the affected branch before you commit to it. From the action menu on any node you can accept, reject, accept an entire subtree, open the MQTT client to view topic data for the selected topic, delete a topic and its children, or refresh the hierarchy. Filters let you narrow the tree by search text or by status, so you can focus on just the new topics that need a decision.
When something looks wrong downstream, the first question isn’t “Did the broker fail?” It’s “Did the data arrive the way we expected?” The Raw view removes guesswork by exposing MQTT topics exactly as they’re published before any classification or governance is applied. Use it to confirm which topics are arriving from your publishers and to troubleshoot when something isn't showing up where you expect. You can search and filter the topic list, refresh it, and open the MQTT client subscribed to a selected topic to inspect its payload. When a topic looks wrong in the Namespace view, Raw is where you confirm whether the problem is the incoming data or your classification rules.
Production MQTT brokers aren’t judged by demos. They’re judged by what happens at 2 a.m. when something goes wrong. That’s why Litmus Unify 2.0 expands observability well beyond message throughput. New Prometheus metrics provide visibility into connection health, latency, retained messages, QoS behavior, session lifecycle, and more—giving operations teams the signals they need before downstream systems are affected.
Beyond Explore UNS, Litmus Unify 2.0 hardens the broker for production and multi-site operation. The broker now exposes a wide set of Prometheus metrics so you can watch message flows and errors in the tools you already run; enough signal to alert on saturation or latency drift before it reaches a data consumer. Those metrics cover:
Connection and disconnection counts, plus authentication activity
Messages and bytes in and out, and dropped messages
QoS resends, retained-message counts, and inflight utilization
End-to-end publish latency and session expiries
Session and delivery handling is more predictable, and multi-replica scaling is now supported:
Cleaner session expiry
Reliable retained-message delivery
Tighter publisher–broker coupling
High-availability scaling
A Unified Namespace is only as good as the data entering it. That’s why Litmus Edge and Litmus Unify were designed to work together. The two products form a single path from machine to trusted namespace:
Litmus Edge connects and contextualizes: It connects to OT assets, normalizes and contextualizes their tags at the source.
Edge publishes over MQTT: That contextualized data flows to Litmus Unify using a dedicated MQTT account.
Unify builds the hierarchy: The namespace manager parses the metadata on incoming messages and generates the governed structure you then curate in Explore UNS, so the context added at the edge carries through into your namespace.
State stays in sync both ways: Because publisher state is now bound to broker state, disabling an Edge MQTT account in Unify disconnects the client cleanly, keeping your namespace an accurate reflection of what's actually connected.
Put simply, Litmus Edge captures and contextualizes operational data at the source, and Litmus Unify turns that stream into a single, trusted source of truth for every consumer downstream.
The Litmus Industrial Data Foundation moves organizations from fragmented OT environments to connected, governed, and scalable industrial data operations. Litmus Unify owns the data-sharing layer of that story, working alongside the other products:
Litmus Edge: Connectivity, DataOps, Edge AI at the source
Litmus Edge Manager: Monitor, and scale distributed Litmus Edge deployments from a single place.
Litmus Unify: governed, consistent, real-time OT-IT data exchange through a Unified Namespace
Litmus Data Catalog: metadata discovery, lineage, and ownership across the enterprise
We've said it consistently over the past year: good data makes great AI possible.
Industrial AI doesn't struggle because today's models lack intelligence. It struggles because operational data lacks consistency, governance, and context.
A Unified Namespace gives every downstream consumer—from dashboards to AI agents—a shared understanding of operational data. Unify 2.0 strengthens that foundation by making the namespace itself easier to build, easier to govern, and easier to trust.
That governance is what makes Industrial AI viable. Models, agents, and analytics are only as trustworthy as the data feeding them, and a clean, ISA-95-aligned namespace with clear accept/reject provenance gives AI a structured, consistent, real-time foundation to build on. Unify 2.0 tightens that foundation right where it matters.
What is a Unified Namespace? A Unified Namespace (UNS) is a single, structured source of truth for real-time operational data, organized by hierarchy rather than by point-to-point connections. Producers publish data once and any consumer subscribes to what it needs, which removes brittle integrations between systems.
How does the accept-reject workflow in Litmus Unify 2.0 work? Explore UNS generates a hierarchy from your incoming MQTT topics, and each node has a status of New, Accepted, Neglected, or Rejected. Accepting a node also accepts its parents; rejecting a node also rejects its children, so you can govern a whole branch of your namespace in one action.
What's the difference between the Namespace and Raw views? The Namespace view shows the standardized hierarchy built from your classification rules, where you accept and reject nodes. The Raw view shows topics exactly as received, before classification, and is used to confirm what's arriving and to troubleshoot.
Litmus Unify 2.0 gives you a visual way to build a Unified Namespace, a governance workflow to keep it clean, and the observability and high-availability upgrades to run it in production. Explore UNS turns namespace design from a manual, document-driven exercise into something you shape directly from live data. Paired with Litmus Edge, it becomes the governed, real-time backbone your analytics and Industrial AI initiatives depend on.
See Litmus Unify 2.0 in action — request a demo