System design

Architecture

Four control layers, one coordination protocol, and a deployment path built to run on regulated government infrastructure without a rewrite.

Who actually controls the fleet

Autonomy without a human path is a liability, and a human-only path does not scale past a handful of machines. Swarmonic separates the two so neither blocks the other.

LAYER 1

Runtime

Speaks to every device. Owns discovery, driver resolution, the coordination protocol, temporal synchronisation, collision avoidance, and the attestation chain. This is the layer that would run on the robot itself in production, so a fleet keeps coordinating through a network outage.

LAYER 2

AI controller

Turns an intended outcome into coordinated device commands. Decomposes goals into tasks, matches tasks to genuinely capable machines, propagates kinematic constraints, and evaluates the fleet-wide consequences of a command before anything moves.

LAYER 3

Human interface

Where an operator states what they want and sees what the fleet is doing. Deliberately thin: the AI controller does the work, and the operator supervises rather than pilots. A direct programmatic path stays open for developers who want to command devices themselves.

LAYER 4

Emergency override

Independent of the layers above and intentionally not clever. Halts devices through the protocol's own cascade regardless of what the AI controller believes is correct. Nothing can talk it out of stopping.

Where this runs

The platform is deliberately infrastructure-neutral: containerised, configured entirely through environment variables, with the message bus behind an interface and no dependency on any hosting provider's proprietary database, authentication, or storage service. That is a design constraint, not an accident — it is what keeps the production migration a deployment change rather than a rebuild.

Current — demonstration

Managed container host

Public demo, simulated fleet, no physical hardware
  • Runs the full orchestration engine against a simulated 22-device fleet
  • Sufficient for evaluation, technical due diligence and licensing review
  • Single region, in-process state, no persistence requirement
  • Intentionally minimal — this environment exists to be read, not to carry load
Why the distinction is stated plainly. Industrial and defense fleet operation has requirements that a general-purpose application host does not meet: a managed MQTT broker at fleet scale, an edge runtime executing on the device itself, and formal compliance authorisation. Those requirements are architectural, so they are designed for from the start rather than discovered later. The demonstration environment and the production target are different by intent — the codebase is identical across both.

Portability constraints

Five rules the codebase holds to. Together they keep the production migration to roughly a day of work instead of a rewrite under deadline pressure.

01

Containerised

Plain Docker, standard base image, no provider-specific build system.

02

Environment configuration

Every setting arrives as an environment variable. Nothing is hard-coded to a host.

03

Standard datastore

Postgres over an ordinary connection string. No proprietary managed database.

04

Bus behind an interface

Message transport is abstracted, so swapping to AWS IoT Core is a configuration change.

05

No host-native services

No provider-specific auth, object storage, or key-value store anywhere in the codebase.

RESULT

One image, any target

The same container runs on a managed host, on ECS, on EKS, or inside GovCloud.