Representing a Unified Namespace (UNS) in AnyLog

Overview

A Unified Namespace (UNS) provides a logical representation of an industrial environment, organizing operational data into a structured hierarchy of assets, equipment, processes, and measurements. The objective of a UNS is to provide applications, users, analytics, and AI systems with a consistent operational view regardless of where the data physically resides.

Unlike relational databases, which organize data into tables, columns, and records optimized for storage and retrieval, a UNS organizes information according to the physical and operational structure of the business. Instead of asking which table contains a measurement, users and applications navigate through meaningful operational relationships such as Enterprise → Site → Asset → Equipment → Measurement.

A UNS therefore transforms raw data into operational context. It describes not only what the data is, but also where it belongs, how it relates to other assets, and how it should be interpreted within the broader industrial environment.

AnyLog extends this concept to distributed edge environments. Rather than requiring data to be centralized into a single repository, AnyLog creates a logical namespace that spans distributed databases, historians, devices, and edge systems while allowing data to remain at its source. The result is a real-time operational model that can be accessed uniformly across the enterprise without moving or duplicating data.

Figure 1 — Building an Intelligent Fabric Over Distributed Edge Data

Figure 1 illustrates the fundamental AnyLog architecture. A logical operational layer is created above distributed edge systems, databases, devices, and industrial infrastructure. The Unified Namespace is not tied to any single database or cloud repository. Instead, it provides a logical representation of distributed operational assets while allowing data to remain at its source. Applications, users, analytics, and AI agents interact with this logical layer rather than directly with individual data sources.

Dynamic UNS Creation

A key differentiator of AnyLog is that a UNS does not need to be pre-defined.

AnyLog dynamically builds the UNS from live industrial data sources and metadata while keeping the operational data distributed at the edge. The UNS is therefore not a database, data model, or centralized repository. Instead, it is a logical metadata layer that describes how distributed data should be represented, organized, and accessed.

Because the UNS is a logical definition over the data, multiple UNS representations can coexist over the same underlying data. Different users, business units, applications, or AI systems may define different asset hierarchies, naming conventions, and contextual views while accessing the same physical data sources.

Creating, modifying, or extending a UNS simply requires adding or updating metadata policies. No data movement, re-ingestion, ETL process, or restructuring of the underlying data is required.

UNS Representation in AnyLog

In AnyLog, UNS objects are represented as JSON metadata policies stored in the distributed AnyLog metadata layer. Each object represents an element within the namespace and includes:

• Asset or tag name
• Position within the hierarchy
• Parent-child relationships
• Source data location
• Query information
• Domain-specific metadata
• Governance and ownership information

The hierarchy is established through parent-child relationships using object identifiers.

Figure 2 illustrates how AnyLog represents a UNS using metadata policies. Each UNS object is stored as a JSON document describing the asset, its position within the hierarchy, engineering context, and the mapping to the physical data source. These metadata objects establish parent-child relationships while preserving references to the underlying distributed data. The result is a logical namespace that can be modified and extended without moving or restructuring operational data.

Example: Hole Depth Tag

The following metadata object represents the hole_depth measurement for rig RIG-TX-007:

{
"uns": {
    "name": "RIG-TX-007/hole_depth",
    "uns_layer": "tag",
    "namespace": "wits/record01/RIG-TX-007/hole_depth",
    "parent": "5cbbdbc9525eab0145ff6653db6d651e",
    "rig_id": "RIG-TX-007",
    "column": "hole_depth",
    "wits_record": "1",
    "wits_item": "15",
    "wits_description": "Hole Depth",
    "data_type": "float",
    "unit": "ft",
    "dbms": "timbergrove_rigs",
    "table": "rig_data",
    "where": "rig_id='RIG-TX-007'",
    "id": "ce69e34a00f43c0e5ea9744cab11afbf",
    "date": "2026–05–17T17:19:47.831776Z",
    "ledger": "global" 
    }
}

This object describes:

• The namespace path (wits/record01/RIG-TX-007/hole_depth)
• The source data location (timbergrove_rigs.rig_data)
• How the data is queried
• The engineering unit and data type
• Its parent asset within the hierarchy

The parent field references object 5cbbdbc9525eab0145ff6653db6d651e, which represents the drilling rig itself.

The hole depth example shown below demonstrates how a measurement is associated with a drilling rig through parent-child metadata relationships. By traversing these relationships, AnyLog reconstructs the complete asset hierarchy represented in Figure 2.

Example: Rig Object

{
"uns": {
    "name": "RIG-TX-007",
    "uns_layer": "rig",
    "namespace": "wits/record01/RIG-TX-007",
    "parent": "034486c838672fab67c4eca5f47b9716",
    "rig_id": "RIG-TX-007",
    "rig_name": "Eagle Ford",
    "region": "South Texas",
    "location": "land",
    "loc": "28.9724, -98.6428",
    "dbms": "timbergrove_rigs",
    "table": "rig_data",
    "where": "rig_id='RIG-TX-007'",
    "id": "5cbbdbc9525eab0145ff6653db6d651e",
    "date": "2026–05–17T17:18:10.772630Z",
    "ledger": "global"
    }
}

By traversing these metadata relationships, AnyLog reconstructs the complete asset hierarchy and exposes it as a navigable UNS while the operational data remains distributed across edge systems, databases, historians, and devices.

Figure 3 illustrates two complementary ways of accessing distributed operational data. Users and applications may interact directly with the distributed data fabric through standard SQL queries, or they may navigate the same data through the logical UNS hierarchy. Both approaches operate on the same underlying distributed data. The UNS provides contextual navigation while SQL provides direct analytical access. Together they form a unified intelligence layer without requiring data duplication.

How UNS Definitions Are Created and Maintained

Figure 4 illustrates the automated generation of UNS metadata within AnyLog. Namespace definitions may be created from multiple sources including AI analysis of raw data, OPC UA information models, MQTT topic structures, historians, databases, and existing metadata repositories. The AnyLog translation engine converts these sources into standardized JSON metadata policies that collectively form the UNS hierarchy.

Because AnyLog does not require data centralization, UNS definitions can be created and evolve through multiple mechanisms.

1. AI-Driven UNS Creation from Raw Data

Raw operational data is ingested into AnyLog nodes, structured into tables or time-series, and registered within the AnyLog metadata layer.

Using the AnyLog MCP interface, AI agents can analyze:

• Data structures
• Tag names
• Database schemas
• Industrial naming conventions
• Industry standards
• Historical relationships
• Operational context

The AI can then automatically generate or refine UNS policies. Domain-specific knowledge can be applied to infer asset hierarchies, equipment relationships, process structures, and semantic classifications without requiring manual modeling.

This allows organizations to rapidly create a meaningful UNS even when no prior asset model exists.

2. UNS Creation from OPC UA

AnyLog connects to OPC UA servers and automatically discovers assets, devices, variables, metadata, and embedded relationships.

The OPC UA information model itself provides much of the hierarchy required to build a UNS. AnyLog extracts this information and generates corresponding UNS policies that represent equipment, measurements, assets, and their relationships.

3. UNS Creation from MQTT Brokers

AnyLog subscribes to MQTT topics, parses message payloads, analyzes topic structures, and maps message attributes into metadata objects.

Topic hierarchies often naturally represent assets, sites, devices, and measurements. AnyLog converts these structures into corresponding UNS definitions.

4. Hybrid UNS Creation

Most deployments combine multiple approaches.

Existing metadata from OPC UA servers, MQTT brokers, historians, relational databases, time-series databases, ERP systems, CMMS platforms, and AI-generated knowledge can be merged into a single logical namespace.

As equipment, facilities, and business requirements evolve, the UNS evolves with them through metadata updates rather than data migration projects.

Figure 5 — Infinite Perspectives. One Ground Truth

Figure 5 illustrates one of the most important differentiators of AnyLog. Because the UNS is represented as metadata rather than a physical data model, multiple namespaces can coexist over the same operational data. An executive AI agent may view assets according to business objectives, maintenance teams may organize equipment according to service requirements, and operations personnel may view the environment according to process flow. Each namespace represents a different perspective of the same distributed data while preserving a single operational ground truth.

Unlike traditional UNS implementations that typically enforce a single enterprise-wide hierarchy, AnyLog supports multiple concurrent namespaces over the same distributed data. This enables different applications, business units, digital twins, and AI agents to operate against the view most appropriate for their objectives without requiring data duplication or restructuring.

Summary

AnyLog treats the UNS as a distributed metadata layer rather than a centralized repository. The namespace is represented as JSON metadata objects that define assets, relationships, context, and data mappings.

Because the UNS is logical rather than physical, organizations can create multiple concurrent namespaces over the same distributed data while keeping data at the edge. Applications, users, and AI agents can each operate against the namespace most appropriate for their use case without changing the underlying data.

As new equipment, data sources, and requirements emerge, the UNS can be updated simply by modifying metadata policies, enabling a continuously evolving operational model without moving, duplicating, or restructuring the underlying data.