CUBELinux · The Builds to Date

Abstract

This is the running record of the CUBELinux builds: what the system is, what each build added, what the gates proved, and what is still ahead. The first whitepaper documents the design and is left untouched as that design record; this document records the builds, and it is written to be read on its own.

The store lives in the kernel. A coordinate is no longer only a way to name a record but a way to reach one — a lookup is a search over arithmetic addresses. A region is a way to query one: a box is found by seeking to the foot of its key span and reading forward. And as of today the whole path works on the metal: this machine boots CUBELinux, the kernel serves the store, writes are durable, listings return the store's records, and the log that makes writes cheap is now folded on a schedule instead of by hand.

Every number below is measured by a gate, by the test suite, or by a command whose output is quoted. Where something is not proven, it says so.

1. What CUBELinux is now

CUBELinux is a coordinate-addressed operating system. A coordinate is (space, point) — a 32-byte space selector and a 192-bit key produced by a space-filling curve (Morton by default) over three 64-bit axes. Records live at coordinates, not behind names; the space is a hard partition, so cross-space access is structurally impossible from a query. The store is in the kernel, the interface is cube(2), and everything above it is written against that interface — a name, a path, or a mount is a view at the edge, not the substrate.

Today that is a running system rather than a design:

• It boots. 6.19.3-cubelinux0.7+, build #102, is installed on the workhorse — bare metal, not a VM, and it is what the default entry boots. The store driver is built into the kernel (CONFIG_CUBELINUX_STORE=y), registers /dev/cubelinux at boot, and is told which image to serve by the command line: cube_store=/var/lib/cubelinux/store.img, with panic=30 so a fault returns the machine rather than hanging it. Build #86’s one change was to durability: the entry a write appends goes down unsynced, and the control block that counts it carries the single fsync for both — one sync where there were two, ordered so that a crash can lose an unacknowledged mutation but can never count one that is not there. The half of that sentence nobody checked was the assumption underneath it, that there is always a control block to carry the flush — and for a store with no control block there was nothing on the append path to flush at all, which §8 measures and #96 fixes. verify-torn-tail is the gate that justified the collapse, by tearing the log between the two and reading the result with userspace on the same bytes. #87’s change is the arrangement vocabulary’s second half: a value written as several records at consecutive z now comes back joined from one plain read of the first slice’s coordinate — and what it deliberately will not join is a sealed chain, because a sealed slice is an envelope with its own header and nonce, so joining those belongs to whoever holds the key. #87 is what is running — the box says so itself, Linux version … #87 … Wed Sep 23 19:51:11 EDT 2026 — and #96 is installed, taking over on the next reboot: it is the build that makes a refusal a refusal, and that makes an acknowledged write durable in both shapes the store takes (§8). It supersedes #95, which was installed for twenty minutes and never booted — every measurement in this record was taken on #87, and re-taking them on the metal is what the next boot is for. The first attempt at the benchmark boot would not start and is recorded in §8: its initramfs carried no disk driver, and on this machine the disk's driver is a module. The machine came back on the default entry after a cold boot, the boot is now rehearsed in QEMU against a disk of the same shape, and it is armed again for the next reboot — because the figure this build has not been measured for is its own durable write.
• It is the default now, with the workhorse kernel as the way back. As of 2026-09-23 GRUB's default entry is the CUBELinux entry, named by its explicit id (GRUB_DEFAULT='cubelinux'), and the previous workhorse kernel 6.19.3-cube+ is named as GRUB's fallback — so an entry that will not load hands the machine to the kernel that was there before. What that covers is an entry failing to load (a missing kernel or initramfs), and not a kernel that loads and then faults: panic=30 reboots into the same entry, and the way out of that is the boot menu or grub-reboot gnulinux-6.19.3-cube+-advanced-2a7b1834-83ed-4394-a8ee-816b885b5624. It has booted by default since 2026-09-23: a plain reboot, with nothing armed one-shot, came up on CUBELinux with cube_store= and cube_boot_record=1 both on the command line. A running kernel on this machine is therefore still a question about which boot, and /proc/cmdline is where the answer is.
• It serves its store. A client asks the front-end for a listing and gets the store's records; it writes, and the write is acknowledged once the kernel has taken it into the log and flushed it. The store on disk carries 70,408 records — measured today, and it grows as this site writes — in a v4 addressed image, sealed, with the format's own verifier reporting errors=0. That word "flushed" was earned back today: "acknowledged" had been taken to mean "durable", a store with no control block was acknowledged without a single flush on the path, and #96 fixed it at the cause — §8 has the measurement, and §9 records the decision.
• It maintains itself. A fold — the operation that empties the log into the image — now runs on a daily timer, so the store no longer depends on somebody remembering to fold it.
• It records its own boots. cube_boot_record=1 is on the command line, and it is doing the work: the kernel appended boot=1790189822 device=/var/lib/cubelinux/store.img kernel=Linux version 6.19.3-cubelinux0.6+ … into reserved space 0xFC, classed 0x0080, through the same append() as every other record — the OS storing itself, written by the kernel rather than by a client. It is verified three ways on the box, the way its gate verifies it: the record exists; cube(2) serves it back (a read of that coordinate answers 219 bytes with the mask 0x0080, and the front-end answers the same bytes for the name boot); and userspace finds the same record in the image after the log is folded (cube-image flag-scan for class 0x80 finds exactly one). The userspace marker it supersedes is retired; that marker had also stopped working, answering Function not implemented on a kernel with no cube(2).
• And it is fast where it counts, measured on the box. A coordinate read through cube(2) is 11 µs — the mean of 200 reads that find their coordinate, worst 21 µs — and a ten-record listing is 47 µs, and asking which spaces exist is 0.158 ms. One thing about that figure belongs here rather than left standing: those 200 reads asked for a coordinate the box’s store does not contain. The benchmark’s probe space (0x5c…) exists in the gates’ stores, which are built with it, and not in this machine’s, so the number is the cost of a read that finds nothing — the fast path — and the listing timed a space with nothing in it. It is left in place because it is a real measurement of a real question; what it is not is the cost of finding a record. The benchmark boot now names a space and a coordinate the live store actually holds, so the next run measures the question this paragraph was claiming to answer. A durable write is 4.962 ms on build #87, worst 5.652 ms over ten writes — measured on the metal after this build folded the write's two fsyncs into one, which is what halved it from the 8.2 ms that build #85 measured. Those are not the measurements this record carried before, and the write is the reason: the write path resolved the store's layout by reading the whole device — 100,663,296 bytes — in order to append seventy, which cost 60–131 ms per write and was never gated at all, because the gate timed only reads. It now reads the control block and the log's head. On the read side, the control-block validation, the header, the space table and the log window are held across calls instead of re-read per call, and the validation itself dropped from 4096 bytes to 96: the question every call asks of the control block is one number, and it is in the first 48 bytes of each of the two copies. The unfolded log is capped at 256 KiB and folded from the write path, because every read pays for it — the log's capacity is 50,335,744 bytes, so a full one would have put ~48 MB in front of every coordinate read.

2. Milestones reached

Dated, because a milestone is a thing that happened on a day:

3. The build line

The builds that changed the system's shape, in order:

4. What it does

Stated as capability, so it can be checked against the machine rather than believed:

• Address a record by where it is. cube(2) (syscall #548) puts, gets, deletes and syncs at a coordinate. No path, no name, no inode, and no lookup table between the caller and the bytes.
• Walk a space in bounded batches. CUBE_OP_ENUM returns whole records packed as key(24) | flags(2) | value_len(u32) | value, with a cursor that counts the records already returned. A short batch is not the end; a cursor that stops moving is.
• Ask a question about a region. CUBE_OP_RANGE answers the records of a space inside a box, by seeking rather than scanning. §6 has the numbers, including what the bound costs when the box is not aligned.
• Retrieve by class. CUBE_OP_FLAG_SCAN takes a mask, any or all, and one space or every space.
• Write durably, cheaply. A write is acknowledged once it is durable in the log, not once the image has been rewritten; the image is rewritten by a fold, which is now on a schedule. On this machine a write advances the store's on-disk generation and is visible to the very next listing — 6,164 records, one write, 6,165.
• Survive a kill. Acknowledged writes were shown to survive a SIGKILL (verify-kernel-append), and a torn log entry at the tail is discarded rather than replayed (verify-torn-tail). Both are measured on the two shapes a store takes — with a control block, whose count write carries the flush, and without one, where the entry carries its own — which is the distinction #96 found and §8 records.
• Serve a store that is not on this machine, and name the device that holds it. A USB dongle carries a CUBE store of its own, and the kernel serves it as its store: verify-dongle writes four records at coordinates through cube(2), lets the machine that wrote them go away, boots again and walks them back off the device — 4 spaces, 8 records — including the device's own space and the portal that leads to it. The device is found by its serial, never by /dev/sdX, and the gate refuses a device that is mounted or carries a filesystem.
  
  A device is an entity, and this substrate names an entity with a space. The reserved tags are classes — 0x00 root, 0xFB events, 0xFC boot, 0xFD keystore, 0xFE portal, 0xFF edges — and a device is the first class whose instances have to be told apart, so 0xF9 names the class and the rest of the id names the instance: 0xF9 ‖ SHA-256("cubelinux.device.v1:" ‖ serial)[0..31], unguessable because a space id is a capability. Declaring a device writes two records — the identity at that space's origin, and a portal descriptor in the portal space, entered from this machine's root and leading to the device — and the gate proves all of it from outside: the kernel's walk reports the space and the portal, and the same descriptor decodes off the device with the decoder that wrote it.
• Keep the store sealed at rest, with the records as ciphertext on the device.

5. The store and its interface

control block   two copies, 0x0000 and 0x0800   magic, slot size, active slot, generation
image slot      ×2 (the fold writes the idle one, then flips)
[header 46]                       magic, version, curve, extents, counts
[space table: space_count × 48]   space | first index | records
[index: record_count × 40 (v3) / 42 (v4)]   key | [flags] | value offset | value length
[values: packed, in index order]
log region                        the unfolded writes, drained by a fold

The index is fixed-size and sorted by key, so a reader computes a record's place as index_off + i × INDEX_ENTRY — a coordinate is an address, exactly as claimed. The format is described once, in drivers/cube/cube_format.rs, compiled by the kernel and included by userspace; two descriptions of one format is what once shipped an hour of unsupported-version.

A fold is safe to interrupt, and that is a property of the layout rather than a hope: the image lives in two slots, a fold writes the slot that is not active and then points the control block at it. Observed on this store: active_slot 0 → 1 with image_off 4096 → 25165824, and the log went from 49,280 bytes to 0.

Through cube(2) the operations are the verbs the design always named: PUT, GET, DEL, SYNC (fold), ENUM and SPACES (the bounded cursor walks), RANGE (the region seek) and FLAG_SCAN (by class). Each argument block is versioned by its own size field, so the interface grows by gaining a block rather than by being replaced — the coordinate block is 88 bytes, the walk's own is 64, and the kernel routes on the size it is given.

6. A region is a seek

The operation the address existed for is the region query — the records of a space inside a box — and it landed as a seek rather than a filter.

The key fact is about the curve, not the query:

Monotonicity. If p ≤ q on every axis, then key(p) ≤ key(q).

Under it, a box needs no decomposition at all: its two corner keys bound every key inside it, so the index is binary-searched for the foot of that span and read forward to its head — O(log n + span) instead of O(records). Every candidate is then decoded and tested for membership, because a span is a bound, not the set: keys of points outside the box also fall inside it, and returning them would be wrong.

Monotonicity belongs to a curve, not to the trait. Morton and RowMajor have it; Hilbert does not — it transposes and rotates the axes, so its corner keys say nothing about the keys between them, and seeking on them returns wrong answers. The store gates the seek on the curve, and a curve must opt in; it cannot inherit a bound by accident.

Measured over a 32,768-record space, asking 512-record questions:

The 1.00× is exactness worth naming — for an aligned cube at the origin the span is the box's keys. The 6.99× is the honest cost of a bound: an unaligned box's span covers keys of points outside it, and those are examined and rejected. The 64.00× is the gate working — Hilbert has no span, so it walks.

The gate kernel/verify-range.sh boots the kernel and diffs its answer against userspace's over an unaligned box holding a deliberate trap — a record at (2,7,7), outside the box but inside the span — and the walk is correct only if it examines that record and rejects it.

7. What the gates prove

The gate wall, and what each gate proves. The rows marked today were run on 2026-09-23 — the cost, file-store and syscall gates re-run on 2026-09-23 for the #86 change — each in its own VM or file store, so a gate is about the build rather than about what this machine happens to be running — and the box-side rows against whichever kernel was running when they were taken. The 4 µs read and the 8.2 ms write are build #85’s: they were taken before the reboot onto #86, which folds the write’s two fsyncs into one, and the box has not been re-measured since:

The board names 28 gates — verify-no-store (the walk defect's own gate), verify-dongle (a store on removable media) and verify-store-readers (a device refused before it is read) are all new today. The whole wall was run for this build — 26 of the 26 it named then: 26 pass, 0 red — and the two added afterwards — verify-dongle, run on its own with the device attached, and verify-store-readers, run on its own on this machine — both pass. A wall run from here on names 28. Every red the day produced is in §8 and none of them survives as a defect: two were gates accusing the kernel of what the live box was doing, one was the walk's own, and one was a store shape whose writes were acknowledged without a single flush on the path. The workspace suite — the crate tests that underpin all of the above — is 218 passed, 0 failed.

8. Defects the gates caught

Named, because each was found only by running the real thing, and a record that shows only the green is a ledger rather than a record:

• A walk that stopped at its first batch. A short batch is not the end — only a cursor that stops moving is. Caught at 747 of 3,006 records; now the rule the walk's tests are written around.
• An index entry written four bytes short — the value length, against the arithmetic that the index is fixed-stride.
• A store that could be folded exactly once: the second fold read an addressed image with a packed-only reader.
• A walk that never ended (2026-09-23). The batch's seen counter started at the cursor instead of at zero, and it is compared after being incremented — so nothing was ever skipped: every call re-served the space from its first record while the cursor advanced by the records returned. Since the cursor is the walk's only end signal, the walk never ended. A listing looped inside the front-end until the kernel's OOM killer took that process, twice, at about 6.4 GiB of anonymous memory each time — and while it was wedged, its writes failed. Every other path that builds a batch already started the counter at zero; this one was the outlier, and it only shows on an addressed image whose space has unfolded edits, which is precisely the live store and precisely what the earlier gates' packed test store never exercised. Fixed at the cause, bounded in the client so a future defect of the same shape cannot take the machine, and the live gate now fails fast instead of streaming duplicates forever.
• A boot record that was silently never written (2026-09-23) — and no gate caught it. With cube_boot_record=1 on the command line, the kernel's first store operation logged could not read the store to record this boot, and the store held no record in space 0xFC at all: the switch was on and the effect was off. The cause is a credential mismatch, not a store fault. The driver opens the store O_RDWR in the calling process's credential context and caches that handle for the whole boot, while every store client on this machine runs as an unprivileged user and the store image was root:root 0664 — readable by its clients, not writable by them. So the first client to touch the store lost that boot its record; once a root-context caller had opened it, the handle was inherited by every later caller and writes began landing normally. Fixed by giving the image the same group the store's other artifacts already use (chgrp cubelinux, mode unchanged), and the record appeared on the next boot. It belongs in this list precisely because it was not in the gate's: verify-boot-record.sh passes and always did, because in a VM the store is a raw device opened by root inside an initramfs — no unprivileged caller, no user services, no stale clock. A gate that opens the store as root cannot see a defect that only an unprivileged caller can produce. It also exposed a second, independent defect, since fixed and in the kernel this machine is running (#86): ensure_boot_record() claimed the boot before it attempted anything, so one transient failure cost a boot its record, with no retry. It now claims one attempt with a compare-exchange — so two callers racing into their first write still cannot both write a record — and that claim is counted whether it succeeds or fails, which is what makes a failure retryable on a later write, up to four attempts, because “a store that will not take it will not take it later either” is not true of the failure it actually had. The retry became affordable only because the record now goes down the same bounded path every other write takes: it used to resolve the whole device for the record and then resolve it a second time for the caller’s own mutation. That it is in this kernel rather than merely intended for it is checked against the image itself: the string the new failure path emits, the store would not take this boot’s record, is in the extracted kernel, and the message it replaced is not.
• A bench that measured a read it never gave a buffer (2026-09-23) — caught by an impossible pair of numbers. The cost gate timed a coordinate read with a.len = 0: no buffer. On the box that reported 0.000 ms across 200 reads while listing one of the ten records it returns reported 0.015 ms — and a listing is one lookup plus nine more index entries, so it cannot be thirty times slower than the lookup inside it. The reading was an artifact of the call's shape rather than a fast read, and it was flagged instead of published. It also means every read figure quoted from that bench before today was a figure for a call handed no buffer, including the one this record previously carried. Fixed by passing the buffer the loop already had; the corrected box numbers are above. The lesson is the instrument's own: a benchmark that skips part of the operation is a benchmark for the part it skipped.
• A display fault that left no trace, and then left (2026-09-23) — unexplained, unreproduced, and no longer being tested for. On returning from a boot the external monitor went black and came back with artifacts, and then it levelled out: the effect disappeared on its own, which is what a boot-time transient does and what a memory or hardware fault does not. Nothing was logged that would explain a persistent fault — no i915 error, no atomic-commit failure, no MCE, ECC or bad-page event, no OOM — and the store's canary was unchanged across it. The one trace sits in the settling window: intel_encoder_link_check_work_fn [i915] logged as having hogged a CPU for more than 20 ms, four times inside two seconds, minutes after that boot, and never again, with zero such warnings in the previous eight boots. The box's internal eDP panel is connected but disabled, so i915 link-checking a panel nobody uses was the suspect, and video=eDP-1:d was added to the CUBELinux command line to tell the kernel the connector is not there. It was removed the same day, and the reason is the point. It was in place for exactly one boot — the boot armed for the benchmark — and that boot's display was clean. That is not evidence for the hypothesis, because the fault had already stopped recurring before the token ever ran: a clean boot when nothing was going wrong is equally consistent with the token working, with it doing nothing, and with the transient simply being gone. The only outcome that would have carried information was the blanking coming back with the token in place. It did not come back, so the experiment collected a cost — the internal panel is unavailable to the kernel while that token is set, so undocking means a black screen — and no information. The fault stays in this list as unexplained and unreproduced: not fixed, and not filed as one. The token is one edit away in /etc/grub.d/12_cubelinux if the blanking ever returns, and the note there says which outcome would read as an answer.
• A walk with no store behind it served invented records forever (2026-09-23) — found by the first benchmark boot, and fixed in two halves. Reproducible in one boot — cube_store=<anything that is not a store> cubelinux.enum=1 — it served roughly two hundred thousand invented records a minute: a garbage space, a zero-length value, and a cursor that kept moving, so the walk never reached an end and the machine never got on with the boot it was making. It is the third time this project has met a loop with no end signal, and the first time the loop was in what the kernel answered rather than in how a client read it.
  
  The first half was the store's answer. A caller asking which spaces exist was told success — spaces returned 0, len=0, cursor=1 — so it copied the space it was handed out of a buffer the kernel never wrote, and because the cursor advanced by itself the rule that ends every other walk here, no progress is the only end signal, could never fire. A store_readable() guard now runs before either walk op answers anything, and the driver refuses a store it cannot read.
  
  The second half was a sign, and the diagnosis recorded for it was wrong before it was measured. The guard fired and the client was told success anyway, and both of the candidate explanations in the previous record are wrong: the ret < 0 test is on the path, and nothing overwrote the answer. What crossed the boundary was a positive number. kernel::error::Error is the kernel error code — from_errno(-2) == ENOENT, to_errno() is documented as "the kernel error code", and the API's own conversion of a Result to a C result, kernel::from_result, writes T::from(e.to_errno() as i16) with no negation, as every other driver in this tree does — and the driver negated it a second time. 38 call sites in cubelinux_store.rs were shaped -(e.to_errno()), so every refusal in this driver reported itself as a success to every caller that tests ret < 0.
  
  Why it became a loop in the space walk and only there: CUBE_OP_SPACES is the one arm that advances the cursor itself. Every other walk arm leaves the cursor where the caller put it, so a bogus return there ends the walk on the no-progress rule — which is why one defect stayed invisible at every other verb. Both halves are fixed: the 38 conversions return e.to_errno(), and that arm refuses a return that is neither 0 ("here is a space") nor negative (a refusal).
  
  Measured against the reproduction, in the guest, on the bench initramfs: cube_store=/dev/null cubelinux.enum=1 prints walk: spaces failed: Invalid argument, serves 0 records, and the boot finishes in 5 seconds — where it used to serve 364,994 invented record lines in the 90 seconds the instrument allowed it. A store whose device is not there at all answers "No such device" rather than the walk's own end signal, so a walk over a store on a disk with no driver cannot read as a walk over an empty store — which is exactly what that first benchmark boot was. The diagnostic prints the hunt needed are gone; the refusal is the return value. The three checks are verify-no-store on the wall now, and the same three inside the benchmark rehearsal, where they were warnings while the defect was open.
• A durable write that was not durable — and the first attribution of it was wrong (2026-09-23). Fixed in #96. verify-kernel-append asks the question a log exists to answer: four writes are acknowledged by the kernel, the VM is killed with SIGKILL with no shutdown at all, and the log must still hold them. §7 recorded it as a pass, and re-running the wall found it red. What this record first said about it was too broad, and the correction is the interesting part. The change between the passing kernel (18:41) and the failing ones is one commit — e0218ec96, "one fsync per append, not two", which writes the log entry with no flush and lets the control block's fsync carry it — and the entry's own flush is what was lost, so the collapse was named as the cause. It was not. The collapse is sound where the sentence it rests on is true, and that sentence assumes there is a control block to write.
  
  A store with no control block has no count to write, so nothing on the append path is flushed at all — and that is not an exotic shape: it is what a store the CLI builds looks like, and it is the shape the gate's own device has. Measured, same device, same four writes, the host's copy of the device read while the guest is still hung, on #95:
  
  no control block — the log region holds its header and zeros where the entry should be, the fold returns the base store (records=2), and four writes were acknowledged. a formatted device — the entry is on the device, and folding it reproduces the userspace store exactly: records=6, fnv1a64=6b679d39597a62b3, byte for byte. The pre-18:41-style kernel keeps the entry in both shapes, because the entry's own fsync is what made it durable there.
  
  So the fix is not the revert: append now takes the entry's own fsync exactly when no later write in the same operation will carry one — one boolean, and the two branches are the two shapes above. The box's store is a formatted file with a control block, so it keeps the measured win (4.96 ms), and the bare shape pays its entry's flush, which is what it always did. The gate was wrong in the same way the diagnosis was, and is fixed with it: it ran its crash check over one device shape, and it now runs it over both — a store with no control block and a formatted one — folding each the way userspace reads it and comparing both against the same userspace store. An acknowledged write that a crash can lose is not a tuning decision, and each shape's branch is now gated.
  
  What is still not measured, and is said rather than implied: the box's own store is a file on ext4, not a block device in a VM. The mechanism the fix relies on there — the control write's fsync flushing the entry beside it in the same file — is the one the formatted-device case measures, and ext4's fsync flushes the inode's own dirty data, so the reasoning is one step from the evidence rather than two. Nobody has killed this machine mid-write to prove it.
• Two gates that accused the kernel of what the box was doing (2026-09-23) — both found in the same wall run, both fixed. verify-enum-live reported "the kernel's walk is missing records userspace can see (2 of them)" against the running #87, a walk that was answering correctly. The two lines were space boot and a boot:0,0,0 record. The gate translates the names its userspace walk prints into the space ids the kernel prints, and its table had root, keystore, portal and edges but not boot — the name the CLI gives the space the kernel's own boot record is written into (0xFC). An untranslated name can never match, so the gate reported a correct answer as a missing record. It surfaced the day that record was folded into the image, because before that it was only in the log and userspace's listing of the image alone did not show it. The kernel was never wrong: it returns fcfc…:0,0,0 flags=0x0080 [219B], which is exactly the record the name stands for. One line in the gate's table, and the gate passes.
  
  verify-selfdestruct reported "the rehearsal changed the host" — and the change was cube.service serving this machine's live store while the rehearsal ran. The gate fingerprinted every file under /var/lib/cubelinux byte for byte, the store the running system is writing included, so any write during the two minutes the rehearsal takes read as damage. It passed on the next run, with nothing writing, which is not a fact about the rehearsal. The fix is the distinction the check was missing: keys and other files are still compared byte for byte, and a store is compared as a store — it must still decode, report no digest errors, and hold no fewer records than it did. That is what damage looks like, and it is immune to its owner's own writes. The rule was tested against all eight cases it can see (unchanged, grown, shrunken, erroring, gone, unreadable, and both directions of a first appearance) before it was trusted.

9. What the future holds

Said plainly, and separated into what is next, what is a decision, and what is not claimed:

Next

• Done 2026-09-25 — the boot record's guarantee, and its epoch. As this record was written, both gaps were in the record rather than in the switch: ensure_boot_record() claimed the boot before it attempted, so one transient failure cost that boot its record silently; and the epoch was whatever the clock said at the first write, which on this machine arrives from a night powered off 40 s out (10h 27m on the boot before that). Both are now built. The claim is a bounded retry that counts attempts rather than a swap that cannot un-claim itself, and the record now carries its own account of its epoch: uptime from the monotonic clock, so boot − uptime is when the boot began whatever the wall clock was doing, and clock=raw|set saying whether the reading predates a correction. The kernel rewrites the record at the next write when it observes the wall clock move without the monotonic clock — a clock correction and nothing else. Gated by verify-boot-record, which now moves the guest's clock forward an hour mid-boot and requires the same coordinate to come back rewritten with the corrected time; measured: boot=1790308025 uptime=3 clock=raw then boot=1790311625 uptime=3 clock=set, exactly the hour the guest moved. Kernel #97.
• Put the name tier on the same footing. Names, documents and the namespace protocol are a view at the edge; the sampler and its client were brought into the tree today so that the whole stack is built, gated and archived together rather than half of it living in a side workspace.
• Meet the realtime constraint. The design was re-weighted once already by robotics — the first whitepaper's §4.5 records that a control loop bounds latency in a way a data workload never does — and that is the integration this work is aimed at: DULRobotics.com. Nothing in this record claims that constraint is met yet; it is the requirement the order of the work above is chosen to serve.

Decisions, not open items

• The filesystem question is settled. The core interface is the coordinate syscall, not a mount; POSIX, where it is wanted, is an opt-in view at the edge — DESIGN-cube-interface §2 is titled "Why not a mountable filesystem".
• The write's durability is settled, and it is one fsync where a control block can carry it. A durable write is 4.96 ms measured on this metal, down from 8.2 ms, because e0218ec96 stopped flushing the log entry separately and let the count write — written next, to the same file — carry the flush for both. That was the trade this section used to reserve for the owner, and the owner's answer, on 2026-09-23, was to make it true rather than to take it back: the shape its sentence did not cover (a store with no control block, where the count write never happens and nothing on the append path was flushed at all) is fixed in #96, and an acknowledged write is now durable in both shapes, with the gate measuring both. The one fsync that remains is the price of the contract; group commit is how a future workload amortizes it across a batch, which makes it an optimization rather than a debt.
• The kill switch is built and rehearsed but deferred. Arming it is a terminal step the owner has put off to a later date, deliberately.

Not claimed

• The root filesystem is not coordinate-addressed. The store is; the root fs on this machine is ordinary, and addressing the root as coordinates is a separate question.
• The store is not yet proven at scale beyond this box. The numbers here are one live store of ~71,600 records (71,586 measured on 2026-09-25; ~70,400 when this section was written) plus gated fixtures; nothing in this record is a claim about a larger deployment.
• The gate on the doorway is built (2026-09-25); what is not claimed is that everything goes through it. The dongle has a space of its own (0xF9 ‖ SHA-256(serial)), an identity record in it, and a portal in the portal space entered from this machine's root — all of which the kernel's walk and the userspace decoder both find on the device. The cube-edge design (note 124.207.150.253) named the missing gate as its highest-leverage unbuilt piece. It is now built: Portal::reaches asks both halves — standing on the near mouth and arriving in the space the caller named — and cube-command's Session with execute_gated refuses a cross-space command with NoPortal naming both ends, before the store is touched. A connection may say stand to give up the owner's reach, after which it can only touch what it stands in or holds a portal into; the daemon and the front-end both run clients through that path. What is still not claimed: the check is userspace's, so a caller that talks to the kernel's cube(2) directly is not gated by it; a client that never says stand keeps the reach its transport gave it, which for this machine's 0600 socket is the store's own process; and no agent path has been scoped with it yet. Nor is a device a space of this store: the kernel serves one store at a time, so the dongle's space and this machine's spaces have not yet been made one address space by anything but the naming convention.

10. Checking this record yourself

Every claim above has a command behind it. On the machine that serves this site's store:

cube-image digest /var/lib/cubelinux/store.img    # version, records, errors
cube-image store-info /var/lib/cubelinux/store.img # generation, active slot, log used
kernel/run-all-gates.sh verify-enum-live.sh        # the box's own store, walked
cargo test --workspace --release                   # the workspace suite

The source is public: the tree, the database work and the kernel are three repositories under cubelinux.com/git — see the terms and register for access. The kernel repository is where cube(2) and the store live; the build line above names the commits that changed its shape. (2026-10-07: the git host is offline while it is moved off the one-core testbed, so the repositories are not browsable at this address today; access is granted on request.)