The epistemology of fully connected symbolic computers

This is the historical design record of a question that shaped valis at its foundation: what a symbolic computer can know, and enforce, about who is acting on it, once that computer is permanently connected to a hostile network.

It exists because the answer is not obvious and is easy to mistake for something simpler than it is. A maintainer who understands only the mechanism will eventually propose a change that the mechanism permits and the reasoning forbids.

⚠ This document does not supersede anything. Two living documents carry the operational statements and continue to evolve:

• docs/REPL-AXIS.org holds the design of the evaluation axis: the placement decision, the shapes rejected and why, the transport obligations, and the questions still open. Its section The hierarchy, in the classical terms is the primary statement of the argument recounted here.
• docs/ARCHITECTURE.org holds the architecture of record, including Two planes of authority, and why the system is a federation of instances, and the capability model this reasoning acts upon.

⚠ REPL-AXIS.org carries its own status line marking it a draft for review. That applies to the axis proposal it contains, not to the classical framing this document draws on, which is settled and long committed.

Where those disagree with this document, they win: they are maintained against the code, and this one is a record of how the position was reached. What this adds is the reasoning around the resolution, the constraints that produced it, and the consequences a maintainer needs in order to judge a new proposal.

⚠ A note on two words used throughout. The operator is the person who runs an instance and holds its execution context. Owner appears only where the substrate's own vocabulary uses it, for the principal an application attaches as. They are the same person; the two words are not two roles.

A symbolic computer of the Lisp lineage is defined by a property that distinguishes it from most machines people now use: the running system is modifiable by the person operating it, at the level of the code, without stopping. That property is the reason such a machine is worth building. It is also the reason this question is hard.

The machines of that lineage sat on desks and were reached by the person sitting at them. The question of an anonymous remote party did not arise for them as an operating condition, whatever their designs may have contemplated.

⚠ That is an argument from circumstance, not from the literature. REPL-AXIS.org records that the lineage has not been read for this question, and withdraws an earlier impression of what it says on precisely these grounds. No claim about what those designs concluded is made here, and none should be inferred.

A modern instance is permanently reachable by an anonymous, adversarial, global network. The property that makes the machine worth building is now also the most consequential surface it exposes. The question this document records is how to keep that property without exposing it to the network.

The argument becomes tractable when the machine is described in the layering every general-purpose computer already has. This framing is stated fully in REPL-AXIS.org and is summarised here because everything downstream depends on it.

A von Neumann machine is layered: hardware at the bottom; a kernel that owns it; a programming interface through which everything above is compelled to ask; and a userland 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 interface. Every guarantee the machine offers rests on that compulsion, not on the good conduct of the programs running on it.

Mapped onto valis:

• The Lisp runtime is the kernel. The work of building the substrate has been the definition of its low level units, which is to say the kernel and its device drivers.
• The capability model is the programming interface. It is where designation, rights, expiry and revocation are made to mean something, and it is what every party other than the operator is compelled to ask through.
• Service modules and clients are userland. They act on capabilities designated to them and hold no ambient authority.

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

The tempting response is to permit a restricted evaluation: a safe subset, an audited language, a sandbox, a package boundary. Each of these was considered. None of them holds, and the reason is structural rather than a matter of implementation quality.

A Common Lisp image loads every form at the same authority. Packages are an organisational device and not a boundary. The reader reaches evaluation. The standard library supplies ambient authority in every direction. Evaluation reaches load, every macro expander, the debugger, the capability layer itself, and any key resident in memory. An image that could not evaluate could not have been built.

⛔ A restricted evaluator is therefore a category error rather than 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.

⚠ This is worth stating flatly because it will be proposed again. It is the first idea a capable engineer has on meeting the problem, it sounds tractable, and a partial implementation appears to work. The property it fails to deliver is not caught by testing, because nothing about a sandbox that leaks announces itself.

If evaluation cannot be attenuated, then evaluation is the wrong object to attenuate. The object to bound is the context.

The substrate already applies confinement in this direction, and it is worth being precise about which direction that is. Confinement is outward: it governs what a node may reach and what may reach it. It does not govern what the party holding that node may do inside it, and it was never intended to. A node that confined its own operator would be a machine held against the person running it, which is the opposite of the project's purpose.

Applied to one instance, this is a statement about firewalls and namespaces. Applied across instances, it is the answer to the question this document poses.

An instance that executes but holds no data has a context that is total over itself and confers exactly its outward reach. That reach is capability-mediated 9P to the instances that do hold the data. Those mounts attenuate exactly as the capability model describes: each carries a grant hash, revocation actively evicts it, an expiry applies, and a read-only grant is wrapped so that the write operation has no name at all.

⇒ The attenuation happens at the 9P boundary, never at the evaluation boundary. A party holds complete authority over a context that holds nothing, and reaches the operator's data only through grants the operator can withdraw. Holding that context was never the same as holding the data.

The shape intended for an operator's own tools is the side-car: a local valis instance that an owner-facing application boots and attaches to as owner, whose namespace is then composed with a remote instance by mounting a capability into its view.

The design notes are in the ubik repository, as docs/SIDE-CAR-CONCEPT.org, recorded there as a deferred work item with the boot mode itself still on its list of what is missing. Read them for the mechanism. They frame the side-car in terms of latency, offline resilience, and namespace composition, all of which are true and useful. This document records the security-architectural reason the same construct is the general answer: the side-car holds the execution context, the remote instance holds the data, and the only path between them is a capability the operator can withdraw.

⚠ A side-car is an execution context, so its authority needs an anchor of its own. The ubik notes record key custody for the side-car as open, including the option of an ungated local-only boot. This argument rules against that option: it would rest the most consequential authority in the arrangement on nothing.

Two distinct things travel between cooperating instances, and conflating them is the most likely future design error in this area.

• Capability-mediated namespace access. An instance mounts a subtree of another instance by presenting a grant. This is the only data path the design admits: no privileged side-channel, no direct socket that bypasses it. ⚠ The mount primitive exists and resolves designations locally; carrying a mount across an instance boundary is not yet built, and the ubik notes record how it should reach a remote instance as an open question.
• Attestations. Administration and service installation are intended to be mediated by consensus over material signed by other instances holding operator authority, including instances a vendor maintains for the benefit of its clients.

⛔ What crosses is an attestation that an artifact is legitimate. What never crosses is access to the context that installs the artifact. Consensus supplies trust in the thing installed, never a route into the machine installing it. The local execution context remains the only thing that applies it.

⚠ The seam for the second already exists: module admission runs through a content hash plus an operator vouch carrying the :admit right. Federating administration changes the signer of that vouch from the operator alone to a quorum, and requires no new mechanism. This is also why :admit belongs with the execution context rather than with the data rights it is currently listed beside.

Authority divides into two planes, and only one of them is described by the rights vocabulary: the data plane, which is reading and editing projections of the operator's data, and the execution context, which is loading code, installing a service, and changing what the node is.

⇒ The statement of record is Two planes of authority, and why the system is a federation of instances, and it is not reproduced here. A copy would become a competing version the moment that section is edited, with nothing to link the two.

The consequence worth carrying into any design discussion is short: a question of the form "which right is evaluation" is malformed. Neither an existing right nor a new one can carry it, because both would enter a vocabulary whose central promise is that a child grant is a subset of its parent, while meaning every right at once plus the power to mint more.

The reasoning above is not only a constraint to respect. It describes a destination, and work should be designed toward it rather than merely kept compatible with it.

⚠ Marked plainly, because the layers below differ both in what commits the system to them and in how much of each exists. Layers one and three are what the argument above commits the system to. Layers two and four are what the project's purpose commits it to, and the argument constrains their shape rather than producing them.

⛔ What is built, and the era it is built in. This is pre-release founding development. One instance holding one whole execution context for one operator is built. A second instance cooperating with it is not: the mount primitive resolves a verified designation against the local assembler root, so carrying a mount across an instance boundary does not exist yet. Everything below describes where the design is going, not where it is. ⚠ Do not read the ordering as a schedule. Nothing here is sequenced.

This section exists so a maintainer can place a new project without re-deriving the argument.

Recorded plainly, because a design record that lists only benefits is not one.

• An absence guarantee became a gate guarantee. Every node now carries the development listener, which is strictly harder to prove than a binary that never contained it. A gate is worth what its tests are worth, and it must hold on every node rather than on one build flavour.
• Plural instances cost real resources. Federation is not free, and an arrangement that would have been one process is now several with a network between them.
• The honest scope of any claim is over the designated path. No evidence available establishes that no path in an image of this size reaches evaluation under some other name. What can be claimed is that the axis is the only path offering evaluation as a service to a party outside the image, and that everything else able to evaluate is already inside the trust boundary because it is the image itself. A broader claim would be false, and a reader who caught it would be right to distrust the narrow one too.
• A state actor holding the hardware wins. This is stated in the research record and is not softened here. The achievable goal is detection and key destruction, not defence at that level.

These are recorded as open and should not be read as leaning. The live versions are in REPL-AXIS.org.

• Whether revocation must interrupt an evaluation already running or only prevent the next one.
• How a recovery quorum is discovered without the discovery itself being the disclosure.
• The minimum coherent state at which a node can verify an operator key and serve a small control surface. A low floor shrinks the window that needs bootstrap authority at all, and shrinking that window is a better answer than adding a second authority to cover it.

Withdrawn since this list was written: the question of how the durable form of the axis is registered was posed against the namespace manifest, where the axis does not belong. Module registration is a separate mechanism, in which a module is designated by a content score rather than by a name in a frame. It is recorded as withdrawn rather than answered, because the question does not arise in that form. The reasoning is in REPL-AXIS.org.

The property worth protecting is unchanged and undiluted: a machine its operator can reach into and change while it runs. For the operator of an instance that property is total, and confining them was never attempted, because it is the wrong problem rather than a hard one.

What the resolution spends is plurality. Each operator gets a whole machine, reachable by them completely, and reaching anyone else only by permission that can be withdrawn.

🄯 Brian O'Reilly <fade@deepsky.com>, 2026