CUBELINUX · Whitepapers
Seven drafts — the newest is PowerButton.io's integration report, 2026-10-01: a standalone CUBE store in production, written by an agent that runs on it. Pick one to read in full — each is a standalone HTML page.
About these drafts. The whitepaper documents the design, verified on-disk state, and completed kernel build of the CUBELinux coordinate-addressed OS. The addendum is a separate, clearly-labeled preliminary exploration of how state-spanning neural networks might one day layer on top of the CZYX filesystem — nothing in it is built or committed. The ESP32 integration proposal is likewise a preliminary exploration of carrying the coordinate substrate onto microcontrollers, and is likewise not built. The local-inference note is an architectural observation on an external project, DwarfStar, and where the coordinate model may or may not contribute to it. The unseen-volume report is neither a proposal nor a design: it is a test, run and gated, on a store laid out on removable media — and the three defects that running it turned up.
CUBELinux Newsletter. Get update summaries as they happen — new builds, verified milestones, and project progress.
Sign up for the newsletter →
The drafts
A Store in Production: PowerButton.io
Integration report · 2026-10-01 · written by an agent on the box
A standalone CUBE store — the cube binary and its images, in userspace, with no kernel module and no filesystem to mount — taken out of development and put under a product with paying customers, on one Oracle Cloud instance (Oracle Linux 9.8, aarch64, 1 vCPU): 34 stores, one per account plus the platform's own. The report is that integration from inside — the classes the product declares (112 agents, 120 one record per priced model call, 124 the conversation, 125/126 the owner's space and the workspace, 128/129 tasks and steps, 130–239 one private space per agent, enforced by a doorway and not by a prompt), the one-writer rule and the two wait layers it forces onto every code path, and what production actually looks like: 28 gates, a scheduler tick of 0.42 s, mail recorded in the customer's own outbox. It ends with three things that went wrong — a held store read as data by three of our own gates, a rate limit that had begun counting our own tests, and a scripted client on Tor using our signup form to make 58 accounts for addresses that never asked — plus what we would ask CUBELinux for next, and what is not done.
The Unseen Volume: a CUBE Store on a USB Dongle
Report · 2026-09-23
A test, not a proposal: an ordinary 15.7 GB USB stick was given a CUBE store, and a machine wrote four records at coordinates through cube(2), went away, and found them again on the device — 4 spaces, 8 records, walked off the hardware by a later boot. Three findings came out of it that were not the point. A device can be named the way this substrate names anything: its own space id (0xF9 ‖ SHA-256(serial)), an identity record in it, and a portal as the doorway — built, and required of the gate from outside. The volume is invisible to the desktop (udisks reports no usage, no type, no label, no mount points) and that turns out to be a property worth keeping: possession stops being discovery, there is no filesystem parser in the path, and nothing indexes or mutates the bytes. And the work found three defects — a store with no control block that acknowledged writes it never flushed, a walk with no store behind it that served ~200,000 invented records a minute, and a userspace reader that asked to hold a whole 15.7 GB device and was killed for it. All three are fixed and gated; what is not built is named in the closing section.
CUBELinux — The Builds to Date
Build record · 2026-09-23 · updated for build #102
The running record of the CUBELinux builds: what the system is now, the milestones reached, what it does, what the gates prove, and what is still ahead. The store lives in the kernel and the kernel serves it on the metal (build #102, installed and what the default entry boots); a coordinate is an address (format v4); a region is a seek (CUBE_OP_RANGE); 218 tests, 0 failures, and 30 gates named with 29 of 29 green; the live sealed store holds 71,586 records (measured 2026-09-25) and the kernel walks them end to end; and a store can now live on a device that is not this machine — see the report above. It names the defects the gates caught — including the walk that never ended, and the machine it took down — with the first whitepaper kept untouched as the design record.
CUBELinux — A Coordinate-Addressed OS
Final draft · 2026-08-21 · updated 2026-09-06 with WordFlags + cubetrace + verification pass
The primary whitepaper. Documents the core claim (a position in space resolves to bytes), the coordinate primitive (256-bit space selector + Morton-ordered leaf behind a Curve trait), the storage layer (WAL + delta checkpoint, 250ms/200-op burst cap), the OS entity schema (MEM/SES/PRJ/EDG, with metatags as first-class citizens), the crate structure (7 built / 3 deferred / 1 dropped), and the custom kernel that has been built, installed, and booted. §7 closes with the FUSE proxy reaching M2(a): 2 tests added, 2 bugs fixed, `./check` green.
Updated 2026-09-06 — the tri-channel word's 12 "wasted" bits were realized as a 16-bit per-word flag field (cubecoords::WordFlags, header tag 14) with scan_by_word_flag/show-flags; the cubetrace layer is now built (execution capture → replay → store as Kind::Layer records → golden-regression → lineage walk, with the Solitaire example); and the whitepaper's own benchmarks were re-tested in release — ~180 tests green, encode costs/box bake-off/session-replay/edge-walk reproduced within ~1–2%, with one revision: feature-ball recall does not favor Hilbert. See §8–9.
State-Spanning Neural Networks for the CZYX Coordinate Filesystem
Preliminary draft · 2026-08-23 · posted 2026-08-25
An exploratory addendum. Proposes five application domains for state-spanning neural networks (LSTM / SSM / GNN / transformer-with-memory / autoencoder) layered optionally on top of the CZYX filesystem: access-pattern prediction with prefetching, coordinate-conditioned compression, anomaly detection in cube operations, learned indexing for range queries, and adaptive caching with neural policies. Each domain gets a model sketch, integration point, and challenge assessment. Central thesis: CZYX's Morton-encoded locality makes neural approaches viable as optional optimizations, not as replacements for the deterministic storage core.
CUBE Integration into ESP32 Modules
Preliminary draft · 2026-09-09
A proposal for carrying the coordinate substrate onto ESP32-class microcontrollers. Describes the device as a first-class coordinate space — its own 256-bit SpaceId, with configuration, telemetry, and health held at coordinates and its relationships held as first-class association edges. Presents two deployment tracks: the device as a CUBE client speaking a coordinate protocol to a host daemon over MQTT/TCP, and the device as a standalone CUBE node with a non-volatile store and its own listener. Draws the precise portability boundary — cube-core and cube-store-raw are no_std and cross to the device, while the durable store, daemon, and FUSE view do not — and closes on the graph-and-Portal model for a device fleet plus the agent monitoring layer, in which recall and topology are the same graph walk. Central thesis: CUBE does not merely store bytes on a device faster; it makes monitoring, memory, and control one traversable, capability-gated coordinate graph.
The Memory Dial: Local Frontier Inference and the Coordinate Substrate
Preliminary draft · 2026-09-12
An architectural note on a structural correspondence. DwarfStar (DS4) runs a 284-billion-parameter model on 128 GB of consumer memory by quantizing only the routed experts, protecting the load-bearing weights, and streaming experts from SSD through a power-law cache. The paper's central finding is in the key layout: a mixture-of-experts router selects among 256 experts with one byte, and the CZYX key already reserves one byte to select among 256 disjoint entity classes — the fields align without shifting, so where an expert can live is a property of the address rather than a decision left to a cache at runtime. It then asks what follows if a model's layout is expressed inside the coordinate space rather than beside it: hot experts pinned by prefix, model versions separated by space selector, access expressed as a Portal, and a different curve chosen at each level of the hierarchy. States plainly where the argument fails (the compression is quantization, not addressing; today's engines do not address weights this way), examines why the Jetson AGX Thor is sm_110 against the supported sm_121, and proposes one bounded experiment — whether the routing pattern has locality at all — with a stated pass/fail.