What happens when the model breaks something

This system has one address space, no user and kernel split, and no process isolation. A tool call from the model is a function call. So the usual answer to this question, that the model runs somewhere it cannot reach the kernel from, is unavailable here. There is nowhere else.

What exists instead is a set of gates, each in front of a different kind of mistake, and one repair tool that lives outside the thing it repairs. This page walks them in the order a failure would meet them.

What the model can reach at all

Every action the model takes goes through one table, sysbox::APPLETS, and the decoding grammar is built from that table. An applet absent from it is unspellable: there is no token sequence that names it, so the question of whether the model would be refused never arises.

That table holds filesystem verbs and two that read the network. It holds no way to write memory, no way to touch an I/O port, and no way to reach a device. The model can list a directory, read a file, write a file, take a snapshot, run a stored program, and fetch a page from an allowed source. That is the whole surface.

Each applet carries two independent bits, saying whether it changes persistent content and whether it sends a packet off the machine. Three trust levels select on them. Read-only admits neither, and it is what the machine runs at when it acts on its own initiative overnight. Online adds the network and still refuses every mutating applet. Full admits everything and is reached by typing the word in full.

A wrong step inside an episode

The model chooses an applet by decoding its name under the grammar, so an invalid choice is unreachable rather than caught. What remains is a valid choice that was the wrong one.

Arguments are validated before dispatch, and a refusal is an observation the model gets to read and react to. A step that reaches an applet and produces nothing is recorded as barren, which is a different thing from a refusal and is counted separately.

The sandbox verb runs a program and reports every object it touched, then puts the tree back. It saves each path's pre-image immediately before the write that would change it, so the cost is proportional to the change. It records the shallowest path that did not exist rather than the one asked for, because writing a file creates the directories above it and undoing only the named file would leave those behind and report success.

A program the model wrote

A successful episode can be compiled into a stored program under /ai/tools. Those run sandboxed in a subtree of their own, under a step budget, with the capability classes that apply to any stored program: reading values, reading state and writing inside its own subtree are allowed, and everything else needs the operator to name it.

Identity is the SHA-256 of the file, so editing a trusted program revokes its trust by construction. Nothing has to remember to re-check it.

Writing such a program is separate from adopting it. Four judges decide: it parses, it runs under the powers an unadopted program actually has, it does the same thing twice, and it is cheap. The third has a blind spot that is written down rather than discovered later, which is that it compares the value answered, the steps taken and the objects touched, and never what the program printed.

A change the machine made to itself

The nightly loop trains a variant, judges it, and adopts only on unanimity from four judges that each catch a different failure. A paired test over the same cached decisions, a replay of the machine's own goals along the baseline path, a structural check for finite factors and positive scales, and a cost check against the heap.

Adoption is a pointer swap. Every variant is a node, the parent stays addressed, and rolling back costs a pointer write. A line goes in the ledger for adoptions and refusals alike, so a night that changed nothing is as legible afterwards as one that did.

The held-out set carries a budget, counted in the ledger, because a loop that improves itself forever would otherwise read its own test set forever and report a figure that got more optimistic each time. Past three reads a test figure prints as stale and is marked unquotable.

Persistent state that is itself the problem

Once state survives a reboot, turning the machine off and on again stops helping, because the reboot faithfully restores the corruption. This is the case the rest of this page cannot cover, and it has its own console.

Hold ESC or R during boot. The recovery console is compiled into the boot image on the ESP, runs before any persistent state is restored, and depends on as little as it can: the disk driver, the store and the keyboard. It has its own line reader so that recovery does not depend on the interpreter, which is exactly the sort of dependency that stops working on the day it is needed.

l	list checkpoints, newest first
v	verify every chunk in every checkpoint
i	store and superblock detail
b	roll back one checkpoint
g <seq>	roll back to a specific sequence number
c	continue booting and restore state
s	continue booting without restoring anything

The last of those is the escape hatch for state that cannot be repaired: boot with none of it and look at the machine with a clear head. Storage is content addressed, so a checkpoint is a root hash and rolling back to an older one is cheap and exact. v walks the chain and says where it breaks, which tells you which checkpoint to roll back past.

A fault

Every interrupt vector except the breakpoint is fatal. A bad pointer halts the machine. There is no process to kill and no recovery from it, and the design says so plainly rather than implying otherwise.

What the machine owes you in that moment is an accurate report, and for a long time it did not give one. Printing writes the console first and the serial port second, and painting from inside an interrupt gate takes a fault of its own, so the first line of every report died before it reached the serial port. A person saw a machine that simply went quiet.

The report is written twice now, whole, serial before the console, because a serial write is a port write and cannot block or fault. A fault while reporting prints one line and halts rather than recursing. Where the fault happened is resolved against the image and against a registry of generated code, and an address in neither is described as being in neither, which is more useful than a plausible number that resolves to an unrelated function.

What the model cannot do

It cannot reach raw memory. No applet writes memory or touches a port, so the grammar cannot spell one. The language does have those operations, and a stored program asking for them is refused by the sandbox. The only route is a program the operator has explicitly trusted by hash.

It cannot replace the kernel. A boot image is adopted only if it carries a signature from a key compiled into the running kernel. The model has no access to the private half and no way to produce one. A hostile or wrong update source can deny service and can install nothing.

It cannot scribble the disk. Writes are locked by default, and unlocking names a range that is enforced on every write. A write starting inside the window and overrunning it is refused, and a length that would overflow does not wrap into a pass.

It cannot spend the night on the network. Unattended episodes run read-only, which excludes both network applets. Reading on the machine's own schedule is a separate switch, off until asked, and it does not raise the trust an unattended episode runs at.

What none of this covers

A trusted program can do what the operator granted it, and the grant is one bit. The reasoning is that a person approving a request has to hold the whole of it in their head, and "may write outside itself but not open sockets" is a sentence nobody can check against a program. The cost of that choice is that trust is coarse.

A fault before the boot image hands over is beyond every mechanism here, because nothing on the machine has had a turn yet. The recovery for that is the install medium, and no software scheme can do better.

Running out of stack in ring 0 with no guard page is a triple fault, which arrives as an instant reboot with nothing printed. Deep recursion in the interpreter is bounded by a depth cap for that reason.

And the model is a language model. The gates on this page bound what a mistake can reach. They do not make the machine correct, and no arrangement of them would.