Paper deep dive
The AnyLog Edge Data Fabric
Roy Shadmon, Mark Davidson, Eric Aquaronne, Massimiliano Pinto, Ori Shadmon, Moshe Shadmon
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 89%
Last extracted: 8/3/2026, 1:49:05 AM
Summary
The paper introduces the AnyLog Edge Data Fabric (EDF), an agent-based platform designed to manage operational data at the edge while presenting distributed resources as a single logical system. It addresses the latency and scalability issues of centralized cloud architectures by keeping data local and moving computation to the data source. Key components include the Distributed Metadata Layer, Virtual Data Lake, Unified Namespace, and Model Context Protocol, enabling real-time AI, federated learning, and resilient decision-making without single points of failure.
Entities (10)
Relation Signals (8)
AnyLog Edge Data Fabric → includes → Virtual Data Lake
confidence 95% · Applications query a Virtual Data Lake rather than individual databases
AnyLog Edge Data Fabric → includes → Distributed Metadata Layer
confidence 95% · Through its Distributed Metadata Layer... authorized users... can discover
AnyLog Edge Data Fabric → includes → Unified Namespace
confidence 95% · physical assets and their relationships are organized through one or more Unified Namespaces
AnyLog Agent → hasrole → Publisher
confidence 90% · A Publisher is used when the system collecting data... lacks the compute or storage resources
AnyLog Agent → hasrole → Operator
confidence 90% · An Operator stores operational data... By managing data near the assets they represent
AnyLog Agent → hasrole → Query Coordinator
confidence 90% · A Query Coordinator acts as the gateway to the Edge Data Fabric
Model Context Protocol → usedby → AI Agents
confidence 88% · AI agents access the same operational context... through AnyLog’s Model Context Protocol
AnyLog Edge Data Fabric → supports → Federated Learning
confidence 85% · AnyLog provides a cloud-like operating model for... federated learning
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Industrial and autonomous systems increasingly depend on AI, automation, and real-time coordination to act on operational data as it is generated. Yet conventional architectures often require that data to pass through centralized platforms before decisions can be made. Cloud systems remain valuable for training, reporting, and long-term analytics, but they add latency and external dependencies to the critical decision path and become harder to scale as each new site adds additional edge devices and data. As intelligence spreads across machines, sites, facilities, and vehicles, continued dependence on centralization will constrain response time, resilience, scalability, and autonomous operation. This paper presents the AnyLog Edge Data Fabric, an agent- and edge-based platform that manages operational data at its source while presenting distributed data, assets, compute resources, and services as one logical system. Through its Distributed Metadata Layer, Virtual Data Lake, Unified Namespace, Single System Image, and Model Context Protocol, authorized users, applications, automation services, and AI agents can discover, query, process, and act on distributed resources without knowing where they are hosted. Queries and computation execute at the agents holding the relevant data, so only requests and results traverse the network. This preserves local ownership, reduces data movement, supports continued operation during connectivity disruptions, and enables repeatable deployment from validated digital-twin configurations. AnyLog provides a cloud-like operating model for distributed SQL, real-time automation, Edge AI, federated learning, and resilient decision-making without a single point of failure or any dependence on centralized infrastructure.
Tags
Links
- Source: https://arxiv.org/abs/2607.28836v1
- Canonical: https://arxiv.org/abs/2607.28836v1
Trouble viewing inline? Open PDF directly →
Full Text
102,210 characters extracted from source content.
Expand or collapse full text
The AnyLog Edge Data Fabric Roy Shadmon, PhDMark DavidsonEric Aquaronne Massimiliano PintoOri ShadmonMoshe Shadmon Abstract Industrial and autonomous systems increasingly depend on AI, automation, and real- time coordination to act on operational data as it is generated. Yet conventional architec- tures often require that data to pass through centralized platforms before decisions can be made. Cloud systems remain valuable for training, reporting, and long-term analytics, but they add latency and external dependencies to the critical decision path and become harder to scale as each new site adds additional edge devices and data. As intelligence spreads across machines, sites, facilities, and vehicles, continued dependence on central- ization will constrain response time, resilience, scalability, and autonomous operation. This paper presents the AnyLog Edge Data Fabric, an agent- and edge-based platform that manages operational data at its source while presenting distributed data, assets, compute resources, and services as one logical system. Through its Distributed Meta- data Layer, Virtual Data Lake, Unified Namespace, Single System Image, and Model Context Protocol, authorized users, applications, automation services, and AI agents can discover, query, process, and act on distributed resources without knowing where they are hosted. Queries and computation execute at the agents holding the relevant data, so only requests and results traverse the network. This preserves local ownership, re- duces data movement, supports continued operation during connectivity disruptions, and enables repeatable deployment from validated digital-twin configurations. AnyLog pro- vides a cloud-like operating model for distributed SQL, real-time automation, Edge AI, federated learning, and resilient decision-making without a single point of failure or any dependence on centralized infrastructure. 1 Introduction2 2 The AnyLog Architecture4 2.1 The AnyLog agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 2.2 The Distributed Metadata and Policy Layer . . . . . . . . . . . . . . . . . . . .5 2.3 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 2.4 Virtualizing the Distributed Environment . . . . . . . . . . . . . . . . . . . . .8 3 Distributed Query Processing10 3.1 Distributed Querying Across In-Place Data . . . . . . . . . . . . . . . . . . . . 10 3.2 A Distributed Query Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Distributed Real-Time Video AI Analytics . . . . . . . . . . . . . . . . . . . . . 13 4 Building a Unified Foundation for Edge Intelligence14 4.1 Process Data Where It Resides . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Coordinate the Fabric Through Shared Metadata . . . . . . . . . . . . . . . . . 15 4.3 Local Autonomy at Horizontal Scale Without Central Dependency . . . . . . . 16 4.4 Integrate Through Open Standards and MOSA Principles . . . . . . . . . . . . 17 1 arXiv:2607.28836v1 [cs.ET] 30 Jul 2026 5 Bridging the Physical Edge to Applications and AI18 5.1 Automatic Schema Creation and Management . . . . . . . . . . . . . . . . . . . 18 5.2 Dynamic Operational Context Through Unified Namespaces . . . . . . . . . . . 19 5.3 Projecting UNS Structures as a Knowledge Graph . . . . . . . . . . . . . . . . 20 5.4 Southbound Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.5 Northbound Interfaces For Enterprise Integration . . . . . . . . . . . . . . . . . 22 6 Operating the Distributed Platform22 6.1 Simplifying Distributed Operations through a Single System Image . . . . . . . 22 6.2 Configuration-Driven, One-Click Deployment . . . . . . . . . . . . . . . . . . . 23 6.3 Observability and Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.4 Policy-Governed Multi-Organization Collaboration . . . . . . . . . . . . . . . . 24 6.5 Distributed Security and Local Policy Enforcement . . . . . . . . . . . . . . . . 25 7 Building an AI-Native Edge Data Platform27 7.1 The Operational Foundation for Industrial AI . . . . . . . . . . . . . . . . . . . 27 7.2 Robust Decision-Making for Nonstationary Physical Systems . . . . . . . . . . 28 7.3 Enabling Federated Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8 Conclusion29 8.1 Looking Beyond the Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2 An Architecture Designed to Evolve . . . . . . . . . . . . . . . . . . . . . . . . 29 8.3 Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1 Introduction The next generation of industrial AI depends on bringing intelligence to the data rather than moving operational data to centralized platforms. As autonomous systems take greater responsibility for monitoring, coordination, and control, direct access to current conditions at the edge becomes a fundamental architectural requirement. Industrial systems cannot afford to discover critical events only after data has been transmitted, processed, and centralized. A failing manufacturing cell can stop an entire production line, instability at one substation can cascade across the grid, an autonomous vehicle can lose critical routing context when remote services are unavailable, and a deteriorating patient can cross a critical threshold while relevant data is still moving through the system. In each case, the value of an observation declines rapidly with time: information that could have prevented a failure becomes evidence explaining why it occurred. Centralized architectures make this delay difficult to avoid because operational data must often be transmitted, ingested, normalized, and stored before applications can use it. Alerting systems, rule engines, automation services, and AI consequently operate on a delayed repre- sentation of the physical environment rather than its current state [1, 2]. Network disruptions, ingestion backlogs, and synchronization delays can further postpone detection and response or interrupt the decision path(s) entirely. The problem worsens as deployments expand. Every new facility, vehicle, production line, or plant adds data that the shared network, ingestion, storage, and processing infrastructure must absorb, increasing reliance on historians, enterprise databases, data warehouses, and cloud data lakes. These systems remain essential for process history, compliance, auditing, reporting, retention, and large-scale analytics [3, 4, 5], but they inherently introduce architec- tural risk when they are also the default path for real-time decisions, causing local operations to depend on the capacity, availability, and responsiveness of centralized infrastructure. 2 Figure 1: AnyLog EDF separates the distributed data plane from the logical control and access plane. Operational records remain in local databases at each site, while metadata, query routing, and virtualization layers provide applications, administrators, and AI with a unified view of distributed data, assets, and infrastructure. The architectural requirement is therefore twofold: time-sensitive processing must remain close to operational data, and authorized applications, machines, and AI agents must be able to reason across relevant observations that span across the edge rather than from isolated local views. This is essential for enabling autonomous operations like lights-out factories, where AI, analytics, rule execution, and machine-to-machine coordination operate continuously [6, 7]. The critical decision path thus requires an operational layer that makes edge data immediately available through a unified view, while forwarding selected records, key events, and summaries to centralized systems for retention, compliance, reporting, and enterprise analytics. This paper presents the AnyLog Edge Data Fabric (EDF), an edge-based platform that deploys lightweight software agents across geographically distributed environments to man- age operational data as one continuously connected system. As illustrated in Figure 1, data remains in the local databases closest to the machines, facilities, vehicles, and devices that generate it, while AnyLog presents the associated data, metadata, compute resources, ser- vices, and assets through a unified logical platform. Authorized users, applications, automa- tion services, and AI agents can issue requests through governed interfaces without knowing where the relevant resources are physically located. AnyLog discovers the appropriate agents, coordinates distributed execution, and returns a unified result [8, 9, 10]. This cloud-like operating model is expressed through several complementary views. Ap- plications query a Virtual Data Lake rather than individual databases, physical assets and their relationships are organized through one or more Unified Namespaces (UNS) [11], administrators manage the deployment through a Single System Image, and AI agents ac- cess the same operational context and platform services through AnyLog’s Model Context Protocol (MCP) server hosted by each agent. The architecture is built on three simple principles: 3 1. Keep operational data where it is generated. 2. Move processing to the data. 3. Share metadata rather than raw data. The remainder of this paper explains how these principles are realized within the AnyLog Edge Data Fabric. Although the examples focus on industrial and autonomous systems, the architecture applies wherever distributed data must be discovered, processed, and acted upon in real-time without sacrificing locality, ownership, performance, or resilience. The sections that follow develop these principles into the complete AnyLog architecture. Section 2 describes how autonomous AnyLog agents implement the platform, and Section 3 covers distributed SQL execution. Section 4 explains how the modular, distributed design integrates new data sources and sites, adapts as deployments evolve, and presents the expand- ing environment as one unified data platform. Section 5 describes integration with sensors, historians, databases, applications, and cloud platforms. Section 6 addresses management, observability, diagnostics, and security, while Section 7 extends the architecture to Edge AI, federated learning, and mobile autonomous systems. Section 8 concludes the paper. 2 The AnyLog Architecture 2.1 The AnyLog agent The fundamental building block of the platform is the AnyLog agent: independently oper- ating software that can run on industrial gateways, embedded computers, edge servers, virtual machines, cloud instances, Raspberry Pis, or enterprise servers. Every agent uses the same core software and can assume one or more operational roles, including data collection, storage, query execution, and agentic services. These roles are configured according to the compute, memory, storage, and network resources available on each device, allowing a single software stack to support deployments ranging from lightweight data collection to fully integrated data, query, and AI systems. An Operator stores operational data in locally managed databases, enforces the policies governing access to that data, and makes authorized records available for distributed queries and services. Operators execute queries over their local data, apply filtering and aggregation, and return raw records, query results, or key events. By managing data near the assets they represent, each Operator contributes a subset of the data available through the fabric’s unified logical view. A Publisher is used when the system collecting data from PLCs or sensors lacks the compute or storage resources to retain and manage that data locally. The Publisher captures raw data near its source and forwards it to an Operator or another configured destination. A Query Coordinator acts as the gateway to the Edge Data Fabric. It receives requests from users, applications, dashboards, automation services, or AI agents; uses metadata to locate the Operators that host the relevant data and services; coordinates execution across participating Operators; and returns a unified result. An MCP Provider serves as a Query Coordinator for authorized AI agents, exposing the Edge Data Fabric through a local Model Context Protocol server [12]. It provides governed access to distributed data, tools, schemas, asset relationships, and platform state without requiring the AI agent to discover or manage the AnyLog agents hosting those resources. A Metadata Manager distributes the shared metadata required for discovery, policy enforcement, and coordination. Metadata Managers synchronize information about schemas, 4 data locations, agent capabilities, access policies, services, and Unified Namespace relation- ships so that agents can locate resources and cooperate without point-to-point configuration. In deployments that require a more decentralized coordination model, metadata can also be alternatively managed through a blockchain-backed layer. Programmable smart contracts allow agents to publish, synchronize, and receive metadata updates through distributed mech- anisms such as publish-subscribe [13, 14, 15]. 2.2 The Distributed Metadata and Policy Layer Cooperation among AnyLog agents depends on a shared understanding of the distributed environment. The Distributed Metadata Layer provides this common view by describing what data, assets, services, and agents exist, where they reside, how they relate, and how they may be accessed. Because metadata is far smaller than the operational data itself (Section 4.2), it can be synchronized efficiently across the Edge Data Fabric, giving each agent the context needed to discover and use distributed resources. Policies translate this shared context into enforceable behavior. They define how agents are configured and how data and services are accessed, processed, retained, shared, and protected. Enforcement remains local to the agents responsible for each resource, preserving consistent governance without introducing a central control dependency. Node Policies enable repeatable, one-click deployment by defining how agents configure themselves for one or more operational roles, as described in Section 6.2. A policy may reference deployment scripts, database settings, services, security requirements, and other role-specific configuration. The configuration is defined once, reused across multiple agents, and automatically reapplied when an agent joins or restarts. Multiple policies may exist for the same role, allowing each Operator, Publisher, Query Coordinator, or other agent to follow the configuration assigned to its environment. Access Policies define which identities may access specific services, databases, tables, and time ranges. These policies are distributed through the metadata layer and enforced locally by the agent that owns the requested data or service. If no applicable policy authorizes the request, access is denied. Table Policies define a logical table within the Edge Data Fabric. They describe its schema, the Operators that host the data, the physical database and table mappings, and the metadata required for AnyLog to discover the data and execute distributed queries through a single logical table. Unified Namespace Policies define the hierarchical relationships among assets. Each policy identifies a root asset and maps its parent-to-child structure, such as an organization containing facilities, a facility containing production lines, a line containing machines, and a machine containing sensors. These relationships create consistent logical paths that enable users, applications, and AI agents to discover and access the data, services, and metadata associated with any asset or branch of the hierarchy without requiring the underlying data to be physically reorganized or centralized in systems such as MQTT brokers, historians, or cloud platforms. Rule Engine Policies define how agents evaluate incoming events, execute scheduled actions, and respond to operational conditions without waiting for a centralized application. A policy may specify that if a PLC fault bit changes from 0 to 1, torque on a fastening cell exceeds its accepted range for five consecutive cycles, or temperature moves outside a permitted band, the agent should write an alert row, publish a Unified Namespace update, send an SMS or email notification, forward the event to a historian, or invoke a downstream workflow. Because these rules execute locally, time-sensitive responses continue even when wide-area connectivity is slow, intermittent, or unavailable. 5 Aggregation Policies define how high-volume observations are reduced into useful sum- maries. If 10,000 consecutive inputs report the same value, an agent may store one row containing the start timestamp, end timestamp, received-record count, and observed value rather than retaining 10,000 identical records. The same principle can be applied to toler- ance bands, allowing readings that remain within ±ε to be represented by their time span, count, representative value, and observed bounds. Policies may also define time-windowed aggregates, such as storing the count, sum, minimum, maximum, median, and average of a measurement stream every 10 minutes. This reduces storage and network demand by enabling pre-processing directly at the edge. Retention and Forwarding Policies define how long different classes of data remain at the edge and which information is forwarded to enterprise systems. A deployment may retain detailed raw records locally for 10 days while sending selected summaries, regulated records, significant events, alarms, and alerts to a historian or cloud repository through native northbound connectors. As data ages, policies may archive it to object storage, file systems, cloud repositories, or other approved storage systems. The schemas and archive locations remain represented in the Distributed Metadata Layer so that historical information stays discoverable across storage tiers. Replication Policies preserve access to selected datasets, summaries, and event streams when an Operator becomes unavailable. According to policy, the specified data is replicated to designated agents, and each replica is represented in the table metadata under the same cluster identifier as the primary. During query planning, if the primary agent is unavailable, the Distributed Query Engine routes the request to an available replica within that cluster, as described in Sections 2.3 and 2.4. Together, the Distributed Metadata Layer and its associated policies allow autonomous agents to operate as one coordinated platform. The metadata establishes a shared view of the environment, while locally enforced policies create a single system image view across data management, automation, security, resilience, query execution, and AI access. 2.3 System Model Let N = n 1 ,...,n k denote the set of AnyLog agents participating in a deployment. Each agent n∈N maintains a local policy set P n , a local metadata view M n synchronized through the Distributed Metadata Layer, and a set D n of local data stores, which may include SQL databases, NoSQL stores, and object or blob stores such as S3-compatible buckets, and which may be empty for agents that do not store operational records. Let T =pub, op, meta, qry denote the set of agent types, corresponding respectively to publisher (pub), operator (op), metadata-manager (meta), and query (qry) roles. Each agent is assigned a role profile τ :N → 2 T , where τ (n) may contain one or more roles because the same AnyLog runtime can be configured to combine them. The roles are interpreted as follows. • If pub ∈ τ (n), agent n can collect or receive source data and publish it to one or more operator agents. This role is useful when the machine closest to the data source is resource-constrained and cannot be utilized for storage or query processing. • If op∈ τ (n), agent n operates as an Operator: it stores operational data in one or more local data stores, including SQL databases, NoSQL systems, and object or S3-like blob 6 stores. It executes the supported retrieval, filtering, aggregation, or query operations over its local data and returns records or partial results for distributed execution. • If meta ∈ τ (n), agent n acts as a metadata manager in deployments that do not use blockchain-backed metadata synchronization. In that mode, metadata-manager agents disseminate metadata updates and answer metadata queries for discovery and coordi- nation. • If qry ∈ τ (n), agent n can accept client requests, resolve metadata, coordinate dis- tributed queries, and return unified results. Define the operator-agent subset N op =n∈N | op∈ τ (n). Only operator agents host local table fragments. Publisher agents feed data into operator agents, query coordinators coordinate requests, and metadata-manager agents are needed only in manager-based metadata deployments. Metadata dissemination follows one of two deployment modes. In blockchain-backed de- ployments, agents synchronize against the shared blockchain ledger-backed metadata state and the metadata-manager role may be omitted. In manager-based deployments, let N meta =n∈N | meta∈ τ (n) denote the metadata-manager subset responsible for propagating and serving metadata. The application-facing logical data surface is a setV of virtual tables. Each virtual table is identified by a tuple v = (c,d,t)∈V where c is a logical grouping, d is a logical DBMS name, and t is a logical table name. Physical placement is described by a metadata mapping μ :V → 2 N op ×R×K where R is the set of serving roles, such as primary, backup, or partition member, and K is the set of cluster identifiers. If (n,r,k)∈ μ(v), then agent n can serve virtual table v in role r within cluster k. For each agent n and virtual table v, let F n (v) denote the local fragment of v stored on n. By default, AnyLog treats virtual tables as partitioned: different agents generally hold different fragments, and the logical table is the union of those fragments across the eligible serving agents. Let N (v) =n∈N op |∃r ∈R,k ∈K : (n,r,k)∈ μ(v). Then the logical content of v is v ≡ [ n∈N(v) F n (v). When a replication policy ρ v is enabled, selected fragments may also be copied periodically to designated backup agents. Replication therefore improves availability, but does not change the logical definition of v. Query planning selects one eligible copy of each replicated fragment so that replicated storage does not duplicate logical query results. A distributed query q over a virtual table v is evaluated by selecting an eligible participant set S(q,v) ⊆ N (v) from metadata, local policies, and replica eligibility. Each participating 7 CompanyDBMSLogical Table Smart City cos wpanalog pppm monitoring agent insight AnotherPeak battery packlogs packcurrent CarPlant assembly fastening Eon windturbine bladepitch power output Table 1: Representative get virtual tables output from the AnyLog test network. This view exposes only the logical surface visible to applications and administrators: Company, DBMS, and Logical Table. Physical placement, partitioning, and replica membership are revealed separately through get data nodes. agent evaluates q on its local fragment and returns either records or partial aggregates. The coordinator then computes Ans(q,v) = Combine (Eval(q,F n (v))| n∈ S(q,v)). This captures the main semantics of the Virtual Data Lake: applications see one logical table even though storage, policy enforcement, and most execution remain distributed. 2.4 Virtualizing the Distributed Environment The purpose of the AnyLog architecture is to abstract the complexity of distributed edge infrastructure by presenting it as a Single System Image (SSI), allowing users, applications, and AI agents to discover, access, and manage distributed resources through a unified logical interface. As illustrated in Figure 2, the three virtualization layers work together to create this user-facing view, with the Layer 3 SSI serving as the final interface through which the underlying distributed environment is accessed and managed. The Virtual Data Lake presents distributed operational edge data as though it were contained within a single logical database. Applications query distributed data using standard SQL without needing to know where data is physically stored, described in Section 3. The Unified Namespace provides a logical representation of industrial assets indepen- dent of the databases that contain their operational information. Applications and AI nav- igate logical assets and their relationships, while the mapping layer resolves the underlying physical systems and relational tables. Multiple namespaces can coexist to support different operational perspectives over the same distributed data. The Single System Image virtualizes the infrastructure itself. Administrators moni- tor and manage geographically distributed agents through a unified operational view that resembles the experience of managing a centralized cloud platform. Together, these three virtualization layers transform a distributed collection of autonomous systems into a cloud- like operational environment where operational data remains local, processing executes at the edge, and every agent retains its autonomy. At the logical layer, the AnyLog operational command get virtual tables lists the DBMSs and tables available for distributed SQL queries, organized by their logical grouping, as shown in Table 1. The command presents the application-facing view of the queryable SQL tables in the fabric. The AnyLog command get data nodes exposes the physical topology behind each virtual table, as shown in Table 2. Applications continue to address resources through the logical tuple 8 Company DBMS Logical Table ClusterID AnyLog agentEndpoints Cluster Interpretation Smart City cos wp analog 64999c P 203.0.113.41:32148 B 198.51.100.44:32148 Replicated water-plant partition. Because both endpoints share cluster64999c , they are backup members of the same physical partition. p pm 2a5f83 P 192.0.2.14:32148 B 198.51.100.37:32148 Replicated power-plant partition. The shared cluster identifier meansthat the primary and backup members serve the same physical partition. monitoring agent insight 2a5f83 P 192.0.2.14:32148 B 198.51.100.37:32148 Power-plant monitoring partition, replicated within one cluster. 64999c P 203.0.113.58:32148 B 192.0.2.63:32148 Water-plant monitoring partition, also replicated within one cluster. 22be8c P 198.51.100.89:32148 Wastewater monitoring partition with one serving member. Different cluster IDs under the same logical table indicate independent partitions. AnotherPeak battery pack logs fec25e P 203.0.113.103:32148 Vessel partition A. ec5697 P 198.51.100.122:32148 Vessel partition B. The logical table spans two clusters, so the data is partitioned across independent clusters. pack current ec5697 P 198.51.100.122:32148 Derived current-data partition A. fec25e P 203.0.113.103:32148 Derived current-data partition B. The table follows the same two-cluster distribution pattern as pack logs . CarPlant assembly fastening 353495 P 192.0.2.131:32148 Manufacturing-cell partition 1. 0b8b65 P 203.0.113.147:32148 Manufacturing-cell partition 2. 65614e P 198.51.100.166:32148 Manufacturing-cell partition 3. 4d1c94 P 192.0.2.184:32148 Manufacturing-cell partition 4. Four independent assembly cells contribute records to one plant-wide logical table. Eon wind turbine blade pitch 4b07f4 P 198.51.100.214:32148 Turbine partition 1. 9366a P 203.0.113.201:32148 Turbine partition 2. f6294d P 192.0.2.227:32148 Turbine partition 3. 14866e P 203.0.113.239:32148 Turbine partition 4. The same logical table is distributed across four independent turbine clusters. power output 9366a P 203.0.113.201:32148 Output partition 1. 4b07f4 P 198.51.100.214:32148 Output partition 2. f6294d P 192.0.2.227:32148 Output partition 3. 14866e P 203.0.113.239:32148 Output partition 4. Multiple logical tables can share the same cluster topology while exposing different operational metrics. Table 2: Landscape summary of representative get data nodes entries from the AnyLog test network. Company , DBMS , and Logical Table define the logical data surface, while the shortened Cluster ID and endpoint columns expose the physical AnyLog serving pattern. Endpoints sharing a cluster ID are backup or replica members of the same physical partition; different cluster IDs under the same logical table are independentpartitions. 9 of Company, DBMS, and Table, while AnyLog maps each request to the clusters and agents currently serving that resource. Agents sharing a cluster identifier represent primary (P ) or backup (B) are members of the same physical partition, whereas different cluster identifiers under one logical table represent independent data fragments that AnyLog unifies under the same DBMS and table name. If a primary agent becomes unavailable, the Distributed Query Engine routes the request to a backup; if no backup exists, the query summary identifies the unavailable agent and tags the result as incomplete. In the examples above, Smart City combines replicated and single-member partitions, AnotherPeak distributes vessel data across two clusters, CarPlant presents four manufactur- ing cells through one logical table, and Eon exposes tables spanning four clusters of remote wind turbines. The Company field adds multi-tenant organization and isolation to this log- ical model. For example, CompanyA may operate a production facility while CompanyB and CompanyC represent equipment and component suppliers. Each tenant discovers and queries only its authorized resources, while Access Policies permit approved tables or selected records to be shared across company boundaries. Section 5.1 explains how schemas for newly observed tables are generated and reused. The core virtualization concept is that once a logical table is defined, the same table can be queried as one logical resource even when the rows are partitioned across many agents. AnyLog therefore allows tables to be distributed at the level that best reflects operational requirements, including by plant, production line, manufacturing cell, asset class, supplier domain, or geographic region. 3 Distributed Query Processing 3.1 Distributed Querying Across In-Place Data For decades, enterprise data platforms have followed the same basic pattern: operational data is moved into a centralized repository before applications can query, analyze, or act on it. Co-locating data with a single query engine simplifies processing, but the model becomes increasingly costly and difficult to scale as industrial operations grow more distributed. High- volume data must be continuously transmitted from remote sites, shared ingestion and storage infrastructure must expand to absorb that growth, and applications may act on delayed replicas while pipelines, transformations, and synchronization complete. AnyLog queries operational data in place by moving computation to the agents that host the data, rather than transferring the data to a centralized processing platform. When an application submits a request, AnyLog uses the Distributed Metadata Layer (Section 2.2) to identify the agents containing relevant data, executes the query locally and in parallel across those agents, and returns only the records, aggregates, or derived results needed to satisfy the request. The underlying operational data remains in the local databases managed by independent AnyLog agents. From the application’s perspective, the distributed environment behaves as a single logical database. The same query model applies whether the requested data resides on one agent, across several facilities, or throughout thousands of geographically distributed systems. Any- Log resolves relevant data locations, coordinates execution, enforces applicable access policies, and combines partial results into one unified response. 3.2 A Distributed Query Engine Applications submit standard SQL through AnyLog’s command interface, REST APIs, or Model Context Protocol (MCP) server. The command-line form is: 10 Figure 2: Architecture overview of AnyLog EDF. Autonomous agents keep operational data local, publish metadata to the distributed control plane, and expose their resources through three logical views: a Virtual Data Lake for data access, one or more Unified Namespaces for asset context, and a Single System Image for platform operations. 11 Figure 3: Five-step distributed query-processing workflow. run client () sql [dbms] SELECT [columns | aggregation] FROM [table] WHERE [clause] The target list in parentheses determines how the request is routed. An empty target list, (), indicates that the requester does not know which agents host the required data. AnyLog resolves the logical DBMS and table through the Distributed Metadata Layer, identifies the authorized agents that have declared relevant data, and routes the query accordingly. When specific destinations are known or required, they may be supplied explicitly: run client ([ip1:port1], [ip2:port2], ...) sql [dbms] SELECT [columns | aggregation] FROM [table] WHERE [clause] In this form, the request is sent only to the listed agents. The same SQL statement can therefore be executed through automatic data-location discovery or against an explicitly selected set of nodes. As illustrated in Figure 3, the AnyLog agent receiving the request temporarily assumes the role of Query Coordinator (Section 2.1). When automatic discovery is used, the coordinator consults the Distributed Metadata Layer to determine the relevant Operators that host data associated with the query. When destinations are specified explicitly, those agents define the initial execution scope, subject to local authorization and data availability. The Query Coordinator builds an execution plan and distributes the SQL query to the relevant agents, which execute filtering, aggregation, and retrieval locally and in parallel using their own resources. Each agent returns only the required records or partial aggregates, such as counts, sums, minima, or maxima. The Query Coordinator combines these results, applies any remaining global operations, and returns a single unified response. 12 Figure 4: AnyLog video architecture extending distributed telemetry capture to support real-time edge inference, with inference results and telemetry stored in local SQL databases, associated video retained in local blob storage, and unified access across independently oper- ating edge devices. Notably throughout this process, the underlying operational datasets remain in their local databases. Only query instructions and compact result sets traverse the network, reducing unnecessary data movement while allowing distributed information to be queried through one logical interface. 3.3 Distributed Real-Time Video AI Analytics AnyLog extends the Single System Image beyond relational databases to include locally man- aged object storage, such as MinIO [16] and MongoDB [17]. Video segments and inference metadata remain distributed in local blob stores and SQL databases across edge devices, while the Distributed Query Engine provides searchability through one logical query interface. 1 At each edge device, the AnyLog agent captures video through Southbound Interfaces such as RTSP (Section 5.4). AI models running on the device or nearby infrastructure ac- cess the live stream through Northbound Interfaces such as gRPC (Section 5.5) and perform inference on each incoming frame. Object classifications, confidence scores, timestamps, cam- era identifiers, locations, and user-defined tags are stored as structured telemetry in a local 1 Blobs may also be stored in cloud services such as Amazon S3 [18]. AnyLog abstracts each storage location as another participating edge, allowing a single SQL query to locate matching video segments any blob storage location without requiring applications implement custom APIs and middleware. 13 SQL database. The corresponding video segments remain in local blob storage, with each record referencing its supporting footage. As illustrated in Figure 4, this makes otherwise unstructured video searchable despite the video and metadata remaining at each edge. For example, the AnyLog query below searches video inference telemetry across the logical table video inferenceevents and returns the associated blob reference, time range, detected object class, count, confidence score, and tags. The extend clause adds the site, camera, and hosting-agent metadata for each result, while the selection clause maps each record to its referenced video segment hosted in the logical table blobreference so the supporting footage can be retrieved directly from the physical storage location. Notably, the video segments and inference telemetry is fragmented across any number of edge devices; AnyLog builds the the query plan and fully automates the distributed query execution: sql video_ai info=(dest_type=rest) and extend=(+site_name, +camera_id, @ip, @port, @dbms_name, @table_name) SELECT blob_reference, segment_start_ts::ljust(19), segment_end_ts::ljust(19), object_class, object_count, confidence_score, inference_tags FROM video_inference_events WHERE insert_timestamp >= NOW() - 20 minutes ORDER BY object_count DESC, confidence_score DESC --> selection (columns: ip using ip and port using port and dbms using dbms_name and table using table_name and file using blob_reference) A conventional cloud-centric architecture sends camera streams across the wide-area net- work (WAN) to centralized ingestion, storage, and analytics services. Detections and alerts typically become available only after the video is processed and the resulting telemetry reaches a centralized cloud database, while custom software must correlate those records with the stored blobs and video segments [19, 20]. By managing video streaming and inference at the edge, the amount of data transmitted across the WAN is limited to only the segments or blobs the application or agent needs. The architecture also scales horizontally, as described in Sec- tion 4.3: each added camera, inference server, or edge device contributes capacity to the same logical environment without requiring applications to manage each resource independently. 4 Building a Unified Foundation for Edge Intelligence 4.1 Process Data Where It Resides Keeping data local determines where operational records reside; processing data where it resides determines how those records are used without first centralizing them. When a request spans multiple locations, AnyLog decomposes the request and directs computation to the AnyLog agents that host the relevant data, described in Section 3. Each participating agent uses its local processing resources to query, filter, aggregate, analyze, or apply AI inference to the data, returning only the information required to construct the final result. The query node then aggregates these partial results and presents them as a unified, complete result to the requesting application or AI agent. This execution model keeps raw operational records in place. Query instructions and the metadata needed to identify relevant participants are sent to the appropriate agents, while compact records, partial aggregates, or derived results are returned to the requester. Network utilization therefore depends primarily on the size of the request and its result rather than on the volume of underlying data, details in Section 4.2. Consider an automotive manufacturer operating robotic fastening cells across multiple production facilities. Each facility stores its fastening events locally using the logical table 14 automotivefasteningevents. An application can submit the following query to any autho- rized AnyLog agent: SELECT plant_id, COUNT(*) AS failed_fastenings, AVG(torque_nm) AS average_failed_torque FROM automotive_fastening_events WHERE event_timestamp >= TIMESTAMP'2026-07-12 15:30:00' AND result_code ='FAIL' GROUP BY plant_id; Using the Distributed Metadata Layer (Section 2.2) AnyLog resolves the table policy for automotive fasteningevents. This policy defines the logical table and identifies the au- thorized AnyLog agents that host relevant data. Similar to MapReduce [21], AnyLog then executes the query concurrently across those agents. Each participant filters its local records and computes a partial result containing the failure count, torque sum, and number of torque observations. These compact intermediate results are returned and combined to produce the global failure count and average failed torque for each plant. The query operates across the manufacturer without first transferring every fastening event to a central historian, enterprise database, or cloud data lake. Each cell can contribute observations as soon as they are captured, so query freshness depends primarily on local processing latency rather than the completeness of centralized ingestion pipelines, and only the request and partial results traverse the network. As data volumes grow, ingestion, storage, and computation scale horizontally across additional AnyLog agents. Separate agents may collect different streams and perform filtering, aggregation, event detection, preprocessing, or inference in parallel, while computationally intensive workloads are assigned to agents with greater processing capacity. The coordination benefit is as important as the computational benefit. A manufacturer operating six plants with eight fastening cells per plant would typically need to maintain 48 endpoint definitions, credential bindings, schema mappings, broker topics, and failover procedures. With AnyLog, the application integrates once with the logical table automotive fasteningevents or a Unified Namespace pattern such as Plant/Area/Line/Cell/*. When a new cell is added, it publishes its metadata and policies and becomes discoverable through the existing interface, eliminating the need for a new application-level integration. 4.2 Coordinate the Fabric Through Shared Metadata A distributed platform requires a common understanding of the resources available across the system. Applications and AI agents must be able to discover datasets, determine which agents host relevant information, understand schemas, identify industrial assets and services, and evaluate security policies without requiring administrators to configure every participating agent manually. AnyLog addresses this requirement by separating the platform’s shared knowledge from its operational data. Operational data remains in the local databases managed by each AnyLog agent. Agents publish compact metadata that describes what data, services, resources, and policies they make available. This metadata forms a shared, dynamic operational knowledge layer through which users, applications, and AI agents can discover resources, coordinate and distribute work, enforce security and operational policies, and cooperate while allowing each participant to query the underlying data and metadata. When an agent creates, adopts, updates, or removes a dataset, it publishes metadata de- scribing the corresponding logical table, schema, physical location, ownership, Unified Names- pace relationships, available services, and the policies governing access, security, retention, replication, and other lifecycle requirements, as discussed in Section 2.2. This metadata is 15 dynamically discovered and synchronized across the Edge Data Fabric, allowing newly avail- able or changed resources to become visible without requiring reconfiguration. AnyLog can therefore abstract the distributed platform behind a single logical API while reducing unnec- essary broadcasts, centralized data movement, and overall network traffic. For example, suppose that 1,000 industrial sensors each generate one 100-byte record per second. Excluding protocol overhead, continuously transmitting those records to a centralized repository would transfer approximately: 1,000× 100× 86,400 = 8.64 GB per day. Assume, conservatively, that each sensor is described by a 4-KB metadata record contain- ing its identifier, schema, logical table, agent location, asset relationship, and access policy, and that every descriptor is retransmitted once per hour. Metadata synchronization would transfer approximately: 1,000× 4,096× 24 = 98.3 MB per day. Under these assumptions, this metadata-first coordination model reduces daily transmis- sion by approximately (98.9 The same effect appears at the workload level. Suppose 40 fastening cells each emit 100 records per second at 100 bytes per record, and a plant dashboard needs one-minute failure counts and average torque values. Shipping raw telemetry to a central service would move approximately 40× 100× 60× 100 = 24 MB per minute before protocol overhead. If the same request is executed locally, each cell can return only a few partial aggregates, reducing the response to the order of kilobytes. On fixed and local networks, such as Ethernet, fiber, and Wi-Fi, this reduces congestion; on metered cellular or satellite backhaul, it reduces recurring operating cost directly. This approach follows established in-network aggregation techniques, which have shown that processing data near its source can reduce communication costs by an order of magnitude compared with centralized collection [22]. 4.3 Local Autonomy at Horizontal Scale Without Central Dependency AnyLog scales horizontally by distributing data, processing, and services across independently operating edge agents. Each additional AnyLog agent contributes its own data, compute, storage, and services, allowing platform capacity to grow without concentrating demand on centralized infrastructure. Like peer-to-peer systems, it separates discovery from storage: Napster indexed files retained by participating computers, while BitTorrent allowed peers to exchange portions of a file concurrently and contribute partial network capacity [23, 24]. AnyLog applies a related principle to operational computing by using shared metadata to discover distributed data, resources, and services while keeping storage and execution local to each agent. As new AnyLog agents join, they contribute both workload and additional compute, storage, and services to the fabric. A Single System Image (Section 6.1) then presents these resources to applications and AI agents as one logical system [25, 1]. New sites and devices may publish data to an existing agent or deploy additional Any- Log agents. Once a new agent publishes its metadata and policies, its data, services, and resources become discoverable through the fabric’s existing interfaces without requiring ap- plications to be reconfigured. Each added agent also contributes compute, memory, storage, 16 and services, allowing platform capacity to grow horizontally alongside the workload rather than accumulating on centralized infrastructure: C platform = n X i=1 C i , where C i = C compute i ,C memory i ,C storage i ,C services i Capacity therefore expands across operational sites rather than accumulating on a central gateway, server, or cluster [25, 1]. Unlike centralized scale-out platforms that must absorb data from every remote site [26], AnyLog makes each site part of the computing platform. Agents ingest and process data locally, execute requests concurrently, and return partial results that a Query Coordinator combines into a unified response. Cooperation does not create a dependency on continuous global connectivity. Each agent continues collecting data, executing local queries, enforcing security policies, running automa- tion, and supporting local applications without a central coordinator or cloud service. During a disruption, the fabric contracts to the agents reachable within the current network parti- tion; connected agents continue coordinating, while unreachable agents become temporarily excluded. This allows queries to remain partially satisfied by connected replicas, avoiding the complete operational disruption common with centralized architectures [1, 2]. Associ- ated with each query result is a query summary that includes which agents participated and what data may be missing. Once connectivity returns, agents refresh their metadata and resume broader coordination without restarting local workloads. This is particularly valuable in denied, disconnected, intermittent, and low-bandwidth environments [27]. Retention policies complete the model. Current observations remain near the physical process while they are most valuable, while older records, summaries, and selected events may be offloaded or replicated to higher-capacity agents, object stores, historians, or cloud platforms [28]. Edge storage and computation remain focused on current operations and local AI inference, while cloud resources continue supporting training, long-term retention, reporting, and enterprise analytics [29, 30, 31, 32, 33, 34]. 4.4 Integrate Through Open Standards and MOSA Principles AnyLog is designed in alignment with the Department of Defense’s Modular Open Systems Approach (MOSA), which promotes modular architectures, open interfaces, interoperability, and the ability to integrate or replace components without redesigning the complete sys- tem [35]. AnyLog applies these principles through a common agent runtime, configurable node roles, standards-based interfaces, and loosely coupled services that can be deployed, upgraded, or expanded independently. Through southbound interfaces such as OPC UA [36], MQTT [37], Modbus [38], REST [39], gRPC [40, 41], and standard database connectors, AnyLog captures data from industrial equipment, control systems, historians, databases, and external applications. Through north- bound interfaces such as SQL, REST APIs, gRPC, and the Model Context Protocol (MCP) [42], it exposes distributed data and services to applications, analytics platforms, automation sys- tems, and AI agents. This modular, standards-based architecture allows AnyLog to operate as an independent data layer across heterogeneous hardware, operating systems, networks, and deployment en- vironments. Organizations can introduce AnyLog incrementally, retain existing systems of record and operational workflows, and integrate new technologies through open interfaces rather than proprietary point-to-point dependencies. 17 5 Bridging the Physical Edge to Applications and AI 5.1 Automatic Schema Creation and Management One of the most persistent challenges in distributed industrial environments is schema frag- mentation. Equipment, applications, and databases are often configured independently by different vendors, integrators, and facilities, causing the same operational data to be rep- resented through different table structures, field names, units, and data types. Preventing these inconsistencies typically requires extensive coordination across teams and sites, slowing deployment, integration, and future expansion. AnyLog addresses this through automatic schema creation and distributed management. When new data is ingested, the receiving agent consults the Distributed Metadata Layer to determine whether an existing table policy describes it. If a matching policy exists, the agent adopts the established schema. Otherwise, it generates a schema from the incoming data and publishes the new definition to the metadata layer, making it immediately discoverable and reusable by other agents receiving similar data. This process allows new data sources to join the fabric through a plug-and-play model without requiring a separate integration project. Ingested data, physical observations, and AI-generated predictions, classifications, recommendations, and other insights remain stored locally, while their schemas, locations, relationships, and access policies become discoverable through the metadata layer. Existing definitions can then be reused as the deployment ex- pands, maintaining a consistent platform-wide data model regardless of scale. For example, an AnyLog agent monitoring a robotic fastening cell in an automotive as- sembly plant may register the logical table name automotive fasteningevents together with the following schema in the Distributed Metadata Layer: table_name: automotive_fastening_events cell_id: str station_id: str robot_id: str vehicle_model: str operation: str event_timestamp: datetime torque_nm: float angle_deg: float cycle_time_ms: int result_code: str fault_code: str | null The metadata definition may also specify units of measurement, required fields, accepted value ranges, indexing rules, retention policies, and relationships among the production cell, station, robot, vehicle model, and assembly operation. A different agent may later receive the following JSON object from a newly commissioned fastening cell: "cell_id": "CELL-27", "station_id": "ST-04", "robot_id": "RB-112", "vehicle_model": "EV-X", 18 "operation": "battery_tray_fastening", "event_timestamp": "2026-07-12T15:42:18.421Z", "torque_nm": 86.4, "angle_deg": 137.2, "cycle_time_ms": 1840, "result_code": "PASS", "fault_code": null Before storing the object, the receiving agent derives its structural signature and con- sults the Distributed Metadata Layer for a compatible schema. It compares the incoming field names and value types against the registered definition, confirming, for example, that cell id is a string, eventtimestamp is a datetime, torquenm is a floating-point value, and cycletimems is an integer. When the schema matches, the agent adopts the existing logical table, creates the cor- responding local storage structure, validates or converts the incoming values, and declares through the metadata layer that it contains compatible data. An application can then issue a query such as: SELECT cell_id, station_id, robot_id, result_code, FROM automotive_fastening_events WHERE event_timestamp >= NOW() - 5 minutes AND result_code ='FAIL'; which is resolved through the logical table name and distributed to every authorized agent that has declared data conforming to the automotive fasteningevents schema. This includes the agent that originally registered the schema and any newly commissioned agents that adopted it. Each agent evaluates the query against its local data, returns its partial result set, and the Distributed Query Engine combines the partial results into one unified response. The new production cell becomes immediately available to existing distributed SQL queries, dashboards, quality-control applications, and AI models without manual schema replication, centralized data movement, or changes to application logic. As deployments grow to thou- sands of edge agents, new data sources automatically join the fabric, allowing applications and AI models to continue operating without reconfiguration. 5.2 Dynamic Operational Context Through Unified Namespaces Relational tables organize operational data into rows and columns that applications can query using SQL, but they do not fully represent the physical systems, assets, and relationships that give those records meaning. AnyLog complements relational data models with one or more logical Unified Namespaces (UNS) that organize distributed assets according to the operational environment and how users need to access the data, independent of how the data was captured or where it is physically stored. A UNS represents assets through a root, parent, and child hierarchy. In a manufacturing environment, this structure may follow: Plant / Area / Line / Cell / Station / Asset / MeasurementOrService UNS policies published through the Distributed Metadata Layer define how each semantic path maps to the relevant tables, columns, filters, services, agents, databases, and connectors. This allows operators, dashboards, MES applications, quality systems, and AI agents to navi- gate the same operational environment according to their respective workflows and analytical 19 needs. One user may organize data by plant, line, cell, and station, while another maps the same records by robot type, product family, maintenance condition, quality state, or utility resource. Each view resolves to the same distributed data without requiring the underlying storage or management to be changed or duplicated. For example, the path CarPlant / BodyShop / Line3 / Cell27 / FasteningStation04 / Torque / CurrentValue "uns": "name": "FasteningStation04/Torque/CurrentValue", "namespace":"MI/BodyShop/Line3/Cell27/FasteningStation04/Torque/CurrentValue", "uns_level": "measurement", "dbms": "automotive", "table": "automotive_fastening_events", "column": "torque_nm", "data_type:unit": "float:Nm", "parent": "fastening_station_04_policy_id" The policy links the semantic path to the torque nm column in the logical table automotive fasteningevents and applies the filters identifying the corresponding plant, area, line, cell, and station. It also supplies contextual information such as the data type, engineering unit, measurement type, and parent relationship. Applications can therefore request the current torque value through the UNS path while AnyLog resolves the underlying data source and query automatically. The same distributed records can support multiple Unified Namespaces and levels of analy- sis, from a single asset or production line to conditions spanning multiple facilities. Production teams may organize data by plant, line, and cell; maintenance systems by equipment type or condition; and quality applications by product or process stage. Unlike MQTT-centric namespace designs, where operational views are coupled to broker topics and topic hierar- chies [43, 37, 44], AnyLog defines semantic views through metadata policies. This allows multiple namespaces to organize the same underlying data without republishing, duplicating, or relocating records. Because these semantic paths remain stable as agents, databases, sites, communication protocols, and broker topologies evolve, applications and AI agents can con- tinue navigating and querying the data through their established namespace paths without modification. 5.3 Projecting UNS Structures as a Knowledge Graph A Unified Namespace organizes assets along hierarchical operational paths, but hierarchy alone cannot fully represent many-to-many relationships, cross-functional dependencies, or assets that participate in multiple contexts. Projecting UNS policies as a Knowledge Graph extends these paths into an interconnected model of the operational environment, making relationships among assets, measurements, services, applications, users, and policies directly visible [45]. Figure 5, for example, shows a fastening station shared across production, maintenance, and quality views. Connecting these perspectives through the same asset allows users and AI agents to move across operational contexts, discover related data and services, and determine 20 Figure 5: Projected UNS knowledge graph for an industrial fastening station. The orange dashed ring and paths identify an overlap dependency: Fastening Station A is referenced across production, maintenance, and quality namespace views. By making this shared con- text explicit, the graph helps users understand where an asset is used, which systems de- pend on it, and what may be affected before a policy, mapping, equipment, or data-model change is made. In this example, a change to Fastening Station A can be traced across upstream namespace context and downstream dependencies, including PLC-17, Robot Con- troller, Torque/Vibration sensors, Analytics App, and Maintenance CMMS. This provides enterprise-wide impact visibility without centralizing operational data, since AnyLog brings the query to the data and only the result sets back. how changes may affect sensors, controllers, applications, and workflows, which improves discovery, dependency analysis, and safer change management. The strategic importance of industrial knowledge graphs is reflected in Schneider Electric’s 2026 agreement to acquire Cognite for 3.1 billion [46]. Cognite Data Fusion creates this context by ingesting and transforming industrial data within a cloud-based platform. AnyLog delivers a similar view but notably through a distributed architecture: UNS policies maintained in the Distributed Metadata Layer define the knowledge graph, while operational data remains managed and hosted at the edge by AnyLog agents. Because relationships are defined logically through metadata policies, AnyLog can expand and update the graph without first consolidating the underlying data. Enterprises gain a shared contextual model while avoiding unnecessary duplication, synchronization delays, net- work demands, and centralized infrastructure costs. As new assets, applications, users, and relationships publish UNS policies, the graph expands through a plug-and-play process while the operational data remains distributed at the edge. 5.4 Southbound Integration Operational data enters the AnyLog platform through Southbound Connector Services. These services establish communication with industrial devices, applications, and databases using industry-standard protocols and interfaces. The connector framework is intentionally modular. Each AnyLog agent enables only the 21 connectors required for its deployment, allowing the same software platform to operate effi- ciently on embedded gateways, industrial servers, enterprise systems, or cloud infrastructure. Connectors are activated through configuration, enabling organizations to adapt deployments without modifying application code. The platform includes native support for widely adopted industrial and enterprise tech- nologies such as OPC UA, MQTT, Modbus, REST, gRPC, relational databases, object stor- age, file-based interfaces, and RTSP for live video streaming. Because the framework is open, organizations can also integrate proprietary systems or leverage third-party connectors when required. Regardless of the protocol, every connector performs the same architectural function. It acquires operational information and streams it to the local AnyLog agent. From that point forward, the ingestion process is fully automated and governed by policies. Incoming data is normalized, existing schemas are reused or new schemas are generated automatically when not provided. Policies determine how the data is retained, archived, replicated, aggregated, monitored, and secured, while making it available through the platform’s unified APIs. Once ingested, the original communication protocol becomes largely irrelevant—the data is now part of the distributed platform and can be consumed consistently by applications, administrators, and AI regardless of how it was acquired. 5.5 Northbound Interfaces For Enterprise Integration Applications, dashboards, enterprise systems, analytics platforms, automation tools, and AI agents interact with the Edge Data Fabric through a common set of northbound interfaces. SQL and REST provide familiar query and application access, gRPC and Kafka [47] support event-driven integration, and MCP allows AI agents to discover and invoke distributed data, tools, services, and contextual resources. Through these same interfaces, users, applications, and AI agents can query data stored across the edge and in connected historians through one API. Within the fabric, a historian is represented as another edge through additional table policies, described in Section 2.2, allowing current and archived data to be accessed through a single edge data platform. Since distributed data and metadata are exposed through a single API, SQL queries and native AnyLog commands can be issued using standard tools such as Postman [48] or inte- grated directly into applications. AnyLog also includes the AnyLog Edge Data Manager (EDM) [49], which provides administrators and developers with a graphical Single System Image for exploring, querying, testing, monitoring, configuring, and operating the distributed platform. Through the same GUI interface, users can navigate asset relationships in the Unified Namespace, compare metrics stored across multiple agents, interact with the fabric through the native MCP client, and inspect returned records and files. 6 Operating the Distributed Platform 6.1 Simplifying Distributed Operations through a Single System Image Deploying a distributed edge system is only the beginning of the operational challenge. As hundreds or thousands of gateways, servers, and industrial computers come online, administra- tors must determine where data resides, monitor platform health, diagnose failures, distribute policies, enforce security, and coordinate services while tracking device-specific addresses, configurations, software versions, databases, credentials, and dependencies. In conventional deployments, these point-to-point responsibilities multiply with every new system, causing management complexity to grow faster than the engineers available to manage it. Rather 22 than operating a collection of silos, AnyLog provides a Single System Image through which administrators, applications, and AI agents interact with distributed data, compute resources, and services as though they belonged to one unified, cloud-like system. Through a unified interface, administrators can: • discover agents, roles, datasets, metadata, and services; • inspect databases, schemas, policies, and data locations; • monitor agent health and resource utilization; • track replication, aggregation, and automation activity; and • execute distributed queries and perform administrative operations. For example, an automotive manufacturer may operate 600 AnyLog agents across assembly plants, supplier facilities, test environments, and distribution centers. The SSI presents these resources as one operational platform while allowing administrators to filter the environment by facility, production line, agent role, software version, available service, or current state. The SSI can also provide the operational foundation for an edge Digital Twin [50, 51, 52, 53]. Because agents publish metadata describing their identities, capabilities, datasets, services, configurations, policies, and availability, the SSI can reproduce the logical struc- ture and observable state of the distributed environment without centralizing its underlying operational data. The metadata state can be copied into a development environment, digital twin, or newly deployed system using: blockchain seed from [ip:port] This command initializes an authorized AnyLog agent outside the production environment with the schemas, policies, asset relationships, services, and resource locations known to the production fabric. Users can therefore reproduce the logical structure of an existing deployment, test configurations and workflows locally, and later apply the same metadata- defined roles and deployment instructions to production agents. When permitted by policy, the replicated environment may also receive a limited subset of operational data—for example, only 100 rows or records from an approved historical time range—allowing a functional digital twin to be created quickly without exposing the complete production dataset. The SSI remains the common interface for observing and managing both the modeled environment and the deployed physical edge. 6.2 Configuration-Driven, One-Click Deployment Industrial integration is traditionally implemented as a series of custom software projects: building connectors, mapping schemas, exposing APIs, and repeating the process for every new site, device, or application. As deployments expand, these one-off integrations accumulate into complex, brittle systems that are costly to maintain. AnyLog replaces custom integration with a configuration-driven deployment model. Reusable configuration files and metadata Node Policies (Section 2.2) define each agent’s roles, connec- tors, data sources, schemas, interfaces, services, network settings, and security policies. The same runtime can therefore be deployed at the edge, in operations centers, or in cloud environ- ments, with each instance configured from a shared knowledge base rather than implemented as a separate integration project. 23 Once defined, configurations can be deployed and replicated automatically across geo- graphically distributed sites [54]. The same model integrates with orchestration platforms such as IBM Open Horizon [55], IBM Edge Application Manager (IEAM) [56], and Dell Dis- tributed Private Cloud (formerly NativeEdge) [57]. Configuration and policy updates are published once through the Distributed Metadata Layer and automatically discovered by the relevant agents, while local policies allow individual sites to accommodate differences in equipment, regulations, network conditions, and security requirements. 6.3 Observability and Diagnostics Operating a distributed data platform requires visibility into both the fabric as a whole and the individual systems that compose it. AnyLog observability spans agents, databases, datasets, services, policies, and distributed operations. Administrators can locate logical tables, inspect metadata declarations, monitor replication and backup activity, review aggregation and au- tomation processes, and trace the execution of distributed queries across participating agents. Using the query status command, users can trace a distributed query and identify: • the agent that coordinated the request; • the metadata used to select participants; • the agents to which the request was distributed; • the execution time reported by each participant; • the number of records or partial aggregates returned; • agents that were unavailable or rejected the request; and • the operations used to combine the partial results. For example, a query may execute against production data stored at 27 facilities. If 26 agents respond within milliseconds but one requires several seconds, the query status command allows the user to identify the slow agent. Applications may also configure the run client SQL command with subset=true and timeout=2 seconds, instructing AnyLog to return a unified view of the available partial results when an agent does not respond within two seconds, rather than delaying the entire query: run client () sql [dbms] subset=true and timeout=2 seconds SELECT ... The returned response identifies the agents that participated and those that were un- available or timed out, allowing the application to determine whether the result is complete. Additional diagnostic services allow administrators to verify connectivity, inspect local re- source utilization, analyze metadata synchronization, review policy execution, and examine platform activity without establishing a separate administrative session with every machine. 6.4 Policy-Governed Multi-Organization Collaboration Most deployments use AnyLog to unify resources within one organization. The same archi- tecture can also support controlled collaboration among manufacturers, suppliers, equipment vendors, logistics providers, utilities, contractors, and customers. Collaboration is optional and policy-driven. Each organization operates its own agents and selectively publishes metadata describing the datasets, services, or derived information it 24 chooses to make available. Other participants can discover those resources, but access remains subject to the policies enforced by the organization that owns them. For example, an automotive manufacturer may allow a robotic-equipment supplier to access failure summaries for the supplier’s installed robots. The supplier can analyze the authorized information across multiple plants without receiving the manufacturer’s complete production database or gaining administrative control over plant infrastructure. Policies can also define the permitted depth of collaboration. One partner may be allowed only aggregate SQL such as COUNT, AVG, MAX, or anomaly summaries across all cells using its equipment. Another may be allowed row-level SELECT statements on approved logical tables but only for whitelisted columns such as timestamp, fault code, torquenm, and robotid. Namespace access can be constrained in the same way: a supplier may be allowed to navigate a UNS branch such as CarPlant / BodyShop / Line3 / RobotVendorX / * while being unable to inspect unrelated lines, product models, utilities, or columns outside that collaboration boundary. Organizations determine: • which resources are discoverable; • which identities may request them; • which query classes are permitted, such as approved aggregations or row-level SELECT statements; • whether access applies to raw records or derived results; • which UNS branches, logical tables, or columns are visible to a partner; • which operations may be executed; • how frequently information may be requested; and • whether results may leave the local environment. Multiple organizations can therefore deploy AnyLog independently and still cooperate through a shared logical platform while preserving their own databases and ownership bound- aries. The data owner continues to enforce the policy boundary at the source agent, while the consumer experiences only the approved logical view. 6.5 Distributed Security and Local Policy Enforcement AnyLog does not treat network membership as proof of trust. Each agent is assigned a cryp- tographic identity managed in software or protected by a hardware-based Trusted Platform Module (TPM) [58]. Agents use these identities to authenticate requesters and participat- ing systems, establish encrypted channels, protect data in transit, and enforce access policies where each protected resource resides [59]. Access Policies define which identities may access specific services, databases, tables, and time ranges. Published through the Distributed Metadata Layer, they provide a shared view of authorized access while preserving local enforcement. Before executing a service or returning data, the agent responsible for the resource authenticates the requester and verifies that an applicable policy permits the request. A Query Coordinator may discover resources and coordinate execution, but it cannot expand or override the permissions enforced by the agents hosting them. 25 This design also limits the impact of a compromised identity. Stolen credentials may expose resources already authorized for that identity [60], but they do not grant fabric-wide access or bypass policies enforced by other agents. The potential damage remains bounded by the compromised identity’s assigned permissions, and revoking those permissions prevents subsequent access [59, 60]. 6.5.1 Security Policy Model AnyLog uses a whitelist-based authorization model. Access policies published through the Distributed Metadata Layer define which authenticated users, applications, and AI agents may access specific services and data resources; requests without a matching policy are denied. For example, an equipment supplier may query fault counts for the machines it maintains but not access raw production data or unrelated equipment. The agent hosting the data authenticates the requester and enforces the permitted scope, ensuring that authorization is controlled by the resource owner rather than the requester. Let a request be represented as x = (i,s,d,T , ∆), where i is the authenticated requester identity, s is the requested AnyLog service, d is the requested database, T is the set of requested tables, and ∆ is the requested time range. A component may be omitted when it is not applicable to the requested service. An access policy published through the Distributed Metadata Layer is represented as p = (S p ,G p , ∆ p ), where S p is the set of authorized requester identities, ∆ p is the permitted time range, and G p ⊆S×D× 2 T is the set of authorized service S, database D, and table scopes 2 T . Each element (s p ,d p ,T p )∈ G p defines one permitted combination. The table scope T p may identify one table, a subset of tables, or all tables within the authorized database. A policy p authorizes request x when i∈ S p , and there exists an authorized scope (s p ,d p ,T p )∈ G p such that s = s p , d = d p , T ⊆T p ,∆⊆ ∆ p . LetP M denote the access policies available through the Distributed Metadata Layer. The authorization decision is therefore Allow(x) ⇐⇒ ∃p∈P M such that p authorizes x. If no policy authorizes the complete request, the request is denied: 26 ¬ Allow(x) ⇐⇒∄p∈P M such that p authorizes x. For distributed queries, the Query Coordinator identifies the agents holding the requested data and forwards the authenticated request context to them. Each participating agent evalu- ates the applicable policies obtained through the Distributed Metadata Layer before executing the service or satisfying the request. The Query Coordinator thus coordinates execution and combines authorized results, but it cannot grant access or override the authorization decision enforced where the requested resource resides. This initial model focuses on authorization for services, databases, tables, and time ranges. The same whitelist-based structure can be extended to govern columns, row predicates, Uni- fied Namespace branches, permitted aggregation functions, result formats, model artifacts, file services, and whether data may be returned as raw records or only as policy-approved summaries. 7 Building an AI-Native Edge Data Platform 7.1 The Operational Foundation for Industrial AI The primary barrier to industrial AI is no longer access to capable models; it is giving those models immediate, governed access to operational data, metadata, and services. To monitor equipment, diagnose failures, coordinate production, and initiate actions safely, AI must un- derstand current conditions, schemas and units, asset relationships, available services, system state, and the policies governing what it may access and execute. Today, this context remains fragmented across historians, databases, cloud platforms, asset-management systems, and application-specific APIs, forcing each new AI application to depend on custom connectors, synchronized datasets, and static schema mappings. One consequence is agent sprawl [61, 62]. Without a unified interface to the operational environment, developers deploy specialized agents for individual systems and tasks, each with its own connectors, credentials, schema mappings, and application logic. One agent may query historian data, another access MES or ERP systems, another retrieve maintenance records, and others invoke control services or enterprise applications. As operational systems expand, the number of agents, connectors, and synchronization workflows grows with them, increasing deployment complexity, management overhead, and security exposure. Each agent also retains only a partial view of the environment, making coordinated reasoning, consistent governance, and uniform access control increasingly difficult. A scalable approach to industrial AI requires a shared operational foundation that can ex- pand across applications, agents, assets, and sites. AnyLog provides this foundation through the Edge Data Fabric, which presents distributed data, metadata, compute resources, ser- vices, and policies as one governed logical environment. The Distributed Metadata Layer identifies available resources, their locations, relationships, and access rules; the Virtual Data Lake provides a common data model; the Unified Namespace adds operational con- text; the Distributed Query Engine executes computation where the data resides; and the Single System Image makes the expanding environment manageable as one platform. With this foundation, new applications and AI agents can build on the same data, meta- data, services, and policies instead of introducing another isolated integration stack. As assets, sites, datasets, services, and models join the fabric, they become available through the same logical interfaces, allowing industrial AI to expand across the enterprise without needing spe- cialized middleware connectors, duplicated mappings, and synchronization workflows [33, 34]. 27 7.2 Robust Decision-Making for Nonstationary Physical Systems As AI assumes greater responsibility for physical operations, the fault and attack surface changes. Decisions may depend not only on human-in-the-loop inputs, which can be de- layed, incorrect, or manipulated, but also on observations generated by autonomous robots, vehicles, machines, and sensors that may be noisy, faulty, compromised, or operating from different perspectives. Because these inputs affect movement, coordination, production, and safety, they must be evaluated at the edge and protected against individual errors before they influence the critical decision path [63]. Low-latency access alone does not ensure that a decision accurately reflects the physi- cal environment. Multiple robots may observe the same event differently because of sensor noise, changing positions, communication delays, equipment faults, human error, or malicious behavior. Where redundant observations exist, fault-tolerant decision-making must combine them without allowing one incorrect input to lead to a consequential outcome. Byzantine agreement enables consistent decisions despite faulty or malicious inputs [64, 65], but traditional protocols often depend on repeated coordination and eventual conver- gence. Emerging approaches such as Proximal Byzantine Agreement (PBA) make robust edge decision-making more practical through one-shot statistical inference that bounds faulty influence while also quantifying decision uncertainty [66, 67]. AnyLog provides the distributed data-access layer needed to apply these methods with the Unified Namespace paths: CarPlant/BodyShop/Floor/Robot-[A|B|C]/Objects/Forklift-17/ Position The associated UNS policies resolve these paths to the relevant logical table, fields, and filters. A decision process can retrieve the latest observations through a distributed query: SELECT robot_id, object_id, position_x, position_y, confidence, observation_timestamp FROM robot_object_observations WHERE object_id ='Forklift-17' AND observation_timestamp >= CURRENT_TIMESTAMP - INTERVAL'2' SECOND; AnyLog identifies the agents holding the observations, retrieves the authorized records concurrently, and returns them as one logical dataset. PBA or another sensor-fusion protocol can then estimate the forklift’s position while limiting the influence of noisy and faults [68, 69]. 7.3 Enabling Federated Learning Federated learning allows multiple sites to collaboratively train a model without centralizing raw data [70, 71, 72]. Each participant trains on its local data and shares only model updates, which are aggregated into a new global model. This preserves data locality, ownership, and privacy while incorporating patterns learned across participating sites. This model aligns naturally with the AnyLog Edge Data Fabric. Local databases provide access to training data, the Distributed Metadata Layer coordinates participants, policies, and training rounds, and file services exchange model artifacts. The logical query interface binds each training task to authorized local tables without moving the underlying data. EdgeFL [73] is a programming framework that uses AnyLog as the infrastructure and or- chestration layer for federated learning and real-time distributed inference. It supports both designated-aggregator and decentralized configurations, allowing participating agents to co- ordinate training and aggregate updates independently. In either model, training rounds are coordinated through the Shared Metadata Layer. Each training agent monitors the meta- data layer, queries its authorized local data through SQL, trains independently, and publishes its model update. Because AnyLog already provides distributed data access, authorization, 28 Mobile agent A local sensors + local DB Mobile agent B local sensors + local DB Mobile agent C local sensors + local DB AnyLog EDF shared metadata, logical assets, policy-governed data access, real-time operational view Cloud / Datacenter / Satellite Backhaul summaries, aggregations, history, key events, alerts Byzantine Agreement when state is disputed local agreement Figure 6: AnyLog supplies the shared operational view for mobile autonomous systems, while a Byzantine-resilient agreement protocol resolves disputed state only when needed. The safety- critical path remains local; cloud, datacenter, or satellite links remain optional for summaries, history, and model distribution. coordination, and artifact exchange, federated learning and inference operate as native appli- cations on the Edge Data Fabric without requiring a separate infrastructure stack. 8 Conclusion 8.1 Looking Beyond the Cloud The future of distributed computing is not cloud-only or edge-only, but a coordinated model in which workloads execute where it is most effective. Cloud platforms remain valuable for large-scale model training, enterprise analytics, long-term storage, and fleet-wide reporting, while time-sensitive inference and operational decisions increasingly require direct access to current conditions near sensors, machines, and physical processes [74, 2]. AnyLog enables this model by treating the cloud as one participant in a distributed com- puting environment rather than the operational destination for all data and computation. Through the Distributed Metadata Layer, distributed query execution, Unified Namespace, and Single System Image, the AnyLog platform enables data, services, and AI to operate as a single logical system while allowing operational data to remain at its source. Policies deter- mine what remains local, what is processed at the edge, and which data, results, or workloads are forwarded to cloud resources. 8.2 An Architecture Designed to Evolve Industrial systems will continue to evolve as new protocols, databases, storage technologies, hardware accelerators, AI models, and communication methods emerge across increasingly distributed environments. A platform tightly coupled to any one technology risks becoming obsolete or requiring costly redesign whenever that dependency changes. AnyLog absorbs this evolution by separating the logical platform presented to users from the physical technologies that implement it. Connectors isolate data acquisition behind config- 29 urable southbound interfaces; logical tables separate applications from distributed databases; metadata decouples resource discovery from physical topology; the Unified Namespace sep- arates asset identity from storage organization; northbound APIs hide distributed execution from consuming applications; and MCP provides AI agents with a standardized interface to the Edge Data Fabric. Protocols, databases, models, agents, and services can as a result be introduced, upgraded, or replaced by modifying the appropriate connector, policy, metadata, or configuration layer rather than redesigning every dependent application. Although new technologies may still require integration work, AnyLog confines that work to its standardized or custom north- bound and southbound interfaces while preserving a consistent Single System Image across the operational environment. 8.3 Final Thoughts The central challenge at the operational edge is no longer simply collecting more data. It is making distributed data immediately understandable, accessible, and actionable without forcing every site, machine, vehicle, and application through a centralized decision path. AnyLog addresses this challenge by turning independently operating edge systems into one cooperative platform while preserving their ability to function locally. This creates a practical foundation for industrial AI and automation. Applications and AI agents can discover available resources, interpret operational context, query current and historical data, and invoke authorized services through a consistent logical environment. Deci- sions execute at or near the physical systems they affect, while enterprise and cloud platforms remain available for training, long-term analysis, reporting, compliance, and other workloads suited to centralized infrastructure. AnyLog gives organizations a practical path to seamlessly modernize operations without replacing the systems already in place. It begins with one machine, production line, facility, or vehicle fleet; connect existing data sources; expose them through the Single System Image; and expand by adding AnyLog agents as requirements and trust grow. What begins as a focused solution to today’s needs becomes infrastructure that grows more capable and valuable with every new asset, site, service, and intelligent application. References [1] W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, “Edge computing: Vision and challenges,” IEEE internet of things journal, vol. 3, no. 5, p. 637–646, 2016. [2] M. Iorga, L. Feldman, R. Barton, M. J. Martin, N. S. Goren, and C. Mahmoudi, “Fog computing conceptual model,” 2018. [3] Y. Lu, M. Perisic, and A. Jones, “Additive manufacturing data integration and recom- mended practice,” 2023. [4] D. Theodoratos, T. Sellis et al., “Data warehouse configuration,” in VLDB, vol. 97, 1997, p. 126–135. [5] R. Hai, C. Koutras, C. Quix, and M. Jarke, “Data lakes: A survey of functions and systems,” IEEE Transactions on Knowledge and Data Engineering, vol. 35, no. 12, p. 12 571–12 590, 2023. 30 [6] C. J. Turner, R. Ma, J. Chen, and J. Oyekan, “Human in the loop: Industry 4.0 tech- nologies and scenarios for worker mediation of automated manufacturing,” IEEE access, vol. 9, p. 103 950–103 966, 2021. [7] S. Liu, L. Liu, J. Tang, B. Yu, Y. Wang, and W. Shi, “Edge computing for autonomous driving: Opportunities and challenges,” Proceedings of the IEEE, vol. 107, no. 8, p. 1697–1716, 2019. [8] D. Abadi, O. Arden, F. Nawab, and M. Shadmon, “Anylog: a grand unification of the internet of things,” in Conference on Innovative Data Systems Research (CIDR ‘20), 2020. [9] F. Nawab and M. Shadmon, “The tipping point of edge-cloud data management.” CIDR, 2024. [10] M. Shadmon, L. Cohen, D. Abadi, and O. Arden, “System and apparatus to manage data using a peer-to-peer network and the blockchain,” U.S. Patent 10,868,865, Dec. 2020, filed November 20, 2018; issued December 15, 2020. [Online]. Available: https://patents.google.com/patent/US10868865B2/en [11] ́ A. P ́eter and S. Werner, “The impact of unified namespace in industry 4.0,” 2024. [12] ModelContextProtocol,“Modelcontextprotocolspecification,”https: //modelcontextprotocol.io/specification/2025-11-25, 2025, specification version 2025- 11-25; accessed July 13, 2026. [13] S. N. Khan, F. Loukil, C. Ghedira-Guegan, E. Benkhelifa, and A. Bani-Hani, “Blockchain smart contracts: Applications, challenges, and future trends,” Peer-to-peer Networking and Applications, vol. 14, no. 5, p. 2901–2925, 2021. [14] H. Zheng, T. Tran, R. Shadmon, and O. Arden, “Decentagram: Highly-available de- centralized publish/subscribe systems,” in 2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2024, p. 274–287. [15] Z. Cai, G. Yang, S. Xu, C. Zang, J. Chen, P. Hang, and B. Yang, “Rbaas: A robust blockchain as a service paradigm in cloud-edge collaborative environment,” IEEE Access, vol. 10, p. 35 437–35 444, 2022. [16] MinIO, “Minio object storage for linux,” https://min.io/docs/minio/linux/index.html, 2025, minIO Documentation. Accessed: 2026-07-30. [17] MongoDB, “GridFS for self-managed deployments,” https://w.mongodb.com/docs/ manual/core/gridfs/, 2026, mongoDB Database Manual. Accessed: 2026-07-30. [18] Amazon Web Services, “What is amazon s3?”https://docs.aws.amazon.com/ AmazonS3/latest/userguide/Welcome.html, 2026, amazon Simple Storage Service User Guide. Accessed: 2026-07-30. [19] Amazon Web Services, “What is amazon kinesis video streams?”https://docs. aws.amazon.com/kinesisvideostreams/latest/dg/what-is-kinesis-video.html, 2026, ama- zon Kinesis Video Streams Developer Guide. Accessed: 2026-07-30. [20] Amazon Web Services, “Working with streaming video events,” https://docs.aws. amazon.com/rekognition/latest/dg/streaming-video.html, 2026, amazon Rekognition Developer Guide. Accessed: 2026-07-30. 31 [21] J. Dean and S. Ghemawat, “Mapreduce: simplified data processing on large clusters,” Communications of the ACM, vol. 51, no. 1, p. 107–113, 2008. [22] S. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, “Tag: A tiny aggregation service for ad-hoc sensor networks,” ACM SIGOPS Operating Systems Review, vol. 36, no. SI, p. 131–146, 2002. [23] C. H. Ding, S. Nutanong, and R. Buyya, “Peer-to-peer networks for content sharing,” in Peer-to-Peer Computing: The Evolution of a Disruptive Technology.IGI Global Scientific Publishing, 2005, p. 28–65. [24] B. Cohen et al., “Incentives build robustness in bittorrent,” in Workshop on Economics of Peer-to-Peer systems, vol. 6, 2003, p. 68–72. [25] R. Cattell, “Scalable sql and nosql data stores,” Acm Sigmod Record, vol. 39, no. 4, p. 12–27, 2011. [26] D. DeWitt and J. Gray, “Parallel database systems: The future of high performance database systems,” Communications of the ACM, vol. 35, no. 6, p. 85–98, 1992. [27] U.S. Department of Defense, “Department of defense command, control, and communications (C3) modernization strategy,” U.S. Department of Defense, Tech. Rep., Sep. 2020, accessed: July 14, 2026. [Online]. Available: https://dodcio.defense.gov/ Portals/0/Documents/DoD-C3-Strategy.pdf [28] A. Ali-Eldin, B. Wang, and P. Shenoy, “The hidden cost of the edge: a performance comparison of edge and cloud latencies,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2021, p. 1–12. [29] R. Singh and S. S. Gill, “Edge ai: a survey,” Internet of Things and Cyber-Physical Systems, vol. 3, p. 71–92, 2023. [30] T. Meuser, L. Lov ́en, M. Bhuyan, S. G. Patil, S. Dustdar, A. Aral, S. Bayhan, C. Becker, E. De Lara, A. Y. Ding et al., “Revisiting edge ai: Opportunities and challenges,” IEEE Internet Computing, vol. 28, no. 4, p. 49–59, 2024. [31] C. Surianarayanan, J. J. Lawrence, P. R. Chelliah, E. Prakash, and C. Hewage, “A survey on optimization techniques for edge artificial intelligence (ai),” Sensors, vol. 23, no. 3, p. 1279, 2023. [32] S. S. Gill, M. Golec, J. Hu, M. Xu, J. Du, H. Wu, G. K. Walia, S. S. Murugesan, B. Ali, M. Kumar et al., “Edge ai: A taxonomy, systematic review and future directions,” Cluster Computing, vol. 28, no. 1, p. 18, 2025. [33] A. Kusiak, “Smart manufacturing,” International journal of production Research, vol. 56, no. 1-2, p. 508–517, 2018. [34] J. Wan, X. Li, H.-N. Dai, A. Kusiak, M. Martinez-Garcia, and D. Li, “Artificial- intelligence-driven customized manufacturing factory: key technologies, applications, and challenges,” Proceedings of the IEEE, vol. 109, no. 4, p. 377–398, 2020. [35] Office of the Under Secretary of Defense for Research and Engineering. (2025) Modular open systems approach. U.S. Department of Defense. [Online]. Available: https://w.cto.mil/sea/mosa/ 32 [36] W. Mahnke, S.-H. Leitner, and M. Damm, OPC unified architecture. Springer Science & Business Media, 2009. [37] B. Mishra and A. Kertesz, “The use of mqtt in m2m and iot systems: A survey,” Ieee Access, vol. 8, p. 201 071–201 086, 2020. [38] G. Thomas, “Introduction to the modbus protocol,” The Extension, vol. 9, no. 4, p. 1–4, 2008. [39] A. Murali, P. Raj et al., Hands-On RESTful API Design Patterns and Best Practices: Design, develop, and deploy highly adaptable, scalable, and secure RESTful web APIs. Packt Publishing Ltd, 2019. [40] X. Wang, H. Zhao, and J. Zhu, “Grpc: A communication cooperation mechanism in distributed systems,” ACM SIGOPS Operating Systems Review, vol. 27, no. 3, p. 75– 86, 1993. [41] gRPC Authors. (2024) Introduction to grpc. Official gRPC documentation. [Online]. Available: https://grpc.io/docs/what-is-grpc/introduction/ [42] X. Hou, Y. Zhao, S. Wang, and H. Wang, “Model context protocol (mcp): Landscape, security threats, and future research directions,” ACM Transactions on Software Engi- neering and Methodology, 2025. [43] O. Standard, “Mqtt version 5.0,” Retrieved June, vol. 22, no. 2020, p. 1435, 2019. [44] Eclipse Sparkplug Contributors, “Sparkplug specification,” Eclipse Foundation, Specifi- cation 3.0.0, Nov. 2022, accessed: July 14, 2026. [Online]. Available: https://sparkplug. eclipse.org/specification/version/3.0/documents/sparkplug-specification-3.0.0.pdf [45] S. Ji, S. Pan, E. Cambria, P. Marttinen, and P. S. Yu, “A survey on knowledge graphs: Representation, acquisition, and applications,” IEEE transactions on neural networks and learning systems, vol. 33, no. 2, p. 494–514, 2021. [46] Schneider Electric, “Schneider electric announces agreement to acquire cognite, unlocking a new level of strategic intelligence for industrial ai,”Financial Release, Jun. 2026. [Online]. Available:https://w.se.com/w/en/assets/pdf/ Schneider-Electric-announces-agreement-to-acquire-Cognite [47] J. Kreps, N. Narkhede, J. Rao et al., “Kafka: A distributed messaging system for log processing,” in Proceedings of the NetDB, vol. 11. Athens, Greece, 2011, p. 1–7. [48] P. P. Kore, M. J. Lohar, M. T. Surve, and S. Jadhav, “Api testing using postman tool,” International Journal for Research in Applied Science and Engineering Technology, vol. 10, no. 12, p. 841–843, 2022. [49] AnyLog, “AnyLog Edge Data Manager,” https://github.com/AnyLog-co/Remote-GUI, 2026, gitHub repository, accessed July 17, 2026. [50] M. Liu, S. Fang, H. Dong, and C. Xu, “Review of digital twin about concepts, tech- nologies, and industrial applications,” Journal of manufacturing systems, vol. 58, p. 346–361, 2021. [51] A. Fuller, Z. Fan, C. Day, and C. Barlow, “Digital twin: Enabling technologies, challenges and open research,” IEEE access, vol. 8, p. 108 952–108 971, 2020. 33 [52] M. Singh, E. Fuenmayor, E. P. Hinchy, Y. Qiao, N. Murray, and D. Devine, “Digital twin: Origin to future,” Applied System Innovation, vol. 4, no. 2, p. 36, 2021. [53] F. Tao, B. Xiao, Q. Qi, J. Cheng, and P. Ji, “Digital twin modeling,” Journal of Manu- facturing Systems, vol. 64, p. 372–389, 2022. [54] AnyLog, “AnyLog Deployment and Testing Scripts,” https://github.com/AnyLog-co/ deployment-scripts, 2026, gitHub repository, accessed July 15, 2026. [55] LF Edge, “Open Horizon,” https://lfedge.org/projects/open-horizon/, accessed: July 13, 2026. [56] IBM. Overview of ibm edge application manager. IBM Edge Application Manager documentation, version 4.5.x. [Online]. Available: https://w.ibm.com/docs/en/eam/ 4.5.x?topic=overview-ieam [57] Dell Technologies, “Dell Distributed Private Cloud (formerly Dell NativeEdge),” https:// w.dell.com/en-us/shop/storage-servers-and-networking-for-business/sf/nativeedge, accessed: July 13, 2026. [58] A. Tomlinson, “Introduction to the tpm,” in Smart Cards, Tokens, Security and Appli- cations. Springer, 2017, p. 173–191. [59] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust architecture,” NIST special publication, vol. 800, no. 207, p. 1–52, 2020. [60] MITRE. (2025) Valid accounts:Technique t0859. MITRE ATT&CK. [Online]. Available: https://attack.mitre.org/techniques/T0859/ [61] Gartner,“Gartneridentifiessixstepstomanageaiagent sprawl,”https://w.gartner.com/en/newsroom/press-releases/ 2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl, Apr. 2026. [62] Y. Elsayed and C. Jones, “Agentic explainability at scale: Between corporate fears and xai needs,” 2026. [63] Z. Zhou, X. Chen, E. Li, L. Zeng, K. Luo, and J. Zhang, “Edge intelligence: Paving the last mile of artificial intelligence with edge computing,” Proceedings of the IEEE, vol. 107, no. 8, p. 1738–1762, 2019. [64] D. Dolev, N. A. Lynch, S. S. Pinter, E. W. Stark, and W. E. Weihl, “Reaching approxi- mate agreement in the presence of faults,” Journal of the ACM (JACM), vol. 33, no. 3, p. 499–516, 1986. [65] L. Lamport, “The weak byzantine generals problem,” Journal of the ACM (JACM), vol. 30, no. 3, p. 668–676, 1983. [66] R. Shadmon and O. Arden, “Enhancing accuracy in approximate byzantine agreement with bayesian inference,” in 2025 55th Annual IEEE/IFIP International Conference on Dependable Systems and Networks-Supplemental Volume (DSN-S).IEEE, 2025, p. 191–195. 34 [67] R. Shadmon and O. Arden, “Brief Announcement: Proximal Byzantine Agreement: Improved Accuracy for Fault-Tolerant Replicated Datastreams,” in 39th International Symposium on Distributed Computing (DISC 2025), ser. Leibniz International Proceedings in Informatics (LIPIcs), D. R. Kowalski, Ed., vol. 356. Dagstuhl, Germany: Schloss Dagstuhl – Leibniz-Zentrum f ̈ur Informatik, 2025, p. 64:1–64:8. [Online]. Available: https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.DISC.2025.64 [68] S. S. Iyengar, R. R. Brooks et al., Distributed sensor networks. Chapman and Hall/CRC, 2004. [69] W. Elmenreich, “An introduction to sensor fusion,” Vienna University of Technology, Austria, vol. 502, no. 1-28, p. 37, 2002. [70] B. McMahan, E. Moore, D. Ramage, S. Hampson, and B. A. y Arcas, “Communication- efficient learning of deep networks from decentralized data,” in Artificial intelligence and statistics. Pmlr, 2017, p. 1273–1282. [71] L. Li, Y. Fan, M. Tse, and K.-Y. Lin, “A review of applications in federated learning,” Computers & Industrial Engineering, vol. 149, p. 106854, 2020. [72] M. Hao, H. Li, X. Luo, G. Xu, H. Yang, and S. Liu, “Efficient and privacy-enhanced federated learning for industrial artificial intelligence,” IEEE Transactions on Industrial Informatics, vol. 16, no. 10, p. 6532–6542, 2019. [73] R. Shadmon, “EdgeFL: Continuous federated learning across distributed edge nodes,” GitHub repository, 2026, accessed:July 14, 2026. [Online]. Available: https://github.com/royshadmon/EdgeFL [74] M. Satyanarayanan, “The emergence of edge computing,” computer, vol. 50, no. 1, p. 30–39, 2017. 35