ROOTFRAME: a verifiable runtime for autonomous agents

For decades a program’s behaviour was a function of its text: when it failed, someone could read the code and find the cause. Autonomous, probabilistic agents break that. When a language model chooses what to do, behaviour is no longer a property you can read off the source, and three things quietly disappear: explicit control, traceability, and independent verification. ROOTFRAME exists to keep those three while still using probabilistic reasoning where it genuinely helps.

The line that governs its design is deliberately narrow: the model perceives, a deterministic engine decides, and the runtime coordinates. The model is used strictly as a sensor — it receives unstructured input and returns typed facts under a forced schema at temperature zero. It does not choose goals, does not choose plans, and does not authorize actions. Everything that decides is deterministic: given the same state, it decides the same thing.

The core idea is that an autonomous system has five distinct responsibilities, and the temptation of the moment is to put all five inside one model. ROOTFRAME keeps them separate, each held by a different component:

Why it matters is concrete, not philosophical: if one component both produces an answer and judges whether the answer is good, verification is no longer independent of the thing verified — it is self-assessment, and the self-assessment of a stochastic process inherits its fallibility. Separating the five is what makes verification mean something.

ROOTFRAME organises its agents as a holarchy. A holon, in Koestler’s sense, is at once a whole and a part — like a cell that has its own membrane and logic yet is part of a tissue. The useful engineering property is that local autonomy and global coordination are not a trade-off to balance but distinct levels that coexist: the decision sits where the information is, and the constraint sits where the responsibility is.

Autonomy

A holon decides within its scope without consulting the level above; otherwise it would be a remote procedure call under another name.

Composition

A holon can be part of another, and the composite is also a holon — the same machinery serves a component and a whole system.

Constraint from above

The upper level does not say what to do; it says what may not be done. In software that is the difference between calling a function and checking a precondition.

Holons do not call each other; they coordinate by reading and writing shared state. That turns a messaging problem into a consistency problem, bounds the communication surface, and makes emergence deliberate — a pattern no single holon sees appears in the shared state, where another can observe it.

Agents are declared, not programmed, and they reason with an explicit Belief–Desire–Intention model. The decision engine is a pure function of the current state: the same beliefs and goals always select the same intention, which is why a run can be replayed and audited. Before any plan runs, a deterministic authority gate checks it against an explicit allowlist and refuses by default — security precedes usefulness, so a candidate action is authorized first and only then ranked by how much it would teach.

Verification is separate again. Facts entering from the model cross an input membrane; effects produced by execution are checked by independent verifiers before anything is accepted as true. A belief’s origin gates what it is allowed to become: a statement a model produced can be a proposal, never a confirmed observation.

This is the same discipline the rest of ROOTVIEL is built on — the evidence-first cognitive cycle, the propose-only seam, and PROVEN / NOT PROVEN / UNKNOWN kept distinct — shown here at the level of the runtime those ideas run on.

ROOTFRAME is described here from an internal architectural reconstruction written by reading the code rather than prior documentation. It classifies every capability with an explicit status — implemented, pinned by a test, experimental, deliberately written-but-unwired, or simply not established by reading — and the mapping onto this site is direct: implemented-and-tested is PROVEN of a property under its assumptions; written-but-unwired or unestablished is UNKNOWN.