WEAVE: Workload Execution and Autonomous Verification Engine

1.1 · Motivation

The orchestration of autonomous multi-agent systems for physical construction in unstructured, remote, or extreme environments—such as space pre-assembly, planetary habitat setup, and disaster-relief operations—presents a fundamental tension between global task coherence and localized resource constraints. In such environments, traditional coordination systems are bottlenecked by the realities of the physical site, including high-latency communication, frequent network partitions, and unpredictable agent attrition.

1.2 · The bandwidth bottleneck

Traditional state-of-the-art multi-robot task allocation (MRTA) and collaborative assembly frameworks rely on continuous, high-overhead state synchronization. Robots must exchange large 3D spatial representations, dense occupancy grids, or complex pose-graphs to maintain a unified worldview. As the swarm population N and structural complexity M scale, the network bandwidth required to broadcast these global structures grows quadratically, rapidly saturating ad-hoc wireless channels. Furthermore, parallel task execution under these paradigms introduces severe synchronization contention; when multiple robots attempt to manipulate the same object or occupy the same workspace coordinate, resolving the conflict requires centralized arbiters or synchronous, multi-round auction protocols that stall execution.

1.3 · The WEAVE approach

To resolve these limitations, we present WEAVE: a novel system architecture that transposes the enterprise software design principles of Event Sourcing (ES) and Command Query Responsibility Segregation (CQRS) to physical, spatial 3D robotic assembly. The LEGOSwarm research project operates on WEAVE, proving that individual robots do not directly mutate or synchronize global project states. Instead, the absolute source of truth is maintained as an immutable, append-only ledger of discrete transition events (the write model). Each autonomous robot in the swarm maintains a local copy of this event stream, which it processes asynchronously to reconstruct and update a local projection of the global Assembly Graph (the read model). In this framework, the physical progress of the construction site is modeled as a continuous feedback loop designed to systematically minimize the spatial and structural error vector e(t) over time:

where the swarm’s collective actuator actions serve as a distributed regulator trying to drive e(t) → 0.

Contributions

This architecture introduces four primary contributions to the field of swarm robotics:

2.1 · Multi-Agent Task Allocation (MRTA) in Robotic Construction

Distributed assembly requires partitioning a complex structural plan into distinct tasks and assigning them to available agents. Traditional state-of-the-art frameworks, such as SwarmBuild, utilize market-based or auction-based assignment protocols (e.g., Sequential Single Item (SSI) or Ordered Single Item (OSI) bidding) to dynamically allocate tasks based on distance and capability.

While these protocols effectively optimize task distribution in fully connected networks, they suffer from high latency and severe performance degradation under intermittent connectivity. Each auction round requires multiple consensus steps across the network; if a communication partition occurs during a bidding window, the allocation stalls.

Additionally, parallel task claiming in decentralized environments typically relies on lock-based synchronization. If N agents compete for L task locks, the network contention scales as O(N×L), introducing severe synchronization overhead. Under LEGOSwarm, we bypass auction phases entirely by using a lock-free, lease-based reservation protocol modeled on Conflict-Free Replicated Data Types (CRDTs), achieving strong eventual consistency (SEC) without centralized arbitration.

2.2 · Distributed Memory and Consensus in Robotic Swarms

Operating in GPS-denied or communication-degraded environments requires swarms to function as self-contained infrastructures. Prior works, such as SwarmMesh, have investigated the realization of shared global memories across mobile robot swarms to store topography and belief maps. These systems formulate distributed storage as a heterogeneous bin-packing optimization problem, routing data chunks across mobile nodes.

Similarly, the Risk-Aware Swarm Storage (RASS) protocol utilizes potential-based percolation algorithms to route critical metadata away from high-risk spatial peripheries toward more reliable interior base stations.

While these storage protocols efficiently manage partitioned file chunks, they are not designed to maintain transactional, consistent state machines for spatial assembly. Conversely, protocols like SwarmDAG address network partitioning by spawning localized ledger forks using virtual synchrony, which are later reconciled via gossip-based merge steps.

LEGOSwarm builds upon this concept of decentralized consensus by utilizing a structured event-stream ledger, ensuring that even if a network partition occurs, parallel teams can proceed with independent physical construction blocks and safely reconcile their state histories upon reconnection.

2.3 · Event-Driven Architectures and GitOps in Multi-Agent Systems

The application of event-driven and declarative control loops has recently emerged as a paradigm for managing complex software systems. In industrial automation, the Line Information System Architecture (LISA)—often referred to as the “Tweeting Factory”—replaces centralized orchestration with decentralized choreography, where thousands of heterogeneous devices (PLCs, sensors, and assembly robots) independently observe and react to a stream of immutable published events.

In the domain of virtual multi-agent systems, Event Sourcing for Autonomous Agents (ESAA) and runtimes like ActiveGraph demonstrate that an agent’s state can be managed by treating an append-only transaction log (activity.jsonl) as the absolute source of truth, from which the current state of a workspace is deterministically projected (roadmap.json). This is closely paired with the GitOps pattern—popularized by Kubernetes operators—where controllers continuously monitor actual system states, compare them against declared desired configurations, and run idempotent reconciliation loops to align the two.

The primary novelty of LEGOSwarm is the translation of these software-engineering concepts—specifically event-sourced state projection, transactional boundaries, and GitOps-style reconciliation—into the physical, three-dimensional spatial coordinates of a robotic construction site.

3.1 · The Assembly Graph as a Directed Acyclic Graph (DAG)

The complete structural objective is formalized as a Directed Acyclic Graph, expressed mathematically as G = (V, E), where:

V (Vertices/Nodes): Represent discrete, atomic physical assembly operations (e.g., structural placement, material manipulation, or spatial inspection).

E (Edges): Define strict unidirectional topological and physical dependencies between nodes (e.g., structural support, logical precedence, or verification gating).

The Assembly Graph represents the absolute historical and structural “truth” of the build. It contains the exact geometric, materials, and constraint parameters required to realize the physical structure.

3.2 · The Append-Only Event Log

While the graph defines the desired target state, the physical progression of the swarm is captured entirely within an immutable, append-only Event Log. Every state change, node transition, resource allocation, and quality control check is captured as a discrete event.

Rather than synchronizing full graph instances across a noisy or latent network, workers exchange compressed, sequential event logs. Every agent within the swarm independently processes this event stream to reconstruct an identical localized “materialized view” of the global assembly state. This approach ensures strong eventual consistency without requiring a master node or a locking distributed consensus mechanism.

3.3 · Topological Data Flow

The system operates through three primary interfaces:

Top-Down Intent (Patches): The high-level coordinator (Foreman) interacts with the system exclusively by issuing Graph Patches. These patches represent small, delta-encoded structural changes (adding, modifying, or invalidating nodes) compiled against a specific base revision ID.

Horizontal Synchronization (Beacons): Individual workers broadcast lightweight, cryptographic worker beacons to their immediate physical neighbors. These beacons do not contain internal task logic; they only broadcast the worker’s current graph revision index and a short history of recent unique event IDs.

State Reconstruction: When an agent receives a beacon indicating a discrepancy in graph revisions or event history, it requests only the missing delta-log segments from its peers. Once the local log is updated, the agent evaluates its local DAG to determine its next valid physical action.

4.1 · Node Schema Definition

Every vertex within the Mission Graph is an explicit, version-controlled declaration of a physical task. The primary structural novelty of the node schema is the absolute decoupling of operational intent from its physical execution state.

Node:
  id: "N421"
  type: "ASSEMBLY_OPERATION"
  desired_state:
    brick_type: "3001"
    color: "RED"
    pose:
      x: 120
      y: 40
      z: 18
      rotation: 90
  current_state:
    status: "COMPLETE"
  revision: 13
  priority: "NORMAL"
  verification_required: true
  notes:
    structural_class: "PRIMARY"
    comments:
      - "Structural wall section"
  created_by: "FOREMAN"
  timestamp: 882234

Desired_state vs current_state allocation: The core objective function of an active worker agent is to reduce the delta between these two objects. By isolating the target hardware/geometry profile from the live execution telemetry (PENDING, RESERVED, COMPLETE, FAILED), the graph remains a pure declaration of intent, while execution remains fluid and reactive.

Version and origin tracking: The revision keys allow workers to instantly identify if they are evaluating stale architectural metadata, preventing conflicting build actions if a patch is concurrently propagating through the network.

4.2 · Edge Schema & Dependency Types

Edges represent directional constraints between individual nodes. Rather than defining a simple sequence, edges enforce structural, spatial, and logistical realities.

Edge:
  source: "N421"
  target: "N422"
  relationship: "PRECEDES"

The architecture natively evaluates five explicit relational typologies:

PRECEDES: A strict logical block. Node B cannot enter an active queue until Node A’s current_state.status resolves to COMPLETE.

SUPPORTS: A physical structural dependency. Implies load-bearing relationships (e.g., lower wall section supporting a roof layer). If a supporting node is structurally invalidated during execution, all child nodes inheriting this edge are immediately safety-gated.

VERIFIES: A quality control link. Maps an inspection task directly to an assembly task.

TRANSPORTS_TO: A logistical routing constraint mapping material flow to spatial staging locations.

DEPENDS_ON: General system or material availability gating.

By combining these explicit edge relationships, the swarm can dynamically compute its own valid parallel processing paths without needing constant centralized control or a master scheduler.

5.1 · Delta-Encoded Graph Revisions

Instead of treating a design change as a completely new structural graph, mutations are isolated as transaction objects called Revisions. A revision explicitly targets a specific structural node or set of nodes, defining a state mutation compiled against a known historical base.

Revision:
  revision_id: "R1837"
  author: "FOREMAN"
  target_node: "N421"
  operation: "MODIFY"
  changes:
    color:
      old: "WHITE"
      new: "RED"
  timestamp: 882500

By decoupling the change into a discrete delta package, the system ensures that workers do not need to pause operations to clear their entire memory buffer. Agents simply apply the delta directly to their localized, in-memory Directed Acyclic Graph (DAG). This approach protects the unchanged segments of the dependency tree, keeping ongoing, unaffected assembly tasks running smoothly across the swarm.

5.2 · The Graph Patch Schema

When a human operator or high-level design intelligence (the Foreman) alters the construction blueprint, the update is broadcast through the network via a Graph Patch. The patch serves as a lightweight wrapper that bundles multiple atomic topological mutations together.

Patch:
  patch_id: "P1837"
  base_revision: 12
  target_revision: 13
  operations:
    - modify_node:
        node: "N421"
        color: "RED"
    - add_node:
        node: "N850"
    - remove_node:
        node: "N123"

5.3 · Network Propagation and Convergence

When a Graph Patch is injected into the network, it propagates asynchronously across the swarm. Because network packets are highly compressed—containing only the specific array of operations rather than geometric coordinates for the entire structure—transmission times drop significantly.

If an agent receives a patch whose base_revision is higher than its current local revision index, it recognizes a state gap. The agent then queries its immediate physical neighbors for the missing historical events, stepping through them sequentially until its local DAG matches the updated global revision. This approach keeps the network light while ensuring the entire swarm eventually converges on the same plan.

6.1 · The Swarm “Pheromones”

In biological swarms, ants or bees coordinate complex tasks by depositing chemical trails (pheromones) in their physical environment. In the WEAVE architecture, the event stream serves as a digital equivalent.

Instead of routing messages to a central server, an agent that completes a task, runs out of material, or encounters a physical blockage immediately generates an event object and appends it to its local log. This event is then pushed out to any peer agents within direct radio or optical line-of-sight.

Event:
  event_id: "E882901"
  node_id: "N421"
  actor: "Robot17"
  event_type: "NODE_COMPLETE"
  timestamp: 882901

The system natively relies on a standardized dictionary of primitive event typologies to coordinate work:

NODE_CREATED: Informs neighboring agents that a new operational dependency has been added to the local task stack.

NODE_RESERVED: Signals that an agent has claimed a specific operation, shifting its state and gating other workers.

NODE_COMPLETE: Signals the successful physical execution of a node’s desired_state, allowing downstream dependencies to clear.

NODE_FAILED / NODE_INVALIDATED: Alerts nearby agents of a structural or mechanical failure, triggering local rollback or safety logic.

RESOURCE_SHORTAGE: Broadcasts logistics updates regarding local material scarcity.

6.2 · The Decentralized Reservation Table

To prevent multiple robots from attempting to pick up the same physical component or build on the exact same coordinate space simultaneously, the architecture implements a decentralized Reservation Table.

When an agent identifies an open node in its local DAG (where all PRECEDES or SUPPORTS parent edges are marked COMPLETE), it transmits a NODE_RESERVED event containing a strict expiration timestamp.

Reservation:
  node_id: "N421"
  reserved_by: "Robot17"
  expiration: 883000

Upon hearing this event, all neighboring peers update their local materialized views of the reservation table. They will bypass node N421 in their own task selection loops until the reservation is cleared by a NODE_COMPLETE event, or until the system clock passes the expiration timestamp.

If Robot17 experiences a critical hardware failure, loses power, or drops communication mid-task, it does not stall the swarm. The reservation naturally expires, the node’s status reverts to available, and another active worker seamlessly takes its place. This approach ensures robust fault tolerance without requiring master-node oversight or distributed database locks.

7.1 · The Build-Verify-Continue Pipeline

The architecture enforces a strict Build → Verify → Continue workflow loop. An assembly node does not simply mark itself complete and immediately unlock downstream tasks. Instead, the completion of an assembly task triggers the activation of a linked verification task.

When a worker (e.g., Robot17) completes a brick placement for node N421, it appends a NODE_COMPLETE event to the log. However, any downstream node connected via a VERIFIES or SUPPORTS edge remains gated. The system requires an explicit verification pass before those structural dependencies resolve.

7.2 · Verification Schema & Cross-Checking

Verification tasks are typically picked up by different physical agents than the one that performed the build. For example, a specialized inspection robot equipped with high-accuracy spatial sensors (like depth cameras or laser scanners) will claim the verification node.

Verification:
  node_id: "N421"
  verified_by: "Robot22"
  result: "PASS"
  confidence: 0.97

result (PASS / FAIL): If the agent records a PASS, the event is logged, the dependency clears, and the next assembly layer becomes available for reservation. If it records a FAIL, a conflict event is generated, immediately freezing downstream operations in that localized sector.

confidence metric: This value (ranging from 0.0 to 1.0) represents the inspector’s sensor certainty. If a pass occurs with low confidence (e.g., 0.72), neighboring agents can flag the node for a secondary inspection run by a third agent, establishing a decentralized consensus on physical quality control.

7.3 · Closed-Loop Error Handling

When a verification fails, the architecture prevents a cascading failure through localized isolation. The failing verification event instantly updates the node’s current_state.status to FAILED or INVALIDATED.

Because nearby workers reconstruct their local task queues by constantly reading the event stream, they instantly see the failure. Any agent currently holding a reservation for a downstream node (like a roof placement matching a failed wall section) will automatically drop its reservation. The swarm then dynamically generates a new corrective assembly node or rolls back the local state until the physical defect is corrected.

8.1 · Resource Tracking Schema

Materials are treated as finite, distributed global pools. Rather than a central inventory database, the status of physical assets is recorded as structured objects that can be queried and modified via the standard event log.

Resource:
  id: "Brick3001_Red"
  available: 42
  reserved: 3
  shortage: false

Available vs reserved: This allocation mirrors the separation of concerns found in the node schema. When an agent reserves a task, it concurrently claims the required components. The items move from available to reserved status instantly, preventing two agents from planning to utilize the same physical raw materials.

Shortage flag: When localized stock counts drop below a critical threshold calculated against pending downstream nodes, the system flags a shortage.

8.2 · Graph-Level Resource Gating

Nodes declare their material requirements explicitly within their schema using a RequiredResources array. This creates a hard constraint that must be resolved before the node can transition into an executable state.

RequiredResources:
  - "Brick3001_Red"

When an active agent evaluates the local Directed Acyclic Graph (DAG) for its next task, it checks both topological dependencies (parent edges resolved to COMPLETE) and material dependencies. If a node is topologically unlocked but the matching Resource.available count is zero, the agent cannot reserve the node.

Instead, the agent remains idle or automatically shifts its operational mode to logistics—seeking out material caches to replenish the local workspace.

8.3 · Decentralized Logistics and Pheromone-Driven Supply Chains

When a resource shortage is flagged, the matching RESOURCE_SHORTAGE event acts as a high-priority digital pheromone. This event propagates across the network, signaling to free agents or specialized transport units that a specific sector requires material injection.

Because the system manages resource states via the event log, agents do not need a central controller to tell them where to deliver materials. They inspect the pending RequiredResources across the unfulfilled segments of the graph, cross-reference them with localized RESOURCE_SHORTAGE events, and autonomously route supplies directly to the sectors experiencing the highest operational friction. This mechanism balances the supply chain across the construction site completely from the bottom up.

9.1 · Machine-Readable Intent

In traditional version control or task management systems, “comments” or “notes” are unstructured strings meant solely for human eyes. In this architecture, notes are highly structured, strictly typed metadata objects that directly influence worker behavior and local task compilation.

Notes:
  structural_class: "PRIMARY"
  inspection_required: true
  preferred_substitution:
    - "Brick3001_Blue"
  comments:
    - "Exterior wall facing high wind loads"

Dynamic behavior gating: If a node’s notes declare a structural_class: PRIMARY, an agent’s local task allocator automatically escalates its priority and forces a higher confidence threshold on the subsequent verification task.

Fallback logic: The preferred_substitution array provides immediate, localized flexibility. If a worker encounters a RESOURCE_SHORTAGE event for Brick3001_Red while attempting to execute node N421, it does not need to message a human supervisor or stall. The local agent reads the structured note, verifies the availability of Brick3001_Blue, and autonomously updates its execution parameters within the bounds of pre-approved human design intent.

9.2 · The Oversight Interface

Because human intent is baked directly into the node as a first-class object, the Foreman can seamlessly modify execution rules on the fly without changing the underlying geometric or structural data.

For instance, if weather conditions deteriorate on-site, a human supervisor can push a graph patch updating a section of nodes to inspection_required: true. As this patch ripples through the swarm, workers immediately adjust their local state machines, routing additional inspection agents to that sector and altering the physical assembly pipeline in real time. This approach ensures that human expertise remains an active, integrated component of the swarm’s collective memory.

10.1 · The Minimalist Beacon Schema

A worker beacon is designed to act like a brief heartbeat. It contains just enough data for neighboring agents to spot discrepancies in their local state models and trigger a targeted update if something is missing.

Beacon:
  sender: "Robot17"
  graph_revision: 13
  recent_events:
    - "E882901"
    - "E882902"
    - "E882903"
  optional_telemetry:
    need: "Brick3001_Red"
    waiting_on: "N418"
    confidence: 0.91

By keeping the core beacon limited to the sender ID, the current graph_revision index, and an array of recent unique event hashes, the system keeps the data footprint tiny. Optional telemetry fields provide a way for agents to signal immediate local needs or physical stall points without cluttering the global event log.

10.2 · Anti-Entropy State Reconciliation

When an agent hears a neighbor’s beacon, it compares the incoming data with its local memory using a simple check:

Revision matching: If the beacon’s graph_revision matches the local index, the agent moves on to check the events. If the incoming revision is newer, the agent realizes its structural graph is out of date and requests the missing graph patches directly from that neighbor.

Event log reconciliation: The agent looks at the recent_events array. If it spots an event ID it hasn’t processed yet, it pulls just that specific log segment from the broadcasting peer.

Because the system relies on an append-only log structure, catching up is easy. Agents don’t need to negotiate complex state changes; they simply pull the missing historical events and run them sequentially to update their local model.

10.3 · Reconstructing the Materialized View

Every worker independently builds its own Materialized View of the project from the exact same underlying event stream. The agent takes the base blueprint (the Mission Graph), applies any incoming graph patches, and plays back the event log to figure out exactly what is happening across the site right now.

This approach removes the need to store or transmit a massive global state database. Everything an agent needs to know to make its next decision—which tasks are open, who has reserved what, and where materials are running low—is reconstructed on the fly from the event log.

11.1 · The Graph as Collective Memory

The ultimate realization of the WEAVE framework shifts the concept of a robotic swarm from a collection of coordinated individuals to a singular, distributed organism. In this model, the Assembly Graph functions as the organism’s DNA—an immutable blueprint of what it must become. The append-only Event Log serves as its nervous system, propagating impulses and state mutations across the collective.

Because every agent independently reconstructs the global state from the same underlying event stream, the swarm develops a “collective memory.” No single robot holds the master plan, yet every robot knows exactly where the project stands. If half the swarm is instantly destroyed or disconnected, the remaining agents do not stall or lose orientation; they read the last known state of the log, evaluate open dependencies in the DAG, and continue construction without interruption.

11.2 · Future Applications: Beyond Terrestrial Construction

While this paper focuses on structural brick assembly, the underlying data topology is inherently generic. Any physical or digital process that can be modeled as a series of dependent state reductions can leverage this architecture.

Planetary colonization: In high-latency, high-radiation environments like Mars or the Moon, central servers are single points of failure. LEGOSwarm allows autonomous machinery to harvest resources, prepare landing pads, and assemble habitats entirely from the bottom up before human arrival.

Disaster recovery: Autonomous drone swarms deployed to unstable environments (e.g., collapsed infrastructure) can map paths, clear debris, and drop supplies safely by logging localized topological patches as pathways open or close.

De-orbiting and space logistics: Satellites operating in orbital swarms can coordinate the capture and recycling of space debris, managing shared fueling and transport resources without risking communication blackouts with ground control.

11.3 · Conclusion

The WEAVE framework proves that complex, highly precise physical construction does not require complex or centralized coordination. By decoupling structural intent (the Graph) from historical execution (the Event Log), and enforcing a strict Build-Verify-Continue pipeline, the system achieves fault tolerance, structural reliability, and network efficiency. As robotics continue to move from structured factory floors to unpredictable, real-world environments, event-driven, graph-based data structures will provide the foundation for true collective autonomy.