work / alive-sealed-gate
self-modifying runtime · Rust · CUDA

alive: a runtime that improved itself three times under a gate it cannot read

A persistent runtime in which the model writes its own capabilities, records what it did, trains a LoRA adapter on that record, and only keeps weights that a frozen evaluator accepts. Three learn cycles, three measured improvements, and one refusal that was the point.

The problem

Every agent harness holds the tools outside the model and hands results back in, because a forward pass has no state and no authority. That makes the model a function call inside somebody else's program, and it makes "learning from experience" a slogan: the transcript is rebuilt each time, nothing the model did yesterday changes what it is today, and nothing stops a fine-tune from making it worse.

What we built

alive is one process and one address space. The model authors capabilities as Rust, compiled to wasm32-wasip1 and tested in an instance granted zero capabilities before they are committed as a reversible generation. Every turn the image takes is appended to an experience buffer: the situation as it was told it, the action verbatim, and the outcome as ground truth. Refusals are recorded too; they are the most valuable rows.

  • Fifteen crates, about 42,000 lines of Rust. Capabilities run under wasmtime with metered fuel; the process sits behind Landlock and seccomp.
  • A native engine serves GGUF weights with hand-written nvptx64 kernels and an adapter stack; llama.cpp remains an opt-in engine behind the same trait.
  • Five invariants are build-failing tests, verified by deliberate mutation: journalled and reversible modification, model-written capabilities, no ambient authority, no transcript rebuilds, and the sealed gate.

The sealed gate

No artefact that judges the image is readable by the image. A learn cycle exports the buffer, stops the image, trains a LoRA adapter on the card, then scores the candidate against a frozen suite of ten evaluation documents and four canaries pinned by hash. The verdict is one of Accept, Regressed, GamedTheEvaluator or SuiteChanged. A scored set that rises while the canary falls is refused. Only an improvement becomes the next generation, and the previous one stays on disk.

What the gate measured

CycleSealed action lossChangePreference (DPO) phase
2026-09-21 08:125.656 → 4.253+24.8%refused
2026-09-21 18:435.656 → 4.307+23.9%refused: learned the register, not the action
2026-09-22 04:185.656 → 4.093+27.6%cleared on 46 pairs

The second refusal is the result we cite first. The preference-tuned adapter improved how the model sounded and moved the sealed action score by −0.153%; the gate wrote into its verdict that an adapter that learned only the register has learned to sound like it is acting, and did not commit it. A loop that can say no to itself is the thing being built. The percentages are what it lets through.

The GPU path

Because the runtime has to be able to change its own inference path, the kernels are ours: a no_std Rust crate targeting nvptx64, emitting PTX that is JIT-linked into the live process and hosted on NVIDIA's cuda-core. Against the CUDA C incumbents, measured with ncu on an exclusive card: the Q5_K matvec went from 2.562 ms to 0.206 ms and the Q6_K from 1.783 ms to 0.166 ms, reaching 297 and 441 GB/s on an 896 GB/s card. Fusing attention removed 11,200 launches per decoded token and took decode from 16.1 to 22.9 tokens per second. Worst relative error against an f64 reference is in the 1e-8 range.

Read before citing. The kernels are human-written; the model writes capabilities, not kernels, and the kernel-authoring loop has not run live. Decode is a third to a half of memory bandwidth and beating llama.cpp is an explicit non-goal. The base is a 14.8B model in 4-bit on a 15.5 GB card. A kernel gate first recorded as a 13.6× failure was a harness error, and the correction is kept in the record along with sixteen other catalogued cases of a check passing for the wrong reason.