CUBELinux is an operating system substrate in which a position in abstract space resolves directly to bytes. Data is addressed by a coordinate — a space selector plus a spatial point — rather than by path, hostname, or inode. This single primitive is used to name a byte on an SSD, a record in a persistent store, a node in a routed graph, a capability token, and a keyframe in an AI inference pipeline, with the same resolution machinery throughout.
The claim is not that CUBELinux replaces every existing namespace. It is that the three namespaces we currently bolt together — file paths, network addresses, and content hashes — are three instances of one underlying problem (position resolves to bytes), and that a unified coordinate layer gives us prefix aggregation, crash-durable storage, first-class associations, and capability-by-construction in one system rather than three bolted-on layers.
The idea is not presented as revolutionary. Several deployed systems already converged on the same underlying insight (see §1): Kademlia/Chord, Vivaldi, and IPFS content-addressing all use a position-in-space-resolves-to-bytes model. The CUBELinux contribution is the specific synthesis of that insight with a 256-bit space selector, Morton-first leaf ordering behind a Curve trait, reserved Null-space metadata, and first-class addressable associations — applied to a running OS substrate and a kernel that has been built, installed, and booted.
This whitepaper documents the design, the verified on-disk state of a running system, and the kernel build that HAS BEEN completed, installed, and booted. A FUSE proxy (cube-fuse-proxy) demonstrating format-proof via a mountable filesystem was completed and checked green on 2026-08-25 (see §7).
/home/CUBELinux/whitepaper/10-session-build-history.txt and /home/CUBELinux/whitepaper/11-session-reboot-history.txt.A position in space resolves to bytes.
Path, hostname, and IP are three namespaces with three resolution mechanisms bolted together; much of a modern system's complexity is translation between them. If one address primitive can serve all three, that is an architectural result, not a reskin.
This is not speculative. Several deployed systems already converged on it:
| System | Space | Resolution |
|---|---|---|
| Kademlia / Chord | 160-bit ID space | greedy descent |
| Vivaldi | synthetic Euclidean | distance predicts latency |
| git / IPFS content address | 2^160–2^256 hash | position IS the name |
The idea is a rediscovery of something that works at internet scale. That is good news, and it also means the unsolved parts are known and specific. The CUBELinux work does not claim to surpass these systems — it converges with them on the same underlying insight and extends it into a storage+OS substrate.
The load-bearing decision is whether the coordinate encodes locality.
The global routing table is roughly 1 million entries instead of 5 billion because of aggregation: a router says "everything matching 153.66.0.0/16 goes out port 3" and forgets the rest. That works only because addresses near each other numerically are near each other topologically.
A coordinate space inherits that property only if nearby coordinates are nearby in the underlying medium. Which is the Morton-versus-Hilbert question.
This is the convergence that matters. The property that makes an SSD read sequential is the same property that makes a routing table aggregate:
The coordinate is a pair:
Coord { space: SpaceId, point: Point }
where:
Cross-space movement is an explicit edge — a Portal — not arithmetic. This is a deliberate choice that gives us a space graph with the same structure as the internet's autonomous systems: separate routing domains, peering points as wormholes, and the ability to traverse without global knowledge.
The origin of the wormhole model is a play-by-mail science-fiction game in which C,X,Y,Z mapped stars, wormholes, and planets, and knowing a coordinate was what let you traverse to an entirely different coordinate set. The property worth preserving from that game is locality of navigation: you know your neighbours and your exits, never the whole map. A system that can be traversed without global knowledge is the kind that scales, and it is a genuinely different starting intuition than "one big flat address space."
The honest caveat: "unguessable coordinate equals access control" is security through obscurity unless the space is large and sparse enough that brute force is infeasible AND coordinates do not leak. Sci-fi wormholes are secret because the game master says so; real ones are secret because of entropy. So a portal's exit coordinate is a 256-bit derived value, not a human-scale integer. Two regimes, deliberately: enumerable coordinates for local, dense, in-space addressing; wide derived coordinates for cross-space edges.
A linearisation strategy maps a Point to a scalar key. Two impls exist: Morton (Z-order, bit interleave, branch-free, a few instructions) and Hilbert (Skilling's transform, iterative rotation, ~an order of magnitude costlier, strictly better locality).
The recommendation is Morton first, behind a Curve trait. Rationale: the prefix property — the thing routing aggregation actually needs — holds for both. The difference is quality of locality, not presence of it. Morton's cost is a handful of instructions; Hilbert's advantage only shows up under measurement.
The decision is made by benchmark, not by argument, and the loser stays compiled so the comparison stays reproducible.
A falsifiable prediction: on a sequential-ish access pattern, Hilbert should produce measurably fewer distinct NVMe read requests than Morton for the same logical region. If it does not, Hilbert's extra cost buys nothing here and Morton is simply correct.
The bake-off tested axis-aligned box scans on cold NVMe. The result is not a clean win for either curve, and that is the interesting result.
The conclusion is not "use Morton." The conclusion is: pre-align the query. Snap the request outward to the enclosing aligned block, read one run, filter in memory. That gives exactly 1 run in every case — perfect locality by construction — at a worst-case 8x read amplification (2x per axis in 3-D). Sequential NVMe throughput versus random IOPS is a ~100x gap, so trading 8x bandwidth for 194x fewer seeks wins decisively. Worst case is a consistent 8.0x read amplification, bounded and predictable — unlike seek counts, which grow with region size.
Encode cost on 10 million points: row-major 1.4 ns/op, Morton 141.6 ns/op, Hilbert 456.2 ns/op. Hilbert is 326x slower to encode than row-major and 3.2x slower than Morton. The current Hilbert implementation is a naive bit-at-a-time loop and could be made several times faster, but it will never approach row-major's single memcpy.
The Curve trait paid for itself: three implementations, swapped by type parameter, and the winner was decided by measurement in one sitting.
Re-verified 2026-09-06. We re-ran this exact bake-off in release and reproduced it: Morton 140.6 ns/pt (draft 141.6), Hilbert 454.9 (456.2), row-major 1.7 (1.4); row-major's unaligned blowup ~77.5 MB / 196 seeks (draft 79 MB). The conclusion survives; the numbers hold within ~1–2%.
[ space : 64 ][ class : 8 ][ leaf : 120 ]
routing entity Morton-ordered leaf coordinate
prefix type
The curve question is now local: within a (space, class) subtree, Morton orders leaves. All three workloads reduce to prefix scans plus point/edge lookups, both of which Morton serves with 1-seek raw reads.
The 24-byte fixed key is pinned by the on-disk format of FileBackedStore. Any kernel driver target format MUST match this format. No new decision needed.
Resolved: logical. Physical LBA addressing fights the SSD's FTL — the drive already remaps, wear-levels, and garbage-collects underneath any address handed to it. On NVMe the win from pretending to control physical placement is close to zero, and the cost is a design coupled to one device. Coordinates are therefore logical/semantic, mapped to storage by the backend. A RawBlock backend may later choose a placement policy; nothing above the storage trait may assume one.
The storage layer is abstracted from day one. The Store trait has put, get, delete, range, entries, flush, and flush_count. The backing medium (memory now, a file or raw block later) is swappable without touching callers. This is not a convenience — it is the property that makes the kernel boundary stay in cube-core instead of leaking into cube-store, and it is what lets the same record format be read by a userspace daemon, a FUSE client, and (later) a kernel driver.
The canonical on-disk record layout, written by FileBackedStore and read by the kernel reader, is:
[MAGIC "CUBE"][u8 version=1][u8 curve_tag] // header (6 bytes)
then zero or more records, each:
[SpaceId 32 bytes][Key 24 bytes][u64 len LE][value len bytes]
Key is a 24-byte fixed key (three 40-bit Morton axes). Curves are tagged: 0=morton, 1=row-major, 2=hilbert. This is the answer to DESIGN §8.1's open question (u64 vs u32 axes): the code already fixed the key at 24 bytes.
The early version of the daemon stored everything in an in-memory HashMap and wrote the whole store file on every flush — O(N²) I/O, and any write acknowledged by the daemon was lost if the process died before a flush. That was a showstopper, and the v1 report said so explicitly.
The current version (2026-08-11, WAL + delta checkpoint) is correct. The WAL is an append-only log with group-commit fsync (250ms / 200-op burst cap). The base snapshot is a JSON file; deltas are written incrementally and folded into the base on checkpoint. Crash loss is bounded to ≤250ms or ≤200 writes. Recovery is proven by wal_recovery_after_crash: kill -9 the daemon, relaunch with the same --store, and the written value is there.
The honest trade-off: the v1 in-memory path had lower per-op latency because it did zero durability work. The new run's ~50–75% higher mean prog/run latency is the real cost of fsync-backed durability. That is the correct exchange. A store that is fast but loses data on crash is worse than one that is slightly slower but survives it. The tail max for prog actually improved (98.45us vs ~175us baseline), and throughput held/rose (379 vs 325 pairs/s) because the harness is gated by cubec process spawn plus socket round-trip, not by store speed.
From the 2026-08-11 full stress run (150s, fresh throwaway daemon, gate ALL CHECKS PASSED):
Against commercial models:
Bottom line: CUBELinux-2 is now in the "durable, coordinate-addressed, sub-15us mean command latency" zone — faster than SQLite's durable path, lighter than RocksDB/LMDB for its single-writer local niche, but not yet a concurrent/multi-tenant DB. The concrete gap and the path to it are in §9 (concurrency/sharding + multi-writer persistence); the first sharded-read step is measured there.
A late stress run found a 4% error band traced to the audit command. Root cause: the audit op did a full get_record of the audit head, split the entire log string on newlines, pushed one line, and put_record the rejoined log on every operation — O(n) in the number of audit entries, serialised under a per-store Mutex. Latency grew with the log: op6 mean ~367ms, max ~3003ms (the 3s socket cap). Every other op stayed ~19–21ms. Auth was a non-factor (zero rejections in any run).
The fix: the audit head now stores only a decimal entry count, and each audit entry is written as its own durable record at a distinct coordinate derived from its sequence number — matching the PDF's "access logs live in Null rows" time/stream-keyed model. append() does two O(1) put_record calls under a single per-store guard. A per-store in-memory tail cache makes dump() O(1) as well, even as the log grows to thousands of entries.
Load-level proof after fix: 8 users x 150s, audit ON, 110,647 ops, 0 failures, op6 mean 11.9 ms (p99 46.9 ms, max 124.9 ms) — on par with every other op (5–15 ms). The 4% error band is gone.
The bake-off proved Morton wins axis-aligned box scans. The three OS workloads — AI memory, sessions/threads, and projects — are mostly NOT box scans. So "Morton won the box" does not transfer. The real carrier is the coordinate schema: what the axes mean per entity.
Two retrieval models are available; pick by what "recall" means.
Association-graph model (recommended): each memory is a leaf keyed by memory_id (hash → 120-bit leaf). Recall = traverse EDG edges (memory → linked memory). That is O(1)-per-hop point/edge lookup — curve-independent. Morton is fine; the edge index does the work.
Feature-ball model (alternative): memory leaf = quantized feature vector (fx, fy, fz); recall = nearest neighbours in a ball. Caveat: the bench's aligned_boxes decomposition is axis-aligned only — it cannot represent a ball. The bench initially only tested axis-aligned boxes, so this was marked unproven — it has since been tested (2026-09-06): Morton 2716, row-major 2724, Hilbert 2730 runs for random ball data (2798 ball pts), and a 3-way tie (5165/5166/5191) for clustered features. Hilbert does not win feature-ball recall. A sphere does not align with any curve's monotone blocks, so recall is served by the curve-independent 1-seek bounding-cube path + in-memory filter; the aligned_boxes decomposition is axis-aligned and cannot represent a ball, but the bounding-cube path makes the curve choice largely irrelevant for recall. (The open question there is the distributed/replicated read path, not the curve.) Resolved balling algorithm (2026-09-06): the correct structure for feature-ball / nearest-neighbour-in-ball recall is a metric VP-tree (or a multi-layer HNSW graph), not a curve. A VP-tree over the feature vectors gives exact 100% recall with ~277 node visits per query (bounded, log-like) vs any curve reading ~1 run per ball point. It is CUBE-addressable: each tree node = a feature-vector record, its children = linked_records edges. So the feature-ball idea is sound — the curve was the wrong tool for it. Now built as a real CUBE index (cubecode::ballindex): the VP-tree is stored as records (doc_type="vp-node", body = pivot + radius, children = linked_records), and ball_stats walks it. Measured at N=2000: exact 100% recall, ~125 node-visits/query (each visit = one record read) — bounded, log-like, vs any curve's ~1 run per ball point.
Leaf = seq (monotonic 120-bit, or (thread_id:40, seq:80)). Replay a thread = prefix scan on seq = single-span raw read, 1 seek (proven ideal). Append = write at head.
Leaf = (dir_hash:40, file_hash:40, block:40) or a path-prefix hash. Read a file = prefix scan on (dir, file); read a block = point lookup. Morton prefix property gives 1-seek sequential reads. Pairs naturally with the "project = space" routing above.
Leaf = (from_id:60, to_id:60) (+ optional kind:8 in class or leaf). This is the mechanism that makes MEM association-recall O(1)-per-hop. Stored in the same coordinate space, different class subtree. This is the single highest-leverage idea in the whole design: it turns "memory" from a scan problem into a graph-walk problem and makes the curve choice almost irrelevant for recall.
The AdjacencyIndex (reserved space 0xAA55AA55..AA55AA58) materialises the EDG out/in adjacency from the store into O(deg) outgoing/incoming/follow lookups (versus the legacy O(scan) HeaderStore::outgoing). The bench measures ~650k edges/ms on a real FileBackedStore at 500 nodes / 8 edges / 20k hops.
Control loop must hit deterministic latency → forbid the aligned decomposition (64 seeks). Use single-span raw read (1 seek) on the hot path. The bench's "aligned reads fewer bytes" win is irrelevant in a control loop. Row-major's 79 MB offset-box blowup is disqualifying (cache thrash, missed deadline). Morton/Hilbert stay safe. Encode cost lands on the hot path: 132 ns/pt (Morton) vs 411 ns/pt (Hilbert) per coordinate op x millions of ops/tick is a real latency line. Morton over Hilbert for the OS on this ground alone, unless feature-ball recall demands Hilbert (still unproven).
PROVEN (by cube-bench, cold NVMe):
NOT PROVEN (needed before declaring "Morton serves the OS"):
Recommendation: ship Morton first, behind the Curve trait, with space as a routing prefix and class/leaf as the Morton-ordered tail. Build the EDG association index as the primary memory-retrieval path. Keep Hilbert in the trait — but it is not better for feature-ball recall (see above), so do not reach for it to fix that workload. Since 2026-09-06 the original #1–#3 are benched: feature-ball measured (curves tie), edge-walk ~8.9M edges/ms in-memory / ~5.0M on a real store, session replay a 1-seek prefix scan for every curve.
CUBELinux's retrieval model is not "find by path, then read." It is "find by tag, then read." That distinction is the single most important thing to understand about the system, and it is where the 2006 insight (Null-space metadata as first-class citizens, associations as first-class edges) connects directly to what makes the system useful for AI and search today.
Path-based systems — filesystems, document trees, folder hierarchies — force you to guess where something lives before you can find it. The hierarchy is the retrieval mechanism, and it is brittle: move a file, rename a folder, reorganize a project, and the paths break. AI systems built on top of path-based storage inherit the same problem: they can search text, but they cannot search structure, because structure is not a property the system exposes — it is a convention the human maintains.
CUBELinux does the opposite. Every record carries its metadata (tags, type, creation date, permissions, associations, access counters) AS PART OF THE RECORD, addressed by coordinate, not in a side table. The EDG association index (§4.4) makes those associations traversable — a graph walk, not a directory listing. The Null-space metadata model (cubeheader crate, called "the best original idea in the PDF" in the crate status table in §5) makes permissions, timestamps, and links first-class citizens of the same space as the data. This is what "metadata as first-class citizen" actually means: the tags are not bolted on; they are the record.
The retrieval implication is direct. A traditional filesystem returns a path. A CUBELinux query returns a coordinate AND its tags, and the EDG index lets you walk from that record to everything linked to it — parent, child, variant, version, related — without knowing the hierarchy in advance. For AI context, this is the difference between "the system knows where the file is" and "the system knows what the file is and what it relates to." An AI agent querying CUBELinux does not need to guess a path; it asks by tag (type, owner, association, creation date, access count) and gets back the records that match, with their graph of relationships already materialized by the AdjacencyIndex. That is structurally different from a search engine over a folder tree, and it is why the metatag model is the thing that makes CUBELinux worth building rather than another filesystem with a search index on top.
This is also why the 2006 decision to put metadata in Null-space coordinates rather than a side table matters. A side table is a second structure to maintain, a second thing to query, a second thing that can drift out of sync. In CUBELinux, the metadata is the record's header, addressed by the same coordinate as the body, written by the same put, read by the same get. There is no "sync the metadata with the data" problem because there is no separate metadata to sync. The tag IS the record, and the record IS the tag. That is the design choice that makes retrieval fast, correct, and AI-compatible — and it is the one place where the 2006 notes were ahead of their time and remain ahead of most deployed systems today.
The PDF names 11 crates. The build consolidates them into a working set, keeping the user's names where the responsibility matches and correcting the two that carry defects.
| PDF crate | Status | Notes |
|---|---|---|
| cubecoords | BUILT | → cube-core (no_std): SpaceId, Point, Coord, Curve trait with Morton/RowMajor/Hilbert, Portal; TriWord/WordFlags (16-bit per-word flag field) + HeaderFlags. Compiles for thumbv7em-none-eabihf (bare-metal ARM). |
| tricoding | REVISED | The body packing was dropped (density regression + compressors win) — but the 12 "wasted" bits + 4 control bits were realized as a 16-bit per-word flag field (cubecoords::WordFlags, pack_flags/unpack_flags): real inline metadata, free on raw size. Measurements: raw stays +33% (6 chars/word); zstd +59% with flags reserved, +73% carrying real metadata. See §8.1. |
| cubeheader | BUILT | Null-space metadata model. Header flags, associations as first-class edges. The best original idea in the PDF. |
| cubestore | BUILT | Store trait + MemStore + FileBackedStore + RawBlockStore + WAL/checkpoint. 24-byte on-disk key, format pinned. |
| cubecrypt | BUILT | Record-level encryption (AES-GCM, XTS, ChaCha) with derived ≥256-bit identifiers. Standard primitives. Obfuscation-as-security discarded. |
| cubefs | BUILT | FUSE front-end. Maps c<C>/z<Z>/y<Y>/x<X> to coordinates. --socket mode is a genuine FUSE view of the daemon's durable store. |
| cubetrace | BUILT | EXECUTION CAPTURE + REPLAY realized (cubecode::vm run_captured/replay); captured traces stored as Kind::Layer records, plus golden-regression and lineage graph-walk (store_trace/replay_trace/capture_golden/verify_golden/lineage) + CLI. See §8.5. |
| cubedbt | DEFERRED | Replay engine. Not built. |
| cubeai-core | DEFERRED | AI/ML tier. Excluded on this hardware. |
| cubeai-agent | DEFERRED | AI/ML tier. Excluded on this hardware. |
| cubed-daemon | BUILT | → cube-server + cubec (the daemon boundary). Holds one CubeStore, serves command language over Unix socket, snapshots to JSON. |
| cubecli | BUILT | CLI: write, run, ls, stat, seal, open. Standalone crate (cubecli/), identical behaviour to former cubesys/src/bin/cube.rs. |
cube-core is #![no_std], allocation-free, forbid(unsafe_code). The no_std boundary doubles as the kernel-portability test: if something cannot be expressed without std, it does not belong in the core. The crate already compiles for thumbv7em-none-eabihf (bare-metal ARM, no OS), so the coordinate primitive is kernel-embeddable today.
The custom Linux kernel (Surface Pro 7, Intel IPU4 camera subsystem, custom CUBE block-device driver interface) has been built, installed, and booted. This is a verified fact from the session store, not a plan item.
The kernel build is tracked across 10+11 sessions in the session store database. The build session, reboot session, and verification sessions together establish that the kernel compiles, installs to /boot, and boots on the target hardware. The kernel is not a future deliverable — it is a completed one.
The kernel's relevance to CUBELinux is the block-device seam: the cube-store RawBlock backend targets a real NVMe partition through the same BlockDevice trait that FileBlockDevice (regular file stand-in) satisfies. The kernel driver would be a third impl of that trait, and the on-disk format is already pinned (see §3.2), so the kernel driver is a backend impl, not a format change.
This is the blow-by-blow of what was built and tried — the story behind the facts in §1–§6, told as we lived it. Each step led to the next, and several open questions were settled by measurement rather than argument.
The FUSE proxy (cube-fuse-proxy, a standalone crate) reached the M2(a) gate on 2026-08-25: it compiles cleanly (0 errors, 5 trivial warnings), passes ./check (fmt + tests + clippy) green, mounts a FUSE filesystem via fuser::mount2, and its proof binary (main.rs, 383 lines) demonstrates seed read/write/remount through the mount. Two tests were added (root-dir readdir, root-dir "."/".." lookup) and two real bugs fixed (the || true short-circuit removed; root lookup handles "." and ".."). M0 and M1 are committed; M2(a) is demonstrated. That is where the draft left off on 2026-08-25.
§5 records tricoding as DROPPED because the body packing was a 25% density regression. But that evaluation missed what the 12 "wasted" bits were for. We first measured the body read path to settle whether a tri-channel body was even worth it: raw body 34,890 MB/s (memcpy) vs tri-channel unpack_flags 9,062 MB/s — raw is ~3.9× faster and 33% smaller. So the body stays raw.
That freed the 12 wasted bits plus the 4 control bits to be a 16-bit per-word flag/metadata field, realized as cubecoords::WordFlags(pub u16) co-packed with 6 data bytes in a TriWord (bits 48–63), via TriEnc::pack_flags(WordFlags, [u8;6]) / unpack_flags — backward-compatible with the old pack_6 (its 4 control bits are the high nibble). Measured, the flag field costs zero raw size (still 6 chars/word); compression is +59% with flags reserved and +73% carrying real metadata. The 16 bits map to CUBE Null-space semantics: arrangement, start/end-of-record, header-vs-payload, continuation, data-type, permissions, encrypted, compressed, stego, null/lookup, checksum.
We then wired it through the stack: each record's header carries the record's WordFlags as a fixed u16 (header tag 14, alongside the per-record HeaderFlags tag 12), written by encode_header/decode_header and preserved by refresh_flags — so reading the flags needs no body decode. The OS exposes it end-to-end: CubeStore::scan_by_word_flag / ConcurrentStore::scan_by_word_flag, cube show-flags <C.Z.Y.X>, cube scan-word-flags <flag|0xbits>, and OS-created records are stamped via cubesys::default_word_flags(kind, descriptor) (START|END|IS_HEADER + type=code for Fn/Kernel + ENCRYPTED for security-sensitive).
The "cubetrace" layer §5 had marked DEFERRED. We built it. Vm::run_captured(entry) records the exact ordered instruction trace a program actually executed — the "machine code as it runs"; branches resolved, call frames marked. replay(&[Op]) interprets that trace on a fresh stack + frame-based locals, with no access to the original program, reproducing the observable behaviour (data-stack result + SYS_TRACE output). The trace is stored as a first-class Kind::Layer record linked back to its source (store_trace/replay_trace), so runs persist as linked CZYX records. We added golden-regression (capture_golden/verify_golden: re-run fresh and replay the stored trace, asserting both match the recorded output) and a lineage graph-walk (lineage). The CLI exposes it: trace-capture, trace-replay, golden-capture, trace-verify, trace-list, trace-links.
A small solitaire state machine is the worked example: we captured its executed-op trace, stored it as a Layer record, and replayed it to reproduce the game's actions purely from the captured trace — not from its source.
We ran the full workspace test suite (~184 tests, 0 failures (full workspace suite): cubeai 5, cubecode 21, cubecoords 8, cubecrypt 12, cubedbt 4, cubefs 53, cubestore 17, cubesys 54 + cube-server 5, cubetrace 3, cube-mvw 2) and re-ran both benches in release. The whitepaper's own numbers reproduced within ~1–2% (see the notes woven into §2.3 and §4.6). The store performance reproduced too: put_raw 237.6 ns/op (draft 236) and ~4208k put/s (draft ~4237k). The one revision: feature-ball recall does not favor Hilbert — the curves tie (Morton 2716 / row-major 2724 / Hilbert 2730 for random; a 3-way tie for clustered), and ball recall is the curve-independent 1-seek bounding-cube path. So the ship-Morton-first recommendation survives; Hilbert stays in the trait but is not for balls.
CUBELinux is a coordinate-addressed OS substrate that addresses bytes by Coord { SpaceId, Point } behind a Curve trait. It has a durable WAL+delta-checkpoint store with a pinned 24-byte on-disk key; a record header that carries both per-record HeaderFlags and a per-word 16-bit WordFlags flag field (header tag 14); first-class associations (EDG) with an AdjacencyIndex; a safe, deterministic, cube-addressed bytecode VM (cubecode); running cubefs (FUSE) and cubecrypt; and a custom kernel that has been built, installed, and booted. New since 08-25: cubetrace (execution capture → replay → store-as-Kind::Layer → golden-regression → lineage), per-word flag queries and inspection, a CUBE VP-tree balling index (cubecode::ballindex), and a full re-verification pass. And now a real concurrent DB OS backend: cube-mvw implements CubeBackend, so CubeStore<MvwBackend> is a durable, sharded, multi-writer MVCC store with per-shard WALs + group-commit + LSM-lite compaction and crash recovery — the DB OS is becoming a reality. ~184 tests green (full workspace, incl. cube-mvw); both benches reproduced.
Faces it can wear: AI/ML experiment lineage & reproducibility; behavior cloning/imitation (the Solitaire idea generalized); security/forensics/malware behavioral traces; replayable audit/compliance event sourcing; golden-trace regression; agent/LLM session capture; robotics control-loop analysis. (The full-use-case list is in the companion neural-network addendum.)
What we plan to try next — each a measurable step, not a promise:
cubefs::vfs::Attr carries word_flags/header_flags (from the record header, tag 14/12) and cube stat <path> prints them named (verified: word_flags=0x009c (tri6|start|end|header|type=code)). Still open: expose as read-only FUSE xattrs (user.cube.word_flags) and add a per-word flag index for faster scan_by_word_flag.u8 bytecode VM; feed a real tracer (Intel PT / QEMU / a JIT listener) into the same trace-record + replay machinery — the mechanism generalizes beyond the VM.RwLock over one map serializes even readers via atomic count contention: it drops to ~10 M reads/s at 16 threads. Sharding key→shard with a per-shard RwLock scales: shard-64 hits ~75–80 M reads/s at 16 threads (~7–9× the single lock). That is the read side of a multi-tenant DB. Writes need the same sharding plus MVCC/timestamps and a durable concurrent WAL; then per-tenant isolation (each SpaceId is already a namespace boundary), capacity/quota, and transaction isolation complete the picture. Writes measured (2026-09-06): a single write lock serializes writers (0.7–2.7 M writes/s at 8–16 threads), while shard-64 reaches ~12.2 M writes/s at 8 threads (~4.5×); it saturates at 16 threads (per-shard HashMap rehash/cache contention — a full multi-tenant DB needs per-shard LSM/B-tree + MVCC, not a sharded HashMap). Step 2 BUILT as a real DB backend (2026-09-06): cube-mvw is now a CUBELinux workspace crate whose MvwBackend implements CubeBackend — so CubeStore<MvwBackend> is a durable, sharded, multi-writer MVCC store with per-shard WALs (parallel durable commits), LSM-lite compaction (memtable + WAL delta + compacted checkpoint base), and crash recovery. Tests (2): MVCC latest-version-wins + WAL recovery (drop+reopen restores), and true concurrent multi-writer (8 threads × 2000 via interior-mutability put_shared, all readable); CubeStore<MvwBackend> records round-trip. Bench (16 shards): ~394–488k durable puts/s (per-shard WAL), ~8.1M gets/s, ~5 ms compact. Group-commit (batch one fsync per shard for many ops) gives ~1.1× more durable writes at this page-cache-warm scale (the write path here is bounded by memtable ops, not fsync; it matters more on colder/larger/remote storage). No tables layer is used: the metatag/coordinate/association model is the schema; per-shard WAL + group-commit + compaction are pure storage-engine on CUBE's own record/block format..ko) is a backend, not a format change (the format is already pinned).cubecode::ballindex). The correct balling algorithm is a metric VP-tree (or multi-layer HNSW graph) over feature vectors, stored as CUBE records + linked_records edges — exact 100% recall at ~125 node-visits/query (N=2000). Still open: re-bench at larger scale and add an HNSW variant for approximate top-k at very large N.ci-golden.sh runs the capture→store→replay→verify golden chain (execution-capture + replay, golden-regression drift, trace-as-Layer, lineage), the CLI trace-verify end-to-end (must PASS), and the sharded-read concurrency step — failing the build on any regression.