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.
CUBELinux Newsletter. Get update summaries as they happen — new builds, verified milestones, and project progress.
Sign up for the newsletter →
The drafts
CUBELinux — The Builds to Date
Build record · 2026-09-23
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 #79, booted on the workhorse); a coordinate is an address (format v4); a region is a seek (CUBE_OP_RANGE); 206 tests, 0 failures, and no red gates; the live sealed store holds 69,749 records and the kernel walks them end to end. 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.