no_std and allocation-free, the device becomes a first-class space in the same coordinate graph as everything else, and the association-edge and Portal machinery turns a device fleet into one addressable, capability-gated graph.CUBELinux addresses every byte by a coordinate — a 256-bit space selector (C) plus three spatial axes (Z, Y, X) — rather than by path, hostname, or inode. The coordinate primitive lives in the cube-core crate, which is no_std, allocation-free, and forbid(unsafe_code), and which already compiles for a bare-metal target (thumbv7em-none-eabihf, ARM Cortex-M without an operating system). That property was not incidental: the crate's own documentation treats the no_std boundary as the standing test of whether the layer could live where there is no OS at all.
This paper takes that boundary seriously and asks what happens when the thing on the other side is an ESP32. The ESP32 family is a widely deployed class of low-cost microcontroller with integrated Wi-Fi, a few hundred kilobytes of SRAM, and a few megabytes of flash — the class of part found inside smart plugs, thermostats, sensors, and industrial gateways. Espressif maintains first-class Rust support for the family, so the toolchain question is largely answered. The open question is architectural: what does it mean for a device to be addressed by coordinate, to hold its own configuration and telemetry at coordinates, and to be reachable from a host only through an explicit Portal?
The scope of this paper is architectural. We describe the device as a coordinate space, the two deployment tracks (client and node), the precise boundary between what ports to a microcontroller and what does not, the graph and Portal model applied to a fleet, and the agent monitoring and automation layer that sits on top. We close with an honest account of what is missing. The central thesis: CUBE does not merely add a faster way to store bytes on a device — it makes monitoring, memory, and control the same traversable graph.
In CUBELinux, movement along the spatial axes is arithmetic, but movement between spaces is not: a different space requires an explicit Portal. This distinction is exactly what a device fleet needs. Each ESP32 is assigned its own SpaceId — a 256-bit value — and is therefore not an address on a bus or an entry in a registry, but a coordinate system in its own right. The device's whole state space is c<SpaceId>/z…/y…/x….
Two consequences follow immediately. First, there is no collision between devices: two devices are two spaces, and their coordinates are not interleaved. Second, because SpaceId is 256 bits, a device space that was never disclosed cannot be guessed — the whitepaper's capability claim is structural, not a policy bolted on top.
Everything a device knows about itself is placed at a coordinate. Because CUBELinux stores metadata in reserved Null-space coordinates rather than in a side table, the record's header and the record's body are addressed by the same coordinate — there is no separate metadata store to drift out of sync. A device therefore does not need a parallel configuration format, a schema registry, or a documentation table. Its configuration, telemetry, and health are all coordinates.
| Device aspect | Representation | Kind |
|---|---|---|
| Capabilities, flags, firmware version | header at the device root coordinate | header |
| Configuration (Wi-Fi, sample rate, GPIO maps) | records in the device's config subtree | data |
| Telemetry and health (uptime, sensor values, faults) | records in the device's health subtree | data |
| "This device feeds that one" | an association edge in the reserved edge space | EDG |
| Host ↔ device reachability | a portal descriptor in the reserved portal space | portal |
The consequence is that "what is this device?" and "is this device healthy?" are not application-specific queries. They are reads at known coordinates, and the same reads work whether they are issued on the device itself or against the host's mirror of the device space.
A deployed system therefore has at least two spaces: the device's own space, and the host's coordinating space. These are separate cubes. Movement between them is a Portal, not an arithmetic step — which is the whitepaper's model applied literally. A host that can read a device's health subtree was given a portal to it; a host that was not, cannot construct the address.
There are two coherent ways to place CUBE on the device, and they differ in where the authoritative store lives.
The device keeps its configuration and state in Espressif's non-volatile storage (NVS) and speaks a coordinate-shaped request protocol to a host CUBE daemon over MQTT or TCP. A write is expressed as a coordinate write — write c<space>/z…/y…/x… — and a health check is a read at a coordinate. The device holds a local mirror so it keeps operating when the network drops; the host holds the coordinating store.
New machinery required. A transport (MQTT or a small TCP framing) and an NVS-backed record mirror on the device. The coordinate types, the record encoding, and the command vocabulary already exist on the host side.
Where the authority sits. On the host. The device is a well-behaved participant in the host's graph.
The device bakes the coordinate layer and the record codec into its firmware, adds an NVS or SD-backed Store implementation, and runs a listener that speaks the CUBE command protocol over TCP or BLE. A host, or a peer device, then writes and reads coordinates against the device directly, and the device is authoritative for its own space.
New machinery required. An embedded storage backend, and a listener replacing the host's Unix-domain socket transport. The coordinate types and the canonical record format are already written to be usable without an operating system.
Where the authority sits. On the device. This is the version in which a device is a genuine node rather than a peripheral.
| Track A — client | Track B — standalone node | |
|---|---|---|
| Device storage | NVS mirror | NVS / SD, canonical |
| Transport | MQTT or TCP to host daemon | TCP or BLE listener |
| New work | transport + NVS mirror | embedded Store + transport |
| Authority | host | device |
| Relative effort | low | substantial (days to weeks) |
| Offline operation | local mirror only | fully autonomous |
The portability boundary is not a matter of opinion; it is visible in the crates. Two of them were written for targets without an operating system. The rest assume a host.
cube-core — #![no_std], #![forbid(unsafe_code)], allocation-free. Defines SpaceId, Point, Coord, the Curve trait (Morton / RowMajor / Hilbert), and Portal. It already compiles for bare-metal ARM, and the corresponding riscv32 bare-metal targets are a configuration change rather than a rewrite.cube-store-raw — #![no_std] and allocation-free by default. Implements the canonical on-disk record format (magic, version, curve tag; then [SpaceId][Key][len][value] records) as zero-copy header parsing and record iteration. Its own documentation names the consumer: a kernel-mode driver that reads blocks without a heap. A flash-backed device store is the same shape of consumer.cube-store — standard-library based. It uses the host filesystem, a write-ahead log with group-commit fsync, a JSON snapshot, and atomic rename. A microcontroller has no host filesystem and no fsync, and its flash has a finite erase-cycle budget that a fsync-per-burst log would spend quickly.cube-index — the derived adjacency and portal indices. They are rebuilt in memory and kept current as edges mutate. That is correct on a host; it is not a fleet-sized structure for a few hundred kilobytes of SRAM.cube-daemon / cubesys — a Unix-domain socket server managed by systemd. Unix sockets and service managers are host concepts. The command protocol itself is transport-agnostic and portable; the socket type is not.cubefs — a FUSE front-end. Linux-only.| Crate / layer | std? | Ports to ESP32 | Replacement or note |
|---|---|---|---|
cube-core | no_std | yes | as-is; retarget the build |
cube-store-raw | no_std | yes | as-is; parse/iterate over a flash block |
cube-store | std | no | needs an NVS / SD-backed Store |
cube-index | std | host only | device keeps only its own slice, or scans |
cube-daemon | std + Unix socket | no | TCP or BLE listener speaking the protocol |
cubefs | std + FUSE | no | Linux only; not applicable |
cube-agent | std | host only | runs where the model and the index run |
CUBELinux does not keep relationships in a side table. An association is a first-class record — Edge { from, to, kind, weight } — stored at its own coordinate inside a reserved edge space. A device therefore does not merely hold values; it holds the edges that describe what it feeds, what feeds it, and what it is part of. Because edges are records, they can carry their own header metadata, and they cannot silently diverge from the data they describe.
Read-optimised traversal is provided by an adjacency index that answers "outgoing edges of this node" and "incoming edges of this node" in time proportional to that node's degree, with a follow operation that walks from a node to a target. The index is derived — rebuilt from the store and updated on mutation — so it can never become a second source of truth.
A Portal is a directed edge from one coordinate to another, possibly crossing a space boundary. Its semantics are deliberately strict:
A portal is traversed only by standing exactly on its mouth. Traversal is not something that can be done from a distance. The reverse of a portal is a distinct edge and must be created explicitly to be usable.
Applied to a fleet, this is the authority model. A device is reachable from another space only where a portal exists. A monitoring agent that has been handed a portal to a device's health subtree can read that subtree and nothing else — not because a policy table said so, but because it does not possess the 256-bit selector for the rest. Portals are themselves data, stored in a reserved portal space and keyed by their source space, so every portal leaving a given space can be enumerated with a single prefix scan. That is a discovery primitive: one can ask what a device is wired to without reading the device.
Because a device's relationships are edges and its state is coordinate-addressable, a health check is not a list of endpoint calls. It is a walk. Starting from a coordinate — a production line, a room, a subsystem — one follows outgoing edges to every device it comprises, reads each device's health coordinate, and follows incoming edges to establish what is upstream when something has faulted. The same walk answers "what does this affect?" and "what feeds this?", in either direction, in time proportional to the local degree. In a conventional installation that question is answered by joining a device registry, a topology table, and a historian, and the join is only as correct as the last synchronisation.
The whitepaper's retrieval model for memory is association-based: each memory is a record, and recall means traversing edges from one memory to a linked memory, at constant cost per hop and independently of the curve chosen. This is described in the whitepaper as the single highest-leverage idea in the design, because it turns memory from a scan problem into a graph-walk problem.
The consequence for an edge deployment is the reason this paper exists. The agent's memory is a graph walk. The installation's topology is a graph walk. They are the same operation over the same structure. An agent that has been asked "why did line 3 stop?" walks edges the same way it recalls a prior incident — and the walk that answers the operational question is the walk that retrieves the relevant history.
A monitoring agent on this substrate does four things, all through one interface:
Observation, memory, and control are therefore not three subsystems. They are reads, walks, and writes against one coordinate graph.
A line is modelled as a space, its machines as coordinates within it, and its material flow as edges. A fault triggers a walk: incoming edges identify upstream contributors, outgoing edges identify downstream exposure. A maintenance agent is handed portals to the assets it is responsible for and to nothing else, so its reach is exactly its remit. Because state and relationships share one structure, the agent's recollection of how a similar fault resolved is retrieved by the same traversal that located the fault — the diagnostic path and the memory path coincide.
A home is a space; rooms, devices, and sensors are coordinates; "this camera watches that door" and "this plug powers that lamp" are edges. An automation such as "when the door opens and the house is empty, raise the lights" is a walk from the door to what observes it and what should respond, rather than a rule whose trigger conditions are maintained separately from the topology. The distinguishing property is the same as in the factory: the assistant's memory of the house and the house's own state are addressed identically, so they cannot disagree about what is connected to what.
The capability model described in §5.2 is by construction only. No access-control logic exists in the coordinate, header, index, or store layers; the authorisation code that exists in the project lives in the host daemon and agent, and governs command and file access on the host. A portal gate — refusing a cross-space operation unless the caller holds the portal — is the missing keystone, and it must be built before any claim about a unified authority model is honest.
Neither track exists. There is no NVS-backed store, no MQTT or BLE transport, and no device-space provisioning. The coordinate layer and the record codec are written to permit these; they are not implemented.
The adjacency and portal indices are derived, in-memory structures. On a host this is unproblematic. On a device with a few hundred kilobytes of SRAM, only the device's own slice is affordable; a whole-fleet index on an MCU is not. The practical consequence is that the fleet-wide graph belongs on the host, with devices as its leaf spaces — which is precisely the split that Track A assumes.
The host store achieves durability through a write-ahead log, group-commit fsync, and checkpointing to a snapshot. None of these primitives exist on a microcontroller, and flash erase cycles are finite. A device-backed store must instead map records onto a wear-levelled medium — non-volatile storage on the device, or a block device where one is present — and the crash-recovery guarantee must be re-established for that medium rather than assumed from the host design.
The project's AI/ML crates are explicitly deferred; the reasoning loop that exists is the agent implementing a ReAct-style tool loop against a local model on a host. On-device inference is a separate, unresolved question, and this paper does not assume it. The device is a space in the graph; the reasoning happens where the model and the index can run.
The most common misreading of this proposal is that CUBE "installs" on an ESP32 as it would on a host. It does not. A microcontroller has no operating system unless one is supplied, no host filesystem, no process model, no Unix sockets, and no FUSE. What crosses to the device is the coordinate model and the record encoding. Everything above that boundary is replaced by device-appropriate machinery. The proposal is a port of an addressing model, not a deployment of a host stack.
The coordinate layer of CUBELinux was written without an operating system in mind, and that decision is what makes an edge deployment coherent. A device can be a space; its configuration, telemetry, and health can be coordinates; its relationships can be first-class edges; and reachability to it can be an explicit portal rather than an address that anything may construct.
Two tracks follow from this. As a client, a device is a well-behaved participant in a host's graph, and the new work is a transport and a non-volatile mirror. As a standalone node, a device is authoritative for its own space, and the new work is an embedded store and a listener in place of the host's socket. In both cases the coordinate types and the canonical record format are reused rather than rewritten.
The strongest argument for the approach is not storage speed. It is that state, relationships, reachability, and agent memory become one addressable structure, so that monitoring and recall are the same traversal and control is a write at a coordinate. That unification is the substance of the proposal; performance is a secondary consideration and, in the measurements available, was never the limiting factor.
Two pieces stand between this proposal and a system: the device-side integration, and the portal gate that converts capability-by-construction into capability-by-enforcement. The second is the more important, because it is what makes a scoped agent — one that can read a pump's health and cannot touch a controller — a guarantee rather than an intention.
Future work: the portal gate; an NVS and SD-backed Store; a retarget of cube-core and cube-store-raw to a microcontroller target; a device-space provisioning path; and a fleet demonstration in which the whole installation is one adjacency index on a host and each device is one space within it.