The evaluation axis, a design scoping note

Set out in the architecture of a von Neumann machine, the thing being argued about stops being subtle. Such a machine is layered: hardware at the bottom, a kernel that owns it, a programming ABI through which everything above is compelled to ask, and a userland that lives above that boundary. A process does not reach into kernel memory and politely decline to abuse it. It cannot reach at all. It asks, and the asking is the ABI. Every guarantee the machine offers its users rests on that compulsion, not on the good conduct of programs.

In valis, the Lisp runtime is the operating system kernel. The work so far has been the definition of the low level atomic units, which is to say the kernel and its device drivers. The capability model is that machine's programming ABI: the interface through which every other party is compelled to ask, and the place where designation, rights, expiry and revocation are made to mean something.

⇒ Anyone who can load arbitrary code into the kernel of an operating system, without being forced through its programming ABI, owns all the authority there is to possess. This is not a risk assessment and not a claim about likely exploits. It follows by inference from where the code runs. There is no authority in the machine that is not reachable from inside the kernel, so a party evaluating there holds every bit of it at once, including the authority that would otherwise be used to constrain them, and including the ability to make their holding it unobservable.

Two consequences run through the rest of this note.

• A restricted evaluator is a category error, not a weak design. It is an attempt to make a kernel module loader safe by inspecting the module. The loader is the hazard; what is loaded is beside the point.
• Attenuation has no meaning at this layer, so designation carries the whole boundary. One cannot hold less of a kernel. One can only decide who is permitted to name the door, which is why the placement question in this note is treated as the entire security question rather than a detail of it.

The substrate already has a full capability system, and the obvious question is why the axis is not simply another grant handed out through it. The mechanism is worth stating precisely, because the answer turns on its details.

This is not a sketch. The mechanism is built, and the description below is of working code rather than of an intention.

Authority arrives in two layers. A peer authenticates its channel with a Noise_XX handshake, and the completed proof is converted, at a single named seam, into a principal that everything above the seam reads (src/identity/authenticator.lisp). Nothing above that seam knows what proof produced it, which is what lets a future proof be added without disturbing anything above. Note what the handshake actually establishes: it proves possession of a transport key, so the principal a wire session carries is the transport identity, not the owner's durable signing identity.

Authority over objects is then carried in capability tokens (src/capability/token.lisp): an issuer DID, an audience DID, mount grants pairing a namespace designation with a rights set, an expiry, a nonce, and an Ed25519 signature, with the proof chain back to the owner's root token riding inline so that verification needs no external store and works offline. The verifier (src/capability/verifier.lisp) walks that chain leaf to root and is fail closed: every condition raised during checking is returned as a refusal with a reason, never as an escaped condition. Each delegation link must satisfy three structural conditions, and a fourth gate applies across the link: the child's designation lies within the parent's designation subtree, the child's rights are a subset of the parent's, the parent itself carries the delegate right, and separately the child must not outlive the parent. Expiry and revocation are then checked on every token in the chain.

That machinery is sound and it is sufficient for everything it was built for. It is not sufficient for this, for three reasons that compound.

1. Three of the four conditions have nothing to bite on. Rights subsetting, expiry attenuation and re-delegation control all express "less than the parent". Evaluation has no "less than". There is no attenuated evaluation, because evaluation reaches the reader, load, every macro expander and the debugger. Only the second condition, designation, still does real work, which is why designation is where this design puts the boundary and why the axis must be a sibling of the publication axis rather than a child of it.
2. Evaluation runs beneath the layer that enforces the conditions. The four checks are performed by a verifier, and the verifier is code in the image. A grantee who can evaluate does not need to defeat the chain walk; they can redefine it, read the revocation store, or mint a root token directly. The guarantees hold for grants that operate through the model and say nothing about a grant that operates underneath it.
3. The exterior edge is part of what the axis exists to repair. Delegation over the terminus presumes a coherent instance: an edge that is listening, a capability layer that verifies, a namespace that mounts. The cases that motivate the axis are exactly the cases where one of those is the broken thing, or where an operator is still building an instance into the program they want. Authority is needed before the system that grants authority works, and a path that runs through the thing being repaired cannot repair it.

⇒ Points 1 and 2 say the ordinary path would not contain this authority even when it works. Point 3 says it is not available precisely when this authority is most needed. Neither is an argument for placing the axis outside the capability model, and the section on why the owner's reach is total explains why placing it outside would be the worse error. They are an argument that the axis is a different kind of object from every other grant, and must be designated, placed and reasoned about as one.

Those are different directions and they are not in tension. Confinement governs what the node may reach out to and what may reach in from the network. It does not govern what the person who owns the node may do with it, and it was never intended to. An enclave that also confined its owner would be a machine held against the person who runs it.

⛔ Confining the operator is the wrong problem, not a hard one. Sandboxing a Common Lisp system that someone has physical access to is not a difficult engineering task; it is a task that should not be attempted. It is their valis and their data, and they are entitled to break it. Whoever invokes a development listener keeps the shrapnel. Reaching a live image is an intended affordance of this system: the owner holding their own Lisp machine open at the code level is a goal, not a leak to be designed out.

honest frame

Host control is the foundation stone of the entire trust model. Everything above it assumes it. Whoever holds the machine already holds every key resident in memory, every capability the image can mint, and the image itself.

⇒ An owner reaching a live image over a loopback listener therefore gains no authority they did not already have. This is why the interim is ordinary machine access, ssh or another low level tunnel, and why that is sufficient rather than a compromise being tolerated: the operator is already on the host in order to run the node at all. The same reasoning scoped operator-facing node documentation to loopback, and the owner management port stays firewall closed until its credential legs are in place, with the local path serving in the meantime. The axis does not introduce this power. The power is already there, in the hands of whoever holds the machine, and the axis is the attempt to give it a name, an expiry, and a revocation instead of leaving it implicit.

⛔ The reasoning above holds only while reach requires already holding the host. A granted, network reachable evaluation capability is categorically unlike every neighbour it sits among. /active/zone-write grants a bounded operation on a known object. An evaluation grant is not one capability: it is the ability to mint every other one, to read the revocation store, and to revoke the revoker. It converts "possession of the machine", which is a fact that ends when the machine changes hands, into a transferable secret that outlives possession.

⚠ So the hazard is not today's binding and never was. It is the moment the axis becomes something a grantor can hand to someone who is not on the machine. That grant must be documented as a hazard where a grantor will see it, at the point of granting, and not in a source comment that only a maintainer reads.

A break-glass key compiled into the artifact was rejected for three reasons, and the deepest was that a thing sitting beside the capability model rather than inside it can never be hardened away: it acquires dependents, and then removing it is a breaking change rather than a decision. The axis is the same question wearing different clothes. Placed beside the model it would be a second authority, unrevocable in practice. Placed inside it, it is a grant like any other, and everything the model already knows how to do applies to it.

An owner who attaches receives the full canonical frame, and entries placed there by base policy carry no grant hash. Both eviction sweeps pass over such entries by design, so the only lever that removes one is a fence, and a fence takes the whole frame with it.

That is the exact defect the session fencing work existed to escape, reappearing on the most consequential surface in the system. Rejecting it is not a preference; a base-frame evaluation axis would be an authority that could be withdrawn only by withdrawing everything, which is another way of saying it could not be withdrawn in practice.

This shape is rejected for the same reason plus one more. It is still base policy, so it still carries no grant hash and ordinary revocation still cannot reach it. And a self-narrowing unmount is the session's own act: it gives the holder a way to drop the axis and gives the grantor no way to take it away. That is the wrong way round for an authority of this size.

⚠ Only a capability-backed axis makes "revocation reached the axis" available as evidence at all. A base-policy entry has no hash for a sweep to match, so there is nothing to observe and nothing to assert. The placement decision is therefore also a decision about what can ever be proven, which is the subject of a later section.

Each prohibition carries its reason, because a prohibition without one is a prohibition that gets argued away.

• It must not decide whether the caller may evaluate. That decision was made when the axis resolved into the session view. A re-check would be the first per-access guard in the tree, in a system whose entire enforcement model is that out-of-scope objects have no name, and a structural test exists specifically to catch one.
• It must not call the listener's own client authentication. Authentication already happened, cryptographically, at the attach. Calling it again would put a second and weaker gate in front of the real one.
• It must not bind a port, own a listener, or be reachable from a global. A bridge reachable from a global is a back door in the designation boundary, since the whole boundary is that nothing can name the axis without a grant.
• It must not filter, rewrite or inspect forms, for the reason given at the top of this note: the filter would resemble a boundary without being one, and its existence would invite reliance on it.

When	What is visible	Where it is produced
The grant was never minted	The walk of the axis path fails as though the name never existed, because in an unaugmented view it does not	the namespace assembler, existing behaviour
The grant was minted but never presented	Identical, because the second phase runs only when a capability is written to the control door	the namespace assembler
The grant was revoked before the attach	A refusal carrying a reason string from the verifier. Every verifier path is fail-closed and returns a reason rather than signalling	the capability verifier, through the mount path
The grant was revoked mid-session	The mount entry is removed from the live view, so a new walk fails. A handle already open below it does not fail, which is the transport gap named above	the live-view eviction sweep
The session was fenced	The same visible effect, wider: every mount goes, base policy included	the session fence
The session went idle past its bound	Identical to a fence, produced lazily by the operation that would have used the view	the activity mark, checked on the next operation
An evaluation was interrupted	An error naming the interruption, on the flushed request	the 9P flush handler

⚠ The wire carries an error name and nothing else. A bridge that responds to any of the mid-session rows by simply closing its loopback socket gives the person at the editor "connection closed" and no reason at all, and a contract nothing reads is not a contract. Whether the error name reaches the developer, and by what route, is left undecided here.

No evidence available establishes that no path in an image of this size reaches evaluation under some other name. Evaluation is reachable from the reader, from loading, from every macro expander and from the debugger, and an image that could not evaluate could not have been built.

The honest scope of any claim made here is therefore over the designated path: the axis is the only path that offers evaluation as a service to a party outside the image, and everything else that can evaluate is already inside the trust boundary because it is the image itself. That is a real and useful property. A broader claim would be false, and a reader who caught the broader claim would be right to distrust the narrow one too.

Recorded now because it governs the userland direction and is not answered by anything above. The argument here is about the owner's reach, where the claim that possession already confers everything holds. It does not transfer to a second party.

A Common Lisp image loads every form at the same authority. Packages are an organisational device and not a boundary, the reader reaches evaluation, and the standard library supplies ambient authority in every direction. So the property recorded elsewhere in this system, that a module acts only on capabilities designated to it and holds no ambient authority, is today a discipline observed by the code in this tree. It is not enforced by the runtime, and it does not survive code from anywhere else. Designation decides who may reach the door; it decides nothing about what happens on the other side of it.

⇒ The goal of a person running their own code on their own instance therefore collides with the single authority of the runtime the moment that person is not the owner.

ANSWERED, and not by placement. A second party is given a second instance, never a confined region of the first. An instance that executes but holds no data has an execution context total over itself that confers exactly its outward reach, and that reach is capability-mediated 9P to the instances that do hold the data. The attenuation happens at that boundary, never at the evaluation boundary. The decision of record is Two planes of authority, and why the system is a federation of instances.

⚠ The guesses recorded here before that decision were isolation and a hosted evaluator with no ambient authority. Both attempt to manufacture a second context inside one image, which is why neither settled. Kept because the reasoning that rejected them is the reasoning that found the answer.

The transport half of this is solved: a parked read can be cancelled and its request answered. An evaluation genuinely running on a worker thread is not a parked read, and the transport cannot reach it. The evaluation protocol carries its own interrupt machinery, but it is thread-directed rather than transport-directed, so reaching it means this substrate reaching into that protocol's internals for a second reason. The trade is between an authority that ends immediately and a dependency on internals that is already uncomfortable at three symbols.

Decided 2026-07-29: every valis node carries the listener, and it must be possible to turn off.

The shape the ruling takes. valis/delivery depends on slynk; the resident starts a listener only when VALIS_SLYNK_PORT names a port, so leaving it unset is both the off switch and the default; the resident names no host at all and so takes loopback, while the single entry both it and the --dev path go through refuses a routable host rather than binding it; and tests/dev-slynk-test.lisp covers it. This is the loopback listener referred to elsewhere in this document.

⛔ It is not the axis, and the resemblance is the trap. An environment variable read at boot is an ambient switch reached from the host. It carries no grant hash, revocation does not reach it, and it cannot be withheld from a delegate. The evidence list above names this exact condition as an outstanding gap, at item 5. ⇒ This ruling settles the listener and nothing about the axis.

The reasoning that makes this consistent with the rest of this document: a node that cannot be reached is a node that cannot be updated while running, and being updatable while running is the reason the system is written in Lisp at all. An absence guarantee bought that property away on every node in order to hold it on none.

Presence is not access, and that separation is the design. The listener being compiled in does not make it reachable. It listens only when configured to, and what governs reaching it is the capability grant this document already settled, never the question of whether the code is in the image.

⛔ The question as posed below is malformed, and it is kept because the reasoning under it is still worth reading, not because either option is live. Both limbs sit in the vocabulary of ordinary capability delegation, whose central promise is that a child grant is a subset of its parent. Evaluation has no subset: once a party can evaluate in a context they hold everything in that context by definition, so a restricted evaluator resembles a boundary without being one.

⇒ The axis grants a CONTEXT, not a right. The confinement this substrate applies is outward: it governs what a node may reach, never what the party holding that node may do inside it. The decision of record is Two planes of authority, and why the system is a federation of instances.

⚠ The parser point below survives the answer. No new bit is being added, so the control door's four-right parser is not part of this choice any more, but an owner who can mint a grant from an evaluation prompt but not through the file interface still has the discipline inverted.

The original question, kept for its reasoning:

⛔ This asked how the axis is registered in the NAMESPACE manifest, and the axis does not belong there. Module registration is a separate mechanism. It already exists in this tree, and it has the shape the namespace-manifest framing treated as absent.

A module is designated by its content rather than by a name in a frame. The admission predicate in valis/src/plugin/module-admission.lisp asks a single question: does an owner-rooted, unrevoked, unfenced authority grant :admit over exactly this /module/<64-hex-score>? The designation is nothing but that content: a 32-byte score over the module's own sources, rendered as hex. It therefore carries the grant's authority without appearing in any frame, and there is no base-policy entry for a sweep to miss.

⇒ The placement decision is met with no manifest entry at all. Admission is a chokepoint in front of the loader, and it has to be: loading a module is its self-registration, so there is no later point at which a refusal could still take effect.

⚠ What this does and does not retract. The reasoning in Rejected: a canonical axis in the owner's base frame is about the namespace manifest and does not extend to module registration. The base-policy argument under The consequence that makes the decision worth writing down is untouched and still holds.