Architecture
Four control layers and one coordination protocol, for an SI-operable robot fleet. One Mind SI may operate that fleet. One Mind SI does not own the robots or the license. The deployment path targets regulated environments.
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.
Runtime
Speaks to every device in the simulated fleet. Owns discovery, driver resolution, the coordination protocol, temporal synchronisation, collision avoidance, and the attestation chain. This is the layer intended to run on the robot itself so a fleet could keep coordinating through a network outage. The public demo runs it in one process. An on-robot deploy is the production target, not this release.
SI controller
On the mission interface, turns an intended outcome into coordinated device commands: decomposes goals into tasks, matches them to devices that declare the required capabilities, and can refuse at the first failing staged check — geofence, separation, kinematic profile, cascade — after a task is allocated. The public demo's coordination scenarios do not call that check. They go through orchestration and the authority gate.
Human interface
Where an operator states what they want and sees what the fleet is doing. The mission interface decomposes an instruction; the public demo also lets a visitor select a coordination scenario on the simulated fleet. A direct programmatic path stays open for developers who want to command devices themselves.
Emergency override
Independent of the layers above and intentionally not clever. Halts devices through the protocol's own cascade regardless of what the SI controller believes is correct. Nothing can talk it out of stopping.
How a command reaches a robot
One path, five stops. The authority gate is the robot's own, not the platform's: the platform earns the right to command through the same gate as anyone else.
Conceptual relationships as implemented in the runtime and exercised against a simulated fleet. This diagram does not establish physical robot compatibility.
Where this runs
The platform is deliberately infrastructure-neutral: containerised, with the host-specific settings read from environment variables, an in-process message bus, and no dependency on any hosting provider's proprietary database, authentication, or storage service. Moving hosts is not a second product. It is also not a configuration switch onto AWS IoT — that broker is a production target, named below, and it is not in this tree.
Managed container host
- Runs the orchestration engine against a simulated fleet: 22 devices across ten profiled manufacturers, plus three zero-config devices with no vendor profile and no hand-written driver
- Sufficient for evaluation, technical due diligence and licensing review
- Single region. Simulated fleet state stays in memory. Robot-authority records are written under
SWARMONIC_AUTHORITY_DIRwhen that variable is set — the container image and the Replit config set it - Intentionally minimal — this environment exists to be read, not to carry load
AWS, with a GovCloud path
- AWS IoT Core as the managed MQTT broker — per-device X.509 certificates, device shadow state
- AWS IoT Greengrass running the Swarmonic runtime at the edge, on the robot, so coordination survives connectivity loss
- ECS/EKS for the orchestration tier, multi-region for command latency
- AWS GovCloud (US) for FedRAMP High, ITAR, EAR and DoD SRG Impact Levels 2/4/5 workloads
Portability constraints
Five rules the codebase holds to, so a later host change does not start from a second codebase.
Containerised
Plain Docker, standard base image, no provider-specific build system.
Environment configuration
Port, project label, operator token, and the authority-store directory arrive as environment variables.
No proprietary database
No managed database in this tree. Fleet state is in-process. Robot-authority records use a directory when SWARMONIC_AUTHORITY_DIR is set.
In-process bus
Coordination goes through the in-process SCP bus. AWS IoT Core is a production target, not a setting in this tree.
No host-native services
No provider SDK for auth, object storage, or a hosted key-value store in this repository.
One plain image
A plain Python image. A managed host can run it. ECS, EKS, and GovCloud are named targets; this repository does not exercise them.
Where money moves — not a fifth control layer
Commerce sits beside this stack, not inside it. Licenses and seats are sold on Vermarco (Vertical Marketplace LLC — a related company with the same founder). It witnesses sales; it does not dispatch robots. A Vermarco purchase receipt records the sale. After the signature verifies, fulfillment issues a sim-fleet operator token. The token is checked on demo emergency-stop and resume only. It is not an issuer at the robot gate and it does not become a driver. Emergency stop is Layer 4 and local; it never routes through a marketplace or a payment rail.
Layer 3 is the human interface. A Head SI (super intelligence) — One Mind SI — may occupy it as operator of this SI-operable robot fleet. That is one mind coordinating many manufacturers' machines. Legal ownership of robots and of the license remains with the human or company that bought them. The superintelligence does not own them.