Fractal Unified Namespace — Frequently Asked Questions

Diagram of a monolithic Unified Namespace with all nodes connected through a single centralized broker
Diagram of a fractal Unified Namespace with self-similar namespaces replicated at multiple operational levels
Book-open Book-open Read the White Paper

Understanding the Unified Namespace

A Unified Namespace (UNS) connects all data sources and users across a plant or enterprise — PLCs, sensors, historians, ERP systems, and more — into a single, queryable data fabric. Typically, this is implemented with a single centralized broker that handles protocol conversion, naming conventions, engineering units, security, and edge-to-cloud bridging.

A single-broker Unified Namespace introduces several risks. It creates a single point of failure — if the broker goes down, visibility across the entire plant or enterprise is lost. It increases latency as all data flows through one central point. It makes OT network segmentation difficult. And it expands the blast radius of any security breach, because every node can potentially reach every other node. A compromised HMI in one building could have a direct path to a corporate historian.

A fractal Unified Namespace replicates the same namespace structure at every level of the operations hierarchy — machine, line, factory, site, enterprise, and cloud. Each higher level contains the important information from the levels below, mirroring their structure. Think of it like the Internet’s DNS system: local resolvers handle nearby queries, regional servers handle broader ones, and root servers handle global lookups. Each layer is self-similar, fully functional, and autonomous.

Benefits and Common Objections

A fractal UNS provides five key structural advantages:

  • Fault isolation — A failure at one level does not cascade to other levels. Each layer operates independently and degrades gracefully.
  • Contained blast radius — A compromised node can only reach what it is architecturally permitted to reach. Lateral movement is constrained by design, not just by policy.
  • Defined data sovereignty — Bounded namespaces let you enforce what data crosses which boundaries, which is important for multi-site operations, joint ventures, and regulatory compliance.
  • Scalable governance — Schema ownership is distributed to the teams closest to the data, rather than centralized in one group.
  • Predictable performance — Traffic stays local until it needs to go broader, so high-frequency process data does not compete with enterprise reporting queries.

A monolithic UNS is only “simple” until something goes wrong — a misconfigured MQTT client or a compromised node can flood the broker and cause a total loss of visibility across the entire plant. A fractal architecture distributes complexity to the teams who actually understand the data, such as the engineers running a specific production line. Changes can be made on the spot by those responsible for the process.

No UNS is a “single source of truth”. The source of truth for a measurement is the physical system – that is the authoritative source for that value. Every communication level above that is a delegate for that authority. The PLC is not the truth if a wire is broken. A SCADA system is not the truth if an OPC server crashes. An MQTT broker is not the source of truth if a network connection is lost or congested. At each communication level, the lower level acts as the authority for the data it sends to the level above. That only works in practice when every level in the communication chain reliably reports loss of authority (e.g., the network connection to the level below breaks) to the levels above it.

At best a UNS is a “single point of contact” for the truth at that level. To be reliable, the UNS must state with certainty that either it knows its value to be correct and current, or it knows it to be disconnected from the physical system somewhere along the transmission chain. This isn’t a question of monolithic vs. fractal UNS. It is a question of whether the broker and protocol can provide the guarantees required to make a single point of contact act as a reliable source of truth. MQTT does not provide the quality of service or failure handling that provides this. You need purpose-built software and protocols to make the UNS trustworthy, monolithic or not.

The opposite is true. A fractal UNS delegates decisions to the people closest to the process. The team running a stamping line owns their namespace and can make changes on the spot. Corporate data architects own the enterprise aggregation layer. This distributed ownership makes the system more adaptable, not less.

No. MQTT’s pub/sub architecture offers a simple, secure way for devices to connect, but its QoS guarantees do not propagate reliably across more than one broker connection. The result is a fragile system that looks distributed but behaves poorly under stress. A fractal UNS requires purpose-built software, such as Cogent DataHub software from Skkynet that guarantees data consistency from each source to each user across all levels of the hierarchy.

Implementation and Security

If communication between levels breaks, or if a server at any level goes down, that data is flagged as not connected. The other servers in the system continue functioning on that basis. Local operations are not affected by disruptions at higher levels, and the system resumes normal data flow when the connection is restored.

IT/OT convergence has extended enterprise threat surfaces deep into plant environments. A fractal architecture addresses this structurally — each layer enforces its own access controls, so security does not depend on policy alone. Even when policies are misconfigured, documentation is outdated, or a team is responding to an incident at 2 AM, the architectural boundaries hold.

Additionally, a fractal UNS can support multiple-hop connections for a DMZ, to segment OT and IT networks effectively.

Rather than asking “how do we get everything connected,” consider:

  • What is the right boundary for each namespace segment?
  • What data genuinely needs to cross each boundary, and in which direction?
  • What is the failure mode when any single component goes down?
  • What is the containment boundary if a node is compromised?
  • Who governs each layer of the hierarchy?

A flat UNS can answer some of these with policy and configuration. A fractal UNS answers them with architecture.

Not at all. Unifying your namespace is the right goal. A fractal UNS provides the same unified data benefits while restoring the structural segmentation that prevents local issues from becoming enterprise-wide disasters. It requires implementing the UNS vision with the same rigor you would apply to any critical OT system.