valis - Architecture

The steering program is compiled by Whistler, a Common Lisp s-expression → eBPF → ELF compiler with a pure-CL loader (no libbpf, no clang, no bpftool). Keeping the kernel-facing layer in Lisp is the Lisp-Machine thesis applied to the substrate itself: the owner reads and reshapes the steering logic in the same language as everything above it.

sk_lookup support and a catch-all redirector were validated end to end on Linux 7.0: compiled, accepted by the kernel verifier, and attached to a network namespace through the pure-CL loader. Minimal shape:

(defmap redir-sockmap :type :sockmap :key-size 4 :value-size 8 :max-entries 1)

(defprog catch-all (:type :sk-lookup :section "sk_lookup" :license "GPL")
  (when-let ((sk (map-lookup redir-sockmap 0)))
    (sk-assign (ctx-ptr) sk 0)
    (sk-release sk))          ; mandatory: see invariant below
  SK_PASS)

Invariants worth remembering:

• A sockmap lookup in sk_lookup context returns a reference-counted socket; the program must sk-release it before exit or the verifier rejects it with "unreleased reference."
• Two kernel constants that are easy to confuse: program type SK_LOOKUP = 30, attach type BPF_SK_LOOKUP = 36.

The Whistler additions are upstream (atgreen/whistler#43), so a stock Whistler carries them.

Everything in this section follows from a single constraint: the event-dispatch thread must never block. Stalling inside a readiness callback stalls every other source on the loop, so any protocol that can block must be run off it.

src/listener.lisp holds the one backend-selection point: *default-multiplexer-factory* names the epoll multiplexer, and nothing else in the tree chooses a backend. Swapping in a different one is a change to that variable, not a change to any protocol.

src/executor.lisp is the indirection that keeps the loop free. The executor's dispatch-connection generic schedules an accepted connection onto whatever execution context the executor manages, and returns at once.

Three strategies exist in the tree, and which one a port gets is a property of the transport rather than of the protocol:

• Every bound edge port builds a budget executor. It is a thread per accepted connection with a per-port concurrent-connection cap: the cap-th accept deregisters the port's listening source, so further connections wait in the kernel backlog rather than being accepted and closed, and a slot freeing re-registers it. The default cap is 64 connections per port.
• The connectionless datagram path takes an inline executor, which spawns nothing and runs the exchange on the loop thread itself. A datagram arrives whole, so there is nothing to block on, and spawning per datagram would hand an off-path packet flood an unbounded thread-creation lever.
• A bare thread per connection, with no budget, is the third and is what the other two are variations on.

All three sit behind the one generic, so a pooled or coroutine executor is a further subclass and the swap touches neither the multiplexer nor any protocol handler.

A protocol may instead declare :raw-descriptor stream discipline, in which case its connections are driven from the loop itself through the session callbacks rather than handed to the executor. This is what makes long-lived protocols affordable: a connected but idle session costs no thread at all, so concurrency scales with the number of active clients and never with the number of connected ones. Sizing for such a protocol is therefore against a rate of activity rather than a count of peers. The connection-lifetime assumptions measure that claim, at zero OS threads and a few kilobytes retained per idle session.

Two boundaries govern that declaration:

• An adapter that wraps or terminates the stream cannot honestly declare raw discipline, because the descriptor beneath it carries ciphertext while the wrapper holds the bytes the protocol wants. A terminating edge therefore keeps the thread shape. Driving a continuous protocol over a terminated port from the loop is unresolved: termination hands back a blocking stream bound to a thread, so such a session costs a thread even while idle. That question gates continuous protocols over TLS, and owner mail access with them.

• A protocol that needs to make blocking calls while serving a session, such as a namespace round trip, must still get off the loop to make them. Connection dispatch cannot carry those workers. Its unit is a whole connection lifetime: it is keyed on a port an adopted session has already resolved, it reaches the protocol through the registry's handle-connection, which a session-driven protocol no longer defines, and where a strategy owns that lifetime it closes the connection when the work returns. A per-session worker runs many times over one session, so the first one to return would tear the session down.

  Neither entry point covers work that is not a whole connection lifetime, such as a per-session worker or a timer body. A task-level dispatch that takes a thunk, owns no lifecycle and closes nothing is owed here; connection dispatch is expressible on top of it. Until it exists, each protocol spawns its own threads, and the choice between unbounded workers and a bounded pool is settled independently in each one. The two are not interchangeable: a pool smaller than the simultaneously-active set couples clients whose latency is independent today.

Wire descriptors reach a running node two ways. The distinction is in how a descriptor arrives, never between kinds of node:

• Inherited. The privileged host agent binds a port outside the node and passes the descriptor in. The reason is privilege rather than protocol: valis runs unprivileged in its namespace, so a port it may not bind is bound for it and handed down before privilege is dropped. Four things arrive this way (src/main.lisp): :443 for the public TLS edge, :80 for the documentation every node serves in the clear, :53 on both transports for authoritative DNS, and the routable owner terminus on whatever port the agent's config names. Three of those are TCP streams, and the steer is perfectly capable of carrying them. Only a UDP reply must source from the socket the client addressed, which is why UDP is the one transport that has to be inherited to work at all; the two DNS arrival paths sets that out, along with what it costs that :53 is split across both arrivals. Of the four, :80 is the arrival the code has not grown into: the resident parses its descriptor as --edge-http-fd and hands it to no adapter, so a node inherits the port and answers nothing on it. What :80 is for states the design; TODO.org carries where the code stands.
• Declared and pushed. The node mints a listening descriptor and hands a duplicate to the privileged agent over the existing control connection, which is what lets the agent steer every port onto that one socket. The push direction is the property that makes the arrangement safe, and the steered-fd handoff sets out why. Note separately, at the per-namespace steering constraint, that a declaration does not by itself bound the answered set on a routable address: the agent's default-deny firewall is what narrows it.

These compose: a node inherits the descriptors the agent bound for it and declares a port of its own, and a launch may use either arrival, both, or neither. A boot declares at most one port today, since src/main.lisp refuses a --ports set carrying more than one, so "declaring for everything else" is a shape the model allows and the code has not yet grown into. Declaring stays default-closed, so a launch that only inherits behaves as it always did.

They did not compose until recently. The boot shape that adopts inherited :53 descriptors never declared its socket to the agent, so on a node booted that way nothing entered the steering map and no other port was reachable regardless of what the firewall admitted. That was a defect in the code rather than a second kind of node.

The invariant the fix must restore: authoritative DNS is a service in the :names group and nothing more. It is not a mode the node runs in, and its presence must never suppress the general arrival path for other protocols. What that protects is a node routing an arbitrary number of protocols, the surfaces at the edge/core seam and others as they are adopted. Naming none of the others here is deliberate: the model must not need to know them. If adding a protocol requires a new branch in the boot path, the model has been drawn wrongly and the exception has been allowed to suppress the rule.

The connect-time authenticator for a 9P-native peer is a Noise Protocol Framework handshake in the Noise_{XX25519ChaChaPolySHA256} pattern. XX is mutually authenticating without pre-shared knowledge: neither party needs the other's static public key in advance, and both recover the other's key during the exchange. That symmetry is what lets a fresh peer dial a fresh valis and walk away with a did:key for each other: no directory, no out-of-band setup.

The exchange is three messages and binds every byte into the same transcript. The initiator opens with an ephemeral X25519 public key in the clear. The responder answers with its own ephemeral and its static public key, the static encrypted under a key derived from the running transcript; the message ends with an authenticator (an AEAD of the empty string under the same key) that proves the responder also derived the same transcript. The initiator's third message carries its static the same way, again followed by an authenticator. Each derivation step folds the latest DH output into the chaining key, and every emitted byte is folded into the transcript hash, so a single bit-flip anywhere in the conversation breaks the next decryption. After the third message a Split derives two asymmetric transport CipherStates (one for each direction) that a post-handshake transport layer would use; valis's current use ends at admission and does not exercise transport-mode encryption.

Mutual authentication here means a key recovery, not a key challenge: the responder reads the initiator's static out of the third message and publishes it to the rest of the system as a principal. There is no separate "prove you hold this key" step, because the AEAD authenticator on the message a party encrypted with the keys derived from its own static is the proof; impersonating a key requires possessing it.

The cipher behind every encrypted token is RFC 8439 AEAD_{CHACHA20POLY1305} with the IETF 96-bit nonce shape (four zero bytes followed by the counter as little-endian uint64) and the running transcript hash as additional data. The AEAD wrapper has its own RFC 8439 §2.8.2 known-answer test, so the cryptographic primitive is anchored before the protocol that uses it.

The state machine and seven-compatible auth node are in src/identity/noise.lisp; the AEAD wrapper is in src/identity/aead.lisp. See the Noise Protocol Framework entry in the Bibliography.

The factotum is mounted at /id and is itself a 9P file tree, faithful in shape to Plan 9's factotum(4) (src/namespace/id.lisp). It exposes three children:

• /id/ctl - key management: a Tread renders the owner's key descriptors, a Twrite carries control verbs. The interface deliberately mirrors factotum(4) so an operator (or a local module) drives it the way they would drive Plan 9's.
• /id/rpc - the auth-conversation endpoint. Every open of /id/rpc mints a fresh conversation object holding its own auth node, so two concurrent callers cannot share state through it. The rpc surface is a generic auth-protocol multiplexer, not Noise-specific: its first message may carry a proto-selection line, and the endpoint really dispatches on it, building the Noise responder for noise or the challenge driver for ssh-reality, with noise the default when a caller begins its handshake without selecting. It is the factotum's mechanism for driving whichever proof the caller wants, and the seam a further authenticator plugs into by becoming one more dispatch arm.
• /id/proto - a list of authenticator names available behind /id/rpc, one per line. It now advertises both noise and ssh-reality. An architect or an auditor reads it to see which proofs this image admits without opening source.

The same machinery serves a remote 9P peer through seven's auth seam. A Tauth against the root binds the afid to a fresh Noise auth node by way of the node-auth method on valis-root (src/namespace/root.lisp). Subsequent Twrite and Tread operations on that afid pump the three XX messages through seven's "dumb pipe" auth carrier: seven never inspects the bytes; it carries them between the peer and the node, and parks reads until a write completes so the challenge-response ordering is correct. When the third message lands and the node-auth predicate (node-auth-ok-p) reports completion, seven calls node-attach-identity on valis-root with the approved auth node; the specialiser returns the keyed principal the Noise responder resolved from the peer's static public key, and seven records that return verbatim on the live 9P session before admitting the Tattach.

Two paths (a remote afid and a local open of /id/rpc) exercise the same Noise auth node class. The symmetry is the whole point: a local module driving the factotum and a remote peer attaching through it authenticate against the same code.

See the factotum(4) entry in the Bibliography.

Once a proof completes, it has to become something the rest of valis can read. That conversion is a single named operation: the authenticate generic function in src/identity/authenticator.lisp. Everything above the seam (the connection layer, the capability layer, the namespace mounter) only ever sees a principal; only the code below the seam knows what proof produced it.

Noise_XX is the first method on this seam (noise-authenticator); anonymous-authenticator is the second. Adding a future proof (an HTTP-edge signature authenticator, for example) means writing a new class that specialises authenticate to mint the same principal type from a different proof. No code above the seam changes. The Noise implementation does not need to be read or understood to add a new authenticator; the seam is the entire contract.

The principal value type itself lives in src/identity/principal.lisp and carries a did:key identifier and the raw public key bytes that identifier encodes. For a Noise admission, the responder recovers the peer's static public key from the third message, encodes it as a did:key (multicodec 0xec01 for X25519, base58btc per the did:key method spec, in src/identity/did-key.lisp), and constructs the principal. At Tattach the principal lands on the live 9P session through seven's node-attach-identity seam: valis-root's specialiser returns it; seven stores it verbatim on the session's identity slot. Backend code reads it back through current-identity (seven) or the thin wrapper current-principal (src/namespace/root.lisp) for the dynamic extent of request dispatch. A standard file node's node-read runs synchronously on the session thread, so the principal is in scope during node-open / node-read / node-write; a backend that parks reads off-thread (the bus pattern) captures it at the synchronous call site and closes over it for delivery.

For a keyless attach (an Tattach that asks no key, e.g. a NOFID Tattach), the seam binds a distinct anonymous sentinel, never nil. The distinction is load-bearing: nil is the unresolved state before admission, the sentinel is the resolved state for "no key presented". Module code can therefore test anonymous-p without conflating "not yet authenticated" with "authenticated as nobody in particular". The sentinel carries the literal DID string "anonymous" so it is safe to log and dispatch on; the boundary that no key material reaches a module is enforced on its principal-public-key slot, which is nil. The anonymous principal is autonegotiated by the absence of a handshake, never produced by an error path and never a login prompt.

See the W3C Decentralized Identifiers and Noise Protocol Framework entries in the Bibliography.

The custody store in src/identity/custody.lisp is the sole holder of private key material in the running image. The owner's master key is an Ed25519 signing pair; the X25519 transport key Noise uses is derived from it deterministically, so one keyfile roots both the owner's signatures and the owner's channels. The master key is held in memory and persisted to a mode-0600 keyfile so the owner's did:key is stable across restarts: an in-memory-only key would mint a fresh owner DID on every boot and break every capability rooted in it. Real at-rest encryption (passphrase / OS keyring / HSM) belongs to a later phase when real steering and the IETF edge land; the dev keyfile is sufficient for the loopback substrate.

A protocol module receives only a resolved principal: a did:key identifier and a public key. It never calls into the custody store, never holds a private key object, and never has a name through which it could ask for one. This boundary is the key-custody enforcement point: the absence of any path from a module to a private key. The custody store is wired into the factotum's node-auth path by start-fabric (src/fabric.lisp), and stop-fabric clears it; an architect who needs to convince themselves the boundary is intact can read those two lifecycle hooks and confirm that nothing else is ever handed a custody reference.

The seam this creates around the rest of the system is the answer to the "confused deputy" risk that the capability discipline above is designed to head off: a module asked to act on a peer's behalf cannot be tricked into reaching for the owner's key, because it has no name for it.

Each phase success criterion is anchored to a named test in tests/identity-test.lisp that proves it. An auditor reading this document can run the suite and see the claim row stand or fail without reconstructing the coverage from source.

One validation limitation is recorded here rather than papered over. The AEAD primitive carries its RFC 8439 §2.8.2 known-answer vector, but the Noise_XX handshake above it is anchored only by an initialisation known-answer (noise-init-h-ck-known-answer) and a two-party self-interop (noise-xx-two-party-interop) in which both parties are valis: that proves the two sides agree with each other, not that they conform to the wider Noise ecosystem. The handshake state machine is a from-scratch implementation of a standard protocol, so before the authenticator is trusted in production it should be checked against independent published Noise_XX vectors (Cacophony / noise-c) and given a short cryptographic review; a bug shared by both sides would pass self-interop silently. This weighs more heavily as the same state machine becomes the basis other consumers in the constellation interoperate with.

The Noise_XX handshake authenticates who is calling, but the 9P session it admits still ran in the clear: every Tread=/=Twrite=/=Tclunk after Tattach crossed the wire unencrypted, authenticated only by the handshake that preceded it. That leaves a transport man-in-the-middle free to read or rewrite a peer's file traffic once admission is past. Closing that gap means every post-attach message (request and reply) is encrypted and authenticated under the Noise transport keys, and a tampered byte is refused.

The split that makes this auditable is the design's defining choice: all transport crypto belongs to mercer; valis is pure plumbing. mercer, the validated auth agent, owns the transport session: the keys, the AEAD, the two per-direction monotone counters, the nonce construction (the sequence is folded into the nonce and never appears on the wire), the orientation baked in by role, and fail-closed exhaustion. valis never touches any of it. valis owns only the keyed accept loop (it binds the socket, accepts each connection, wraps the connected stream in a secure endpoint, and hands that endpoint to the serve thread) and a thin delegating endpoint that holds nothing but an opaque session handle. Its read-frame calls the session's unseal; its write-frame calls the session's seal; it performs no cryptography of its own. The whole question "is the transport crypto correct?" is therefore answered once, inside mercer; valis's audit reduces to "does the plumbing route every post-attach frame through the session, and never leak the handle?"

The session contract (seal, unseal, close-session, and a transport-session-error condition family) is deliberately provider-neutral. It is the general secure-transport seam, not a Noise interface. Noise_XX is its first provider; a TLS provider for the IETF HTTP edges and ACME-issued certs is the intended second, and the plumbing consumes the abstract contract so that edge reuses it unchanged. Only one operation, obtaining the session from a completed handshake, is Noise-specific, and it lives at the attach boundary where valis installs the handle.

On the wire, each post-attach record is a cleartext 4-byte length prefix outside the sealed body, followed by the sealed ciphertext-and-tag. The length sits outside the seal so the reader can delimit a record before it has any key to unseal it; the AEAD tag is computed over the exact ciphertext, so any tamper at the record boundary fails authentication (which is why an empty additional- data field is safe here). The 9P engine keeps its own size[4] message framing above this layer, untouched: the wrap is a transparent record cipher beneath the protocol, not a change to it.

The pre/post-attach flip is valis-owned plumbing. The handshake, Tauth, and Tattach must cross in the clear: there is no session yet to seal them. valis installs the handle at the attach boundary (node-attach-identity in src/namespace/root.lisp), so the very first sealed record is the Rattach reply; from there every frame is delegated. Tamper is terminal: when unseal signals transport-auth-failed, valis tears the session down. There is no in-band rekey and no renegotiation: an anomaly ends the session rather than recovering it.

This is the same architecture Plan 9's 9front uses for post-auth styx encryption: factotum holds the keys and yields an opaque secret, devtls applies a record cipher (seal/open) under it, and exportfs speaks plain 9P over that cipher without knowing it is there. The mapping is one-to-one onto mercer (the keys and cipher), valis's plumbing (the record framing and the endpoint substitution), and seven (the cipher-agnostic 9P engine). The 9front-validated rules carry over verbatim: a cleartext record header outside the sealed body, a monotone per-direction sequence folded into the nonce and never on the wire, no in-band rekey, and interposition done by substituting the endpoint in the serve path.

The thin delegating endpoint is in src/transport/secure-endpoint.lisp; the keyed accept loop is in src/transport/keyed-acceptor.lisp; the attach-boundary install is in src/namespace/root.lisp. The transport session itself (every byte of the crypto) lives in mercer at mercer/src/transport.

Crypto correctness is mercer's, not valis's: the transport session's ciphertext is anchored byte-for-byte against mercer's own round-trip and the published Cacophony / noise-c vectors under mercer 0.3.0. valis's tests prove the plumbing: that the production keyed path routes every post-attach frame through seal/unseal, flips the pre/post boundary at the Rattach, refuses and tears down on tamper, frames records with the cleartext length prefix, closes and never exposes the opaque handle, round-trips orientation both ways, and holds the session cap and drain. Each row is anchored to a named test in tests/transport-wrap-test.lisp, and each test declares in its own docstring whether it observes the real production effect (DIRECT) or an equivalent property the production path guarantees where the live serve thread offers no external observation seam (PROXY), so an auditor sees exactly which dimension is proven how.

The transport wrap above proves valis seals every post-attach frame, but it proves it against valis's own initiator talking to valis's own responder, both sides our code. A bug shared symmetrically by both would pass that test silently. The remaining question is conformance: does the handshake valis admits, and the transport cipher it then runs, match an externally-defined standard rather than merely agreeing with itself? That question is answered by anchoring valis's real accept loop to a published Noise_XX transcript (bytes authored by the spec ecosystem, not by us) and confirming the wire reproduces them. Because the handshake valis sends carries no payload, the only published transcript its wire can byte-match is the empty-payload Noise_{XX25519ChaChaPolySHA256} vector, dual- referenced (noise-c and an independent reference) and vendored under mercer. The replay fixes all four handshake keys to the vector's values so the wire is determined by the transcript, not by agreement between two pieces of our code.

Each criterion below rides the genuine production path (start-fabric → keyed-acceptor → node-attach-identity, the same loop a real peer reaches), so the proof comes off the real socket, never a direct endpoint call. The named tests live in tests/over-the-wire-test.lisp.

One verification here is out-of-band rather than automated: an end-to-end wrapped attach against a real, non-loopback peer. The in-process and loopback dimensions all have automated in-suite coverage above; only driving a wrapped attach across a real network interface (which needs a remote peer and mount privileges the test image does not hold) is a manual test the operator runs, confirming the post-attach frames are ciphertext on the wire. The runbook below makes that check repeatable.

A capability token is the delegable form of authority. It carries the issuer's DID (the source of the authority), the audience's DID (the grantee), a list of mount grants (each a namespace designation with a rights set), an expiry, a nonce, and an Ed25519 signature by the issuer over a deterministic encoding of those fields. A delegated token carries its ancestry inline: the proof chain back to the owner's root token rides inside the token itself, so a verifier needs no external store to walk it. That self-containment is what makes verification offline: a property that matters under migration, when the owner's substrate may be mid-move and no authorization server is reachable. The value type lives in src/capability/token.lisp; the chain walk in src/capability/verifier.lisp.

Verification walks the chain from leaf to root. The root token must be issued by the owner and signed by the owner's Ed25519 key; every token in the chain must be unexpired and absent from the revocation store. Each delegation link is then held to four conditions: the child's rights must be a subset of the parent's, the child's designation must be a path extension of the parent's, the parent must itself carry the delegate right, and the child must not outlive its parent. Its expiry may equal the parent's but never exceed it. The third condition deliberately diverges from stock UCAN: re-delegation is a structural property of the chain, not a policy judgment made at verification time, so a grantee who was not given the delegate right cannot mint valid sub-grants at all. The fourth (expiry attenuation) is what keeps a delegate that legitimately holds the delegate right from wielding it to escape its own lifetime: because equality is the loosest a child's expiry may be, a delegate cannot mint itself a longer-lived token and outlast the grant it descends from. Extending a lifetime is therefore not a delegation act at all; it takes a fresh grant minted at the root, which only the owner can produce. Together with the issuer-to-audience continuity check at each hop, this closes the confused-deputy route through token forwarding: a chain that escalates rights, escapes its designation prefix, lengthens its own life, or passes through a non-delegable hop fails verification with a stated reason.

Both verification entry points are fail-closed: every condition raised during decoding or checking is caught inside the verifier and returned to the caller as a refusal with a reason string, never as an escaped condition. The 9P layer that fronts verification can therefore treat the verifier as total.

Where a token grants authority to a principal, a capability name grants authority to its holder. A name encodes a designation, a rights bitmask, an expiry, and a nonce, followed by the owner's Ed25519 signature over those bytes, the whole rendered as base58btc behind the valis: URI prefix: URL-safe, so the same string can later ride in an HTTP path. The codec is src/capability/name.lisp; verification is the same src/capability/verifier.lisp described above.

The name is self-certifying in the Tahoe-LAFS sense: verifying it requires only the owner's public key and the revocation store: no directory, no central service, no identity for the presenter. Handing out the string is the grant. This is how anonymous external actors are authorized without ever acquiring an identity: possession designates. The two costs of bearer semantics are answered structurally. Replay within the validity window is bounded by mandatory expiry: a name without a positive expiry cannot be minted. And the revocation store is the kill switch: every verification consults it, for names exactly as for tokens, so a leaked name dies the moment the owner records its hash, before expiry, not at it. The store itself (src/capability/revocation.lisp) is an append-only set of canonical hashes persisted beside the owner's keyfile; revocation is irreversible by construction. Tahoe's further trick (embedding an encryption key in the name so the storage layer never sees plaintext) is deliberately deferred until the durable store exists for it to protect.

Every verified presentation (token or name) resolves to the same internal authority value: the mount directive (src/capability/directive.lisp), a designation in the owner's canonical namespace plus a closed rights set (read, write, mount, delegate). A mount directive is an assembly instruction: it tells the namespace assembler which 9P-served subtree to bind into the requester's session view, with which rights. Recipients never interpret the designation string; they find the subtree present (or absent) in their assembled view. Authorization is thereby enforced by what is mounted, not checked per access: out-of-scope objects are not denied, they are unnameable.

The per-session view is the view-root (src/namespace/view-root.lisp), an attach root whose children come from a per-instance mount table. The binding happens at the attach moment: a bearer name presented as the 9P attach name is verified and the session receives a view containing exactly the designated subtree; a name that fails verification admits the session to an empty view: fail closed, never the shared tree. A plain attach continues to bind the development tree; the policy for what base namespace a keyed versus anonymous session receives there, and the per-request second phase that mounts further capabilities into a live view mid-session, is the namespace-assembly layer's work and lands with it.

Coverage over time is intrinsic to live mounts. A mount is a live 9P binding (walks reach the serving node at access time), so new children appearing under a granted subtree are covered the moment they exist, with no reissue traffic. The converse is also deliberate: new rights verbs are never implicitly covered, because the rights set is closed and a bitmask from an older grant simply has no bit for a verb that did not exist when it was minted.

The capability service itself is 9P-addressable at /cap (src/namespace/cap.lisp), mirroring the factotum discipline: a ctl file mints tokens and names and records revocations (signing always delegated to the custody store: key material never enters the capability layer), and a verify file turns a presented token or name into a verification verdict. Modules interact with authority through file operations, never through direct calls.

An owner does not always stand at the host. The durable way to operate a deployed node is through an owner-facing client (ubik) that attaches over the sealed 9P terminus from somewhere else entirely, and that never witnessed the node's genesis. The problem this section settles is how such a client comes to hold authority without the owner seed ever moving to it. The answer is two privilege tiers, each anchored to a proof matched to what it can do, and both expressed as ordinary revocable, key-bound capability delegations, never a copy of the root secret.

The anchor is matched to consequence. Operator-equivalence can destroy everything, so it demands the strongest gate a genesis-less client can be held to: a demonstration of real host control, strictly stronger than mere network reach. Scoped grants are bounded and revocable, so they ride the ordinary capability path with no host-access requirement; forcing proof-of-reality on every client action would defeat the point of a delegable capability system. Crucially, neither tier moves the owner seed. Even operator-equivalent access is a delegated, key-bound, revocable capability, which is exactly what lets a client be operator-equivalent without becoming an unrevocable clone of the owner key.

Tier 2 is already the capability layer above at work: an owner (or an operator-equivalent client bearing the delegate right) mints an attenuated token via /cap ctl (audience the client's own DID, a specific mount grant, a short expiry), and the client presents it over the terminus, where the assembler binds its audience to the Noise-authenticated session principal and verifies the chain to the owner root. No host access, no new mechanism; the trust model simply uses it.

The owner's identity method is did:key, which has no update or deactivate operation: the DID is the key. Rotation is therefore destructive and total: every grant rooted in the old key dies with it. The procedure, in order:

1. Revoke all outstanding capability hashes by writing them to the revocation store, then stop the fabric. Revoking first means a copy of the old keyfile recovered later still cannot resurrect old grants within their expiry windows.
2. Delete the dev keyfile at ~/.valis/dev-keyfile. The keyfile is the only persistence of the master key; removing it is the rotation.
3. Start the fabric. A fresh Ed25519 master key is generated, the owner DID changes, and the derived X25519 transport key and every factotum-served descriptor follow it automatically.
4. Re-mint every capability name the owner wishes to keep granting. Old names became unverifiable at step 3 (their signatures no longer match the owner key the verifier is handed), so bearer names held by external parties are invalid immediately, not merely at expiry.
5. Reissue delegation tokens to every delegate. Old chains terminate at the old owner DID and fail the root-issuer check.

There is no migration utility in v1: the procedure assumes the loopback development phase, where no real authority is outstanding. When real external grants exist, rotation tooling must walk the revocation and reissue steps mechanically rather than trusting the operator's memory.

⇒ The record of how this position was reached, with the constraints that produced it and what it means for work built on valis, is The epistemology of fully connected symbolic computers. This section remains the statement of record; that one explains it.

⇒ The classical statement of this division is in docs/REPL-AXIS.org under The hierarchy, in the classical terms, and it is the one to read first: the Lisp runtime is this machine's operating system kernel, and the capability model is that machine's programming ABI. What follows here is that argument's consequence for how instances relate, which that note poses without resolving.

Authority in this system divides into two planes, and only one of them is described by the rights above.

• The data plane. Reading and editing projections of the operator's own data. This is what :read, :write, :mount and :delegate describe, and it is where substantially all ordinary operation happens.
• The execution context. Root access to the running Lisp machine itself, in the sense that term carries for any machine: loading code, installing a service, changing what the node is.

⛔ A question of the form "which right is evaluation" is malformed, and the answer is not a new bit. :write cannot carry evaluation, because :write means editing a projection of the data. A new right alongside the others is the same category error under another name: it 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. A holder performing correct attenuation arithmetic on such a right would get a wrong answer, and nothing in the mechanism would object.

These are stated rather than answered. They are recorded here because each one constrains the capability model above, and a reader who takes that model as complete would be misled. Each will be answered in this document when implementation settles it, not before.

As with the identity layer above, each capability success criterion is anchored to a named test an auditor can run. All tests live in tests/capability-test.lisp.

A session's namespace resolves in two phases. At connection time, the principal established during the Noise handshake (or the anonymous sentinel for keyless connections) determines the base namespace the session receives. This is the connect-time assembly in src/namespace/assembler.lisp, the function build-base-view. A connection whose principal matches the owner's key receives the full canonical namespace: all axes present, all of /proto, /bus, /id, /cap, and /ctl named and reachable. The anonymous sentinel receives the read-only /pub published view and nothing else, the same surface an unauthenticated HTTP GET resolves to (see The anonymous published view across both edges, below). A keyed peer who is not the owner receives an empty namespace: the connection is admitted, but there are no names to reach for. Sovereignty is the absence of a name.

After the base namespace is established, a second phase runs when a capability is surfaced alongside a request. Writing a capability to the session's /ctl node (or calling the in-image assembler API directly) mounts the designated subtree into the live view. The capability is verified through the same path as bearer-name attaches: the designation is resolved, rights are applied, and an audience check is made for audience-bound tokens. A read-only grant produces a deep read-only proxy (see below); a write-capable grant mounts the raw node. The mount persists until the session detaches or the capability is explicitly unmounted.

The base policy has exactly three cases, decided once at Tattach time:

• Anonymous connection (NOFID or keyless): the read-only /pub published view, and only that. /pub is published (public by design), so an anonymous mount names it and traverses the published items beneath it, but the floor is wrapped in a read-only projection: every write, create, and publish is refused. The credential-gated axes (/proto, /bus, /id, /cap, /edge) have no name to reach for. If the publication substrate is not up the floor is simply empty: fail-closed, never an error. Capabilities mounted in the second phase still widen the view from here.
• Keyed connection whose principal is not the owner: empty namespace. Knowing who a peer is does not grant them anything; authority arrives only as capabilities, not as identity alone. A non-owner keyed principal does not receive the /pub floor: only the anonymous sentinel does.
• Connection whose principal's key matches the owner's key: full canonical namespace. The owner is the root of all authority: for the owner, every axis has a name by definition.

The policy is expressed as a function in src/namespace/assembler.lisp. The identity check compares the connecting principal's did:key identifier against the owner's DID from the key custody store (src/identity/custody.lisp). If the custody store has not been initialised (for example, in tests that exercise individual nodes without starting the full fabric), the owner-DID check is skipped and the connection receives an empty namespace: a deliberately fail-closed default.

Bearer-name attaches bypass the base policy: a capability presented as the 9P attach name is verified by the capability service and mounts exactly the designated subtree, regardless of the connecting principal's identity. The name is the grant.

A session namespace is an ordered list of mount entries. When two grants cover the same leaf name, the entries form a union: walking the name tries entries in list order and returns the first successful resolution. Directory reads concatenate entries from all union members without deduplication: both entries appear in a listing even when their names collide, because the collision is resolved at walk time, not at list time. This follows the Plan 9 and 9Front kernel's union-directory semantics.

Three bind flags govern how a new mount is added to an existing name:

• Replace: the new entry becomes the sole entry for that name; any prior members are removed.
• Before: the new entry is prepended to the member list; it is searched first on walk.
• After (default): the new entry is appended to the member list; it is searched last on walk. The existing members keep precedence on name collision.

The bind flag is a choice made by the caller at mount time: it belongs to the presentation, never to the grant. A grant carries a designation and rights only; the flag is supplied separately in the ctl grammar or the assembler API.

When a create request targets a union name, the first union member that has write rights receives the create. This is a simplified reading of the Plan 9 MCREATE rule, adequate for the current namespace structure where grant rights are known at assembly time.

The union semantics are implemented in src/namespace/union-node.lisp and exercised by the assembler; the seven server never interprets union structure: it invokes the backend's node-walk and node-entries methods and the union node responds appropriately.

When a grant carries only read rights, the assembler wraps the designated subtree in a read-only projection node at mount time (src/namespace/projection.lisp). The projection is a deep proxy: walking through it returns further projections, so every node in the subtree seen through the projection is also read-only. Write, create, remove, and wstat operations on a projected node fail at open time: the write path has no name, not merely an error response.

The projection node passes through the inner node's QID unchanged. A QID identifies a resource object, not a view of it, so two sessions projecting the same underlying node present the same QID on the wire. This is correct 9P2000 behaviour: the projection is transparent at the protocol level.

Enforcement is by construction: the projection is what was mounted; there is no policy lookup on the hot path. The decision is made once when the grant is assembled, and thereafter no per-access check is needed or present.

When a capability is revoked, the revocation takes effect immediately in all live sessions that have mounted it. The revocation path (src/capability/revocation.lisp) persists the revoked hash, then calls the assembler's eviction sweep. The sweep walks the live-session registry and removes every mount entry whose stored grant hash matches the revoked hash.

The registry is a weak-reference table keyed by the live namespace root, constructed via make-hash-table with :weakness :key (an SBCL extension). What it maps that root to is a live-view-entry, and the entry carries considerably more than the session's principal: the session id an operator has to be able to type, the auth conversation the session was admitted through, the Unix seconds at which it was admitted and at which it was last used, a fenced marker that is nil for a live session and the second of the fence otherwise, and a per-view lock. The id exists because the registry is keyed by object identity, which is unspeakable outside the image, so an operator looking at a session they want stopped needs a name for it. The same entry is also held on the view itself, so the request path stamps its activity mark from a slot read rather than a lookup on a weak table.

The lock ordering is a discipline rather than an aside. A sweep snapshots the registry under *live-view-registry-lock* and releases that lock before it takes any per-view lock, which maintains one acquisition order throughout: registry lock, then per-view lock. Two paths that take the same two locks in opposite orders deadlock the fabric, and a deadlocked fabric answers nothing at all. Within that order a sweep holds the session's own lock across the removal, so a session's namespace is consistent before and after; no session sees a partially-evicted state.

Mount entries created by the base-namespace policy carry no grant hash and are never affected by the revocation sweep. Revocation targets only capability-backed mounts established through the second phase. That immunity is correct for what the sweeps do and is depended on elsewhere, and it is also why withdrawing an owner's live authority needs a mechanism of its own: see owner session lifetime below.

Weak references are what make an ended session safe to forget. A session whose view root is no longer reachable by anyone is collected without an explicit deregistration hook, and that is a settled arrangement rather than an outstanding one. The gap worth naming is a different thing and it concerns sessions that are still live: a handle already open below the root of a session that has been fenced goes on working. The next section states that limit and what follows from it.

The owner was the one principal whose live authority could not be withdrawn. Authority that arrives by presenting a capability carries a grant hash, so both eviction sweeps can find it and take it back. Authority that arrives by proving who you are is base-namespace policy, carries no grant hash, and both sweeps pass over it by design. The owner's frame is base policy from end to end, so it was precisely the case the sweeps could not reach: short of restarting the fabric, an owner session admitted once went on naming the full frame for as long as its transport lived.

Fencing a session empties its view outright, base policy included. That asymmetry with the two eviction sweeps is deliberate: a mechanism that respected the usual immunity could not touch the very session an operator is trying to stop. What is left is a session that can name nothing, which is how this namespace refuses in general. An out-of-scope object has no name to reach for rather than a name that answers no.

A fence does not tear down the sealed transport, and it is not meant to. The connection stays up and the session on it can reach nothing, which is the same enforcement model the rest of this document describes: absence rather than denial.

A session is stopped three ways.

• By name, at the identity door. An operator reads the live sessions, picks the one they want, and writes a fence command naming it. Fencing the session issuing the command is allowed and does exactly what it says, because an operator who has lost control of a session should not first have to work out whether they are about to cut themselves off, and an attacker sharing that session should not keep it by virtue of being the one still holding it.
• By idleness, checked lazily. The bound is enforced by the operation that would have used the session, not by a sweeper. A dormant session issues no requests and reaches nothing; the case worth catching is someone picking up an abandoned one, and that arrives as an operation.
• By an authority transfer. When write authority moves to another locus, every live owner session on the surrendering instance is fenced. This is a separate step from the capability sweep that runs beside it, and it decides by principal rather than by generation, because an owner's namespace is base policy and the sweep cannot reach it. Without this step the instance that gave up authority would go on serving its owner after an evacuation.

The idle bound is unset by default, and the default is a decision. Applying a bound to a deployment that never asked for one is a lockout nobody requested arriving with an upgrade. Fifteen minutes is the recommended value, short enough that an unattended browser tab stops being a live management console over a lunch break and long enough that ordinary editing is never interrupted, but it is advice a launcher or an operator adopts explicitly rather than a value that applies on its own.

Getting back in means authenticating again, and that is where the seam earns its place. A re-attach on the same transport is refused by conversation, so a client cannot simply ask for a fresh frame and hand itself back what was taken; re-running the handshake yields a conversation the fence has never seen, and that succeeds. This connects directly to the evaporate-and-recondense architecture described later in this document: an owner whose instance has relocated has to be able to ask whether the instance now answering is the one they meant, and a session that silently outlives a relocation is what makes that question unanswerable. Cutting the session is what forces it to be asked.

Each success criterion for the enforcement-by-mounting layer is anchored to a named test that proves it. An auditor reading this document can run the suite and see each claim stand or fail without reconstructing the coverage from source.

A publication is a directory node in the 9P namespace whose children are named attribute files (title, author, published-date, content-type, and an optional gemtext) plus a body file. The object is shaped as a Plan 9-faithful directory-of-files: each attribute is individually walkable, individually grantable, and independently readable by an adapter that needs only some fields. The five core attributes are the web-minimal metadata set; gemtext is a per-protocol representation used by the Gemini adapter when a publication wants to serve native gemtext while the generic body carries HTML for HTTP. The adapters are required to consult all present attributes when rendering: this faithfulness contract is what makes the projections equivalent views rather than competing copies.

Absent attribute files are tolerated at read time. The node layer returns defined defaults (Untitled for title, an empty author, a date derived from the publication's modification time, text/plain for content-type, an empty body), so a half-authored publication stays on the wire during creation instead of erroring until every field exists. The defaults are applied by the node layer, not the store: a store backend reports absence (a null attribute, an empty body), and the caller decides what absence means. The node classes live in src/substrate/publication.lisp; the /pub axis that roots them in the namespace is src/namespace/pub.lisp.

Protocol-agnosticism is an import invariant, not a convention. The store and publication packages import no protocol or registry package, and the adapter packages import no substrate package: an adapter's only path to a publication is a real 9P attach, walk, and read. A future adapter must preserve this boundary: if it can name a substrate symbol, it has bypassed the capability seam the design depends on.

A publication reaches the published axis at any time. An owner-keyed client walks the axis over the sealed loopback fabric, creates the slug when it is not already there, and writes the content type and the body; a slug that already exists is replaced rather than refused, so a page can be revised as often as its author likes. The reason this matters is plain in the operator's terms: a node built before a page existed must still be able to receive that page.

The store protocol (src/substrate/store.lisp) is the seam between the namespace node layer and backing storage. It is a narrow CLOS contract: eight generic functions (list, attribute read and write, body read and write, create, existence, and modification time) each taking a store instance as its first argument. There are no default methods; a backend that misses a method is a missing-method error, never a silently papered-over default. Reads are tolerant by contract: absence comes back as a null attribute, an empty octet body, or a null mtime, and the calling node layer applies the documented defaults. The filesystem backend (src/substrate/fs-store.lisp) is the v1 implementation; a future content-addressed store implements the same eight functions and no node class above the seam changes. This seam is the designated replacement point for the durable-storage work.

The filesystem layout mirrors the namespace: one directory per publication, one file per attribute, the slug as the directory name. The layout is inspectable with ordinary tools and is the same tree a kernel v9fs mount would see.

Writes are atomic via rename-into-place: the value is written to a temporary file in the publication's own directory, then renamed over the destination, so a reader never observes a torn write: the rename is atomic because source and destination are on the same filesystem. Temporary names are unique per write (process id plus an atomically incremented counter), so concurrent writers never collide on a shared temp path. Writes are durable as well as atomic: the temporary file's data is flushed to stable storage (fdatasync) before the rename, and the containing directory is flushed (fsync) after it, so a write that has returned survives a crash or power loss; creating a publication flushes the data directory the same way, so the new directory entry is itself durable. A write whose flush or rename fails signals store-error instead of reporting success. The cost is two device flushes per write (tens of milliseconds on rotating storage) which suits operator-paced publication writes; *durable-writes* can be bound to nil where durability is deliberately traded for throughput, such as bulk imports.

Slug validation is the path-injection guard, and it is enforced fail-closed at both ends of the object's life. A slug is a non-empty string of lowercase ASCII [a-z0-9-], checked at the create path (node-create on the /pub root, and again inside the store backend before any directory is made) and at the read path (node-walk refuses a non-conforming name even when a matching directory exists on disk). Because the walk side validates independently, no adapter bug or encoding trick can turn a wire request into filesystem traversal: the HTTP adapter additionally percent-decodes each path segment before validating it, so an encoded .. is rejected as the decoded text it really is, and the Gopher adapter rejects .. segments in the raw selector. The shared predicate lives in src/namespace/pub.lisp.

The durable backend (src/substrate/store-store.lisp) is the second implementation of the store seam, the content-addressed analog of the filesystem store. It implements the same eight generic functions over a content-addressed block stack, a Merkle tree codec, and a generation-fenced head, so no node class above the seam changes and the /pub path behaves identically to the filesystem backend. The seam, not a backend choice, is what the rest of the system sees; this backend exists so publications can become crash-consistent and content-addressed without disturbing the publication object model that sits on top of it.

The on-tree layout is the same shape the filesystem backend writes to disk, expressed through the tree codec rather than through directory entries. The head names a root tree; that tree carries a pub directory child; each publication slug is a subdirectory under it; each attribute is a file child named for the attribute; the body is a body file child. The publication node layer's slug / attribute / body model therefore carries over unchanged: the durability mechanism shifts, the addressing model does not.

Durability here is structural rather than a flush discipline bolted onto a rename. A block is content-addressed and written (and flushed) before the head names it, so the head never references a block that is not already durable. Advancing the head is a generation-fenced compare-and-swap, and that single advance is the only linearization point for a write: a write that carries a superseded generation is rejected at the commit and surfaces as store-error, never a silent overwrite and never a retry that could lose a concurrent change. This is the durable-before-referenced ordering the rest of the store stack already relies on, reused at the publication seam.

Writers within one image are serialized by an in-image lock the backend holds for the read-modify-write cycle, so the only way the compare-and-swap can fail is an out-of-band advance from outside this image, and that case fails closed as store-error. The lock removes the need for an unbounded retry loop; the compare-and-swap remains the authority on what actually committed.

One place the POSIX assumption behind the seam leaks through: the seam exposes a publication modification time, and there is no filesystem timestamp to report. The durable backend synthesizes that value from the head generation, which is monotone, so a later write always reports a later time. The value is used only as the published-date display fallback when a publication carries no explicit published-date attribute; it is a display proxy, not a wall-clock guarantee.

The backend is selected when the fabric starts (src/fabric.lisp, start-fabric). The durable store is the wired default; the filesystem store is retained as a selectable operator fallback for a conservative rollout or for continuity with an existing on-disk publication tree. A fresh durable store serves an empty /pub on first boot: there is no in-band migration of existing filesystem publications into the durable store, so an operator who needs continuity with a filesystem publication tree selects the filesystem backend until a later migration path lands. The durable store roots at its own data directory, distinct from the filesystem publications tree, resolved in a fixed order: an explicit operator-supplied store directory wins; otherwise the store roots at a sibling of a supplied publication directory; otherwise it falls to the XDG data home default. Both the durable store's data directory and the selected store are cleared on a failed start and on stop, so a fabric that fails to come up or that has been stopped leaves no dangling seam state behind.

Two boundaries make this backend auditable. First, it is the one file that bridges the store seam and the lower block, head, and tree codecs, and it deliberately reaches no identity, capability, namespace, or protocol symbol: the seam-crossing is one-directional and structurally enforced, so a capability bug cannot reach storage and a storage bug cannot reach the capability layer. Second, the store holds opaque blocks: it never interprets publication content and carries no key bytes. The durability layer sees ciphertext-or-cleartext blocks as bytes to address and name, never as material to read: the sovereignty boundary that keeps key custody out of the storage path holds here as it does everywhere else in the substrate.

The wire-format adapters (the adopted c3po-http and c3po-gopher modules) are ordinary valis protocol plugins: each registers on its port and specialises handle-connection. What makes them adapters rather than owners is how they reach content. At fabric start (src/fabric.lisp), each adapter is handed a freshly minted bearer capability designating /pub with read-only rights, and opens a long-lived 9P session by attaching over an in-process channel, the same codec and the same enforcement path a remote 9P client would traverse, with no TCP loopback. The assembler resolves the capability to a mount directive and builds a view containing exactly one entry: a read-only projection wrapping the publication root. The adapter can walk and read; a write-mode open is denied at the server by the projection wrapper, not by the adapter declining to write. Because the attach path is the in-process form of the real transport, the adapter is structurally identical to a sandboxed out-of-process edge module. Moving it out of the image changes the transport endpoint and nothing else: capability, view assembly, and projection enforcement are already in their final shape.

Each wire request maps one-to-one onto a walk in the adapter's mounted subtree. A missing name is a walk failure, and the adapter surfaces it as the protocol-native absence: HTTP 404, Gopher error entity type 3. A principal with no /pub grant has no /pub name at all, so absence reaches the wire by construction, never by a permission check on an admitted request.

Responses and requests are size-bounded. Directory listings and file bodies are read with hard ceilings (one megabyte for a listing, sixteen megabytes for a body), so a pathological publication cannot balloon a response buffer. Request lines are byte-capped on read (4096 bytes for an HTTP request line, 1024 for a Gopher selector), and overflow is answered with HTTP 413 or a Gopher type-3 error rather than unbounded buffering. Connection occupancy is bounded the same way memory is: each adapter arms a per-connection read deadline when it accepts a request (*http-read-deadline-seconds* and *gopher-read-deadline-seconds*, ten seconds by default), so a client that connects and sends nothing (or dribbles bytes slower than the deadline) cannot hold a handler thread past it. Expiry is treated exactly like a malformed request: HTTP answers 408 Request Timeout, Gopher closes without a response per its one-transaction model, and the executor reclaims the thread and the socket. The mechanism lives behind the connection seam: the adapter arms the deadline through a transport-blind generic, and the epoll backend (the one component allowed to name the socket library) wakes the blocked reader by shutting down the socket's read side, which surfaces to the handler as ordinary end-of-file while leaving the write side open for the parting response. In-memory connections, and any transport with nothing to time out, accept the call as a no-op.

Adapter teardown is complete: stopping the fabric closes both ends of each adapter's in-process channel, and close means drain-then-EOF: frames already written still deliver, then both sides observe end-of-file. The teardown order is deliberate. The port is unregistered first, so no new connection lands in a dying session; the live fid handles are clunked while the channel still delivers; the channel is then closed, which wakes the server's blocked dispatch loop and lets it return; finally the stopped adapter joins its server thread. The client-side reply reader exits on the same EOF, with any outstanding waiters drained by a transport-closed condition rather than left blocked. The join is bounded: a server thread that fails to exit within the timeout is a regression in the channel's close path, and it surfaces as a loud warning naming the leaked thread rather than a stop that hangs forever: teardown must never trade a thread leak for a deadlock.

Each success criterion and security property of the publication substrate is anchored to a named test. The substrate tests prove the object model and the 9P session path; the render tests drive handle-connection end to end against an in-memory connection (the same entry point a real TCP client reaches), so the request-parse, walk, and response-render paths are exercised exactly as shipped.

• Bulk and cold data is content-addressed and immutable: a block's hash is its name (the Venti model; IPFS as the transport). Immutable content is location-independent: an instance pulls it from wherever it is served.
• Published data is content-addressed and unencrypted, served from many places at once. Because it lives outside the mutable store, high-fanout public reads never touch the private substrate.
• Mutable state lives on a backing store the instance mounts; the mutable head is a small hash pointer over the immutable tree, in the manner of fossil over Venti or git refs over objects.
• Secret keys are owner-held or held in a separate trust domain; they are never content-addressed and never live solely on a host that might be evacuated.
• A hot working set is served by a read-side caching tier in front of the store, so a coincident instance keeps its reads off the single-writer head while still observing every committed write. It is two caches and a coherence primitive, each of which gets its correctness from a fact the store already carries (a block's hash is its name, and the head's generation is its version), so the cache adds speed without adding a way to be wrong. The read-side caching tier below is the mechanism.

The reassembly is not a single function but an ordered handshake whose composition site is src/fabric.lisp → start-fabric (the :evacuative t arm drives the security regime; see the two regimes below). An auditor can follow it through these named seams.

A fresh instance comes up only if it holds the owner's key out of band: the gate is src/fabric.lisp → owner-key-required, which fails closed when the keyfile is absent rather than standing up an unauthenticated substrate; the key itself is loaded through the custody seam (src/identity/custody.lisp → load-or-create-keyfile), so the key bytes never live on the durable store the instance mounts. With the key in hand, the instance reconstructs the filesystem semantics at src/namespace/assembler.lisp → assemble-canonical-frame, the single reassembly entry that rebuilds the view from the manifest of mounts; an unreachable mount is a fail-closed stand-up (reassembly-unreachable), never a silent partial view. The assembler reads the authoritative mutable head through an injected seam, *durable-head-reader* (bound at fabric start, src/fabric.lisp), so the same reassembly code path serves whether the head is read from the durable store or from a test double: the durability boundary is one named indirection, not a scattered set of direct reads.

The mutable head carries the generation that is both the consistency token and the fence (the two regimes section traces its security role). It advances through one linearization point: src/store/head.lisp → advance-head, a compare-and-swap against the expected generation. A late writer that expected a superseded generation loses the swap and is told so by generation comparison alone: no wall clock, no lease deadline. The pre-commit fault seam *advance-head-pre-commit-hook* (src/store/head.lisp) lets the out-of-band crash harness freeze a writer exactly at the swap to prove the rejection survives a real pause.

valis instances can be temporally coincident: several at once, to absorb load. Authority over the mutable namespace is a single writer per subtree (the fossil model), not a leaderless or eventually-consistent scheme: a sovereign namespace wants one authoritative truth, not merge. For one person's modest write load a single writer is ample; if write scaling ever bites, the namespace (already a tree of mounts) is partitioned into per-subtree authorities (the Ceph dynamic-subtree-partitioning model). Coincident instances each assemble their own namespace view and interpose caches; the authoritative writer serialises mutation; public read load is offloaded to the unencrypted content-addressed publishing path.

The mutable head carries a monotonic generation token, which yields consistency and fencing from one mechanism. There are two migration regimes:

• Coincident (scaling): several instances share the store; the generation/lease serialises who may advance the head.
• Evacuative (security): fleeing a computational substrate under attack, assuming the host is compromised. Standing up the new instance bumps the generation, which fences the old, possibly-compromised instance: the store rejects writes from a superseded generation, the same shape as revoking a superseded capability. Because keys never lived solely on the evacuated host, the new instance comes up without trusting the old one.

In-flight connections drop and re-establish by default, acceptable because the namespace, not the process, is the source of truth. Live carry-over of established TCP connections (the kernel's TCP_REPAIR path) is a possible enhancement for protocols that cannot tolerate a reconnect, not a dependency. Re-steering the established sessions cleanly (so the old instance's clients reconnect to the new one rather than waiting on a passive TCP drop) is the job of a session-drain seam on the steering host's agent (the chartered drain-sessions boundary, proposed in the steering agent's repository). That seam is a latency and user-experience improvement on handover, never the fence: the fence is the store's, and it holds whether or not the old host cooperates, because the threat model assumes the old host may be compromised.

One submission traces these seams in order. The owner stands at /mail/outbox holding a write capability minted through the real /cap/ctl path; an anonymous or unauthenticated peer never reaches this door.

1. Authenticated submission (the clunk commit). A capability-mounted 9P write into /mail/outbox stages octets; the clunk is the atomic commit (src/namespace/mail-outbox.lisp → node-close on the outbox-submission file). The envelope and the submit provenance are stamped at the clunk, never parsed from the body; a fid abandoned without a clunk lands nothing: complete or absent by construction.
2. The live seam. /mail is present in the running owner frame only because src/fabric.lisp → start-fabric binds the three mail seams (*mail-dir-root*, *local-delivery-did-resolver*, *local-domains*), each gated on a durable store-backed substrate and reset fail-closed on teardown. The axis is mounted by src/namespace/assembler.lisp → %ensure-mail-mount and reached at src/namespace/root.lisp → node-walk on "mail".
3. Ingest. The clunk hands the assembled octets, derived envelope, and stamped provenance to src/mail/seam.lisp → land-message, the single ingestion door through which both owner-submitted and peer-landed mail enter.
4. Route. src/mail/router.lisp → route-message classifies every recipient through route-recipient, which tests locality against *local-domains* and admits relay only on proven submit authority (see the open-relay guard below).
5. Queue. Each routed recipient lands a durable per-recipient record via src/mail/transport-queue.lisp → place-incoming: the ack follows the fdatasync, so the queue is durable before the submitter is told "committed". The relay path is admitted into a bounded active window with admit-active and the slot is returned on a terminal outcome with release-slot.
6. Local delivery. A local recipient is written into the owner's Maildir at /mail/inbox/<did>/new/ by src/mail/local-deliver.lisp → local-deliver, keyed under the live owner DID the *local-delivery-did-resolver* returns from custody.
7. Relay drain. A relay recipient is drained by src/mail/drain.lisp → start-mail-drain / drain-active-once, which hands the opaque message to a registered mail-adapter. The wire engine is stubbed here; the adapter records a disposition and the drain frees the active slot.

The same path is driven against the live fabric (outbox capability, real router, real queue, real delivery) in tests/mail-end-to-end-test.lisp, so the walkthrough above is exercised, not merely asserted.

route-recipient reaches the relay path by exactly two yes-paths: the recipient is local (recipient-local-p true against *local-domains*, so the message is delivered into a local inbox and never relayed), or the message carries authenticated-submit provenance, an owner who stood at /mail/outbox under a keyed session. A peer-landed message (non-authenticated provenance) for a non-local recipient matches neither path: route-recipient signals mail-open-relay-refused and lands nothing, never silently forwarding.

What this guarantees is that valis cannot become an open relay. Why it holds by construction: there is no allow-relay flag to misconfigure. Relay authority is a capability the submitter either presents or does not; the refusal is the absence of that authority, not a policy toggle a host could flip. An auditor confirms the guard is live, not vestigial, in unauthenticated-non-local-relay-is-refused-fail-closed.

A message body is an opaque block, content-addressed octets the store names by the hash of their bytes and never interprets, exactly like every other block in the durability cluster. Sovereignty here is absence: the operations-facing view of the mail spine has no name for any body. A read grant on /mail/queue resolves a body-free projection (src/namespace/mail-queue.lisp → %synthetic-name) that exposes envelope and status only; it has no walkable name for any message body and none for /mail/inbox. The body score that keys a status record is an address, never invertible to content.

The table below audits the operations paths an operator would use to move or observe the mail spine. None of the backup or observability subsystems named here exists yet: the audit covers the seam each would build on and shows that the seam reaches octets, not meaning. The store handles opaque octet vectors and is encryption-ready, not encrypting.

Each success criterion of the mail spine is anchored to a named test. The end-to-end tests drive the real start-fabric seam, outbox capability, router, queue, and delivery over a durable store with only the wire engine stubbed; the sovereignty tests prove the content boundary both behaviorally (over a really queued message) and by construction (a do-symbols import firewall).

The contract a bound DNS wire engine sees is deliberately narrow and versioned. The engine hands a decoded query (a name, a type, and a class) to the registered serving handler, and the handler returns a record set and a result code. That handler is runciter's: valis registers (make-dns-service-handler <pg-zone-source>) as the adapter handler, so the answer is composed by the nameserver over valis's data, not by valis. The result code is one of three keywords: :noerror (the record set is the answer), :nxdomain (the name does not exist), or :nodata (the name exists but carries no record of the asked type). The contract keeps :nodata distinct from :nxdomain because they are different facts about the zone, and a correct resolver caches them differently; the wire maps :nodata onto a NOERROR message with the authority section carrying the zone's apex SOA.

Negative answers carry authority data, not just a code. On both :nxdomain and :nodata, the handler returns the zone's apex SOA record in the record set, so the wire has everything it needs to emit a spec-correct negative response and to compute the negative-cache lifetime as the minimum of the SOA MINIMUM field and the SOA record's own TTL (RFC 2308). A name outside every authoritative origin is :nxdomain with an empty record set (not-authoritative, no apex SOA), kept distinct from an in-zone negative. runciter owns what authority data accompanies each outcome; the wire stays a pure codec that encodes what it is handed.

Name synthesis is the nameserver's job, never the wire's. For an aliased name the returned record set already contains the CNAME record plus any in-zone records the alias resolves to (one in-zone, single-hop chase); for a name covered by a wildcard owner the returned set is the synthesized answer. The wire encodes what it is handed and never chases names or reaches below the seam for zone data. Everything that is purely a property of the wire stays wire-side and is never surfaced at the seam: EDNS0/OPT and the DO bit, truncation, response-rate limiting, recursion flags, the message ID, name compression, the authoritative-answer bit, and the transport-generated result codes (FORMERR/SERVFAIL/NOTIMP/REFUSED). Delegations and DNSSEC are not in the v1 contract; they are additive later through a contract-version bump, gated by the same fail-closed version check described next.

The version check is fail-closed at register time. src/plugin/dns-adapter.lisp holds the seam: the *dns-adapters* registry, register-dns-adapter, and a contract-version constant +dns-adapter-contract-version+ (1) with the set of admitted versions in *supported-dns-contract-versions*. An engine that declares a contract version outside that set is refused before any registration mutates the table: register-dns-adapter signals dns-adapter-version-mismatch and binds nothing, so a wire engine built against a future, incompatible contract can never silently skew against this core.

valis exposes its zone data to the nameserver through a narrow read protocol, not a serving cache. pg-zone-source (src/operator-state/zones.lisp) implements runciter's zone-data-source protocol over the dns_zone / dns_record rows: zone-version (the zone's SOA serial as an opaque RFC-1982-comparable token), zone-record-set (the runciter resource-record structs of a zone), and lookup-records (records owned by a name). Two further reads let the nameserver build its serving index and gate answerability without a serving view living in valis: source-origins (the held-inclusive set of canonical origins valis holds authoritatively now) and zone-cutover-status (a zone's (cutover-state, expire-deadline): the facets a secondary's answerability turns on). Each method queries the ambient pooled connection, so a caller wraps a read in with-operator-state-connection; the methods open no per-query socket on any hot path because the hot path is runciter's, not valis's.

The in-memory serving index and the answer composition live in runciter, the nameserver. runciter loads its index from this read seam, holds it as an immutable snapshot, and composes every answer (the RFC-2308 decision tree: exact match, one in-zone single-hop CNAME chase, single-label *.<parent> wildcard synthesis, NODATA-versus-NXDOMAIN against an existence set, apex SOA on in-zone negatives, no apex SOA on a not-authoritative name) over its own snapshot. valis composes no answer and caches no zone. This is the Option-A split: the serving cache lives with the nameserver; valis is the authoritative DATA owner over PostgreSQL.

Availability is runciter's, by construction over this seam. runciter rebuilds its index build-then-swap under a lock and serves last good: a rebuild whose source read raises (PostgreSQL unreachable, a row malformed) is contained, leaving the prior snapshot answering, so a database outage degrades to serve-last-good rather than to an empty answer. PostgreSQL is the operator's system of record, never the per-query dependency. valis's contribution to that guarantee is the data seam itself plus the cutover facets the nameserver gates on; the serve-last-good property is verified in runciter's suite (failed-rebuild-keeps-prior-index, source-outage-after-load-keeps-answering).

valis installs nothing into a serving view on commit: it owns no view. The capability-gated :names door (src/namespace/names.lisp) takes a zone's master text and commits an atomic full-zone replace at the 9P clunk: node-close on the submission file is the commit, exactly as the mail outbox clunk is. After the import resolves the new serial, the commit fires the in-process zone-change signal (fire-zone-change, origin and serial) so an in-process listener (the outbound zone-change feed, and a wire feed) observes the change. The nameserver refreshes by pull: runciter re-checks zone-version per origin (and source-origins for set changes) on a throttled, query-triggered poll and rebuilds its index when the version is newer, so a committed write is picked up without valis pushing into runciter. The committed write is durable in PostgreSQL regardless; runciter's next successful pull reflects it. (A lower-latency optional force-refresh seam exists on the runciter side, refresh-dns-service, that a commit hook may call; valis leaves it unwired by default, the throttled poll being the correctness floor.)

valis stores zone records in typed PostgreSQL columns (owner, TTL, class, type, and the record's rdata as presentation text) and is the authority on that envelope. It is not the authority on the per-type rdata grammar. Parsing, canonicalizing, and rendering the rdata of each record type is runciter's job, the sibling that owns the DNS protocol knowledge. Only the rdata crosses the boundary: on the write path record->rdata-columns renders a record's rdata to canonical text through runciter:render-rdata, and on the load path row->resource-record (src/operator-state/zones.lisp) builds the resource-record envelope from valis's own typed columns while handing the rdata text to runciter:parse-rdata to type it. valis re-parses no resource-record syntax of its own. This keeps a single authority for the wire grammar (the same authority the nameserver composes through and the real wire engine encodes through), so the bytes the nameserver serves and the bytes a zone transfer would carry cannot drift apart. The published master-file text an operator reads back is rendered from these same structs through runciter's canonical-line renderer, so a round trip through the substrate is byte-faithful.

A DNS wire engine does not bind by being named in a config file; it binds by passing the same owner-vouched content-hash admission gate every other pluggable module passes. admit-and-bind-dns-module (src/edge/dns-controller.lisp) delegates admission whole to the module-admission chokepoint (the content hash, the owner :admit vouch, and the revocation/fence check) and introduces no new trust path of its own. Only on a successful admission does it bind the adapter over valis's data source; an unvouched or revoked hash is refused fail-closed, the module loader is never called, and the adapter registry is left byte-identical to its pre-call state.

The bind registers the nameserver's serving handler: bind-dns-view (src/edge/dns-controller.lisp) takes valis's pg-zone-source, builds runciter's handler over it via (make-dns-service-handler <source>) (runciter's builder symbol resolved late by find-symbol in its package, the same late-binding idiom the serving seam uses, so valis carries no hard import of a serving symbol), and registers that handler under the adapter name. The serving contract version is asserted equal to valis's +dns-adapter-contract-version+ at bind, fail-closed: a missing builder or a version skew signals rather than binding a wrong-shaped or absent handler. Because the handler holds its own source and pulls its own refresh, the bind is a single registry mutation (there is no separate serving view to offer), and it preserves the no-partial-bind discipline on that mutation: a post-bind self-check funcalls the handler once, and on any failure bind-dns-view restores whatever adapter held the bound name before the attempt rather than blind-deleting it, while admit-and-bind-dns-module restores the whole registry it snapshotted before admission. The result code from a refused admission is the absence of a binding, not a half-built one. Handler construction runs inside a pooled operator-state connection when the pool is armed (the eager index build reads PostgreSQL) and bare otherwise, so an in-memory test bind needs no database.

A decoded query therefore traces these seams in order: the wire adapter is fetched from *dns-adapters* by name and its handler invoked with (name, type, class); the handler is runciter's serving handler, which composes the answer over its own index (loaded from valis's pg-zone-source) and returns (record-set, rcode); the adapter hands that back to the wire for encoding. No port 53 and no binary codec runs inside valis on that path, and no answer logic runs inside valis at all: the proof drives the whole chain through the registered runciter handler in dns-bind-resolves-query-through-runciter-handler, so what is exercised is the production wiring through the real nameserver, not a view in isolation.

The binary wire engine (the RFC 1035 codec, port-53 serving with response-rate limiting and non-recursion, zone-transfer and NOTIFY, and the resolver client) is the sibling DNS engine's responsibility and is stubbed here; the conformant wire transcript is that engine's acceptance gate, not this substrate's. The nameserver's index warms at handler construction (an eager build over source-origins + zone-record-set) and is kept current by its throttled pull; valis's job is to keep the data seam answering and to fire the change signal on commit. Deeper wildcard closest-encloser synthesis, delegations with glue, and DNSSEC signing are additive through a contract-version bump and the fail-closed version check, deliberately out of the v1 flat-authoritative-zone scope.

Each property is anchored to a named test. valis-side coverage proves the data read seam, the cutover facets answerability turns on, the capability gate and its no-partial-state unwind, and that the bind dispatches a decoded query through the real runciter handler. The answer-composition decision tree and the serve-last-good availability property are runciter's (composition relocated to runciter's compose-answer parity suite [parity-checked branch-for-branch against valis's prior zone-view-lookup before the shed], serve-last-good to runciter's refresh suite) and are cited below so the auditor can follow the data/answer split to its other half.

valis-side:

Relocated to runciter (the nameserver's suite), cited for the auditor:

The primary-zone story above is valis answering names it authored. The substrate also answers names it did not author (a legacy zone fed in from an upstream master during a migration onto valis) and feeds its own zones out to downstream secondaries. That secondary operation is a clean split between two owners. valis owns the durable state (the zone rows, the provenance and lifecycle facets, the crash-safe timer deadlines) and the operator door that flips a zone through its lifecycle. The sibling library runciter owns the pure logic (whether a transfer is admissible, what the served-type set is, how an SOA refresh-timer advances, which cutover transitions are legal, and whether an entry may answer right now) and the serving index that answers from it. valis never re-implements any of that.

valis reaches the logic through a single late-binding seam, src/operator-state/runciter-serving-seam.lisp, and never through a runciter symbol directly. The seam declares the contract (accept-zone-transfer, advance-refresh-timer, cutover-transition-legal-p, may-answer-p, effective-status, out-of-set-records) and resolves each real runciter symbol at call time, delegating directly. runciter is a hard dependency that delegates every target live, so the seam carries no valis-side fallback: a pinned-but-missing symbol fails closed (runciter-serving-unavailable) rather than serving a stale local answer. The point of the seam is that the DNS-semantic vocabulary has exactly one home: the secondary door and the cutover door speak to this package, so the day a newer runciter ships a sharper policy the substrate picks it up with no caller change and no second copy of the rule to drift.

:names is not a DNS table that happens to be called a naming database: it is a general naming database (a Plan 9 ndb analog) whose first record class is a DNS zone. The cross-cutting facets that describe any named entry (who controls it versus who authored its data [=authority-state=, provenance-kind=], the lifecycle position [=cutover-state=], the monotonic version, and the crash-safe SOA refresh-timer state) live on the =ndb-entry anchor (src/operator-state/ndb-entry.lisp), keyed by (name, kind) and agnostic to the record class. The DNS-typed dns-zone projection is the typed face of those facets for kind "dns-zone": its origin is the anchor's name.

This is a deliberate altitude choice, not incidental layering. Modelling provenance, write-authority, and version at the ndb-general altitude rather than as DNS-only columns means a later record class (an identity or federation entry) attaches to the same anchor with no schema migration. A one-time backfill seeds every existing zone as a primary / operator anchor, so the general model is populated from the DNS class that motivated it without a flag day.

A secondary transfer arrives in-process from the wire engine as a flat sequence of already-decoded, runciter-typed records. ingest-secondary-zone (src/operator-state/secondary.lisp) authorizes it against the upstream-master principal (an operator-curated allowlist of public master references, one per zone) fail-closed, and it does so before the instance fence and before any write. The session or owner principal that happens to drive the ingest never enters the authority decision: control of a zone is not authorship of its data, and an in-process transfer has no meaningful mounting principal to vouch for the bytes. A master that is not on the zone's allowlist signals upstream-master-not-allowed and commits nothing: the refusal precedes the transaction, so a refused or un-allowlisted master cannot leave a partial zone behind.

An allowlisted transfer still has to be admissible. The DNS-semantic decision (the served-type set, SOA presence and uniqueness, serial sanity) is runciter's, consumed through the serving seam's accept-zone-transfer. A record whose type falls outside the served set refuses the whole transfer atomically (:refused-out-of-set-type); the offending (owner . type) pairs are named for the operator and the audit surface through the seam's out-of-set-records helper, single-sourced in runciter's own admission predicate so valis never re-derives or re-scans the served set on its own. An accepted transfer commits through the shared commit-zone-records door with a :secondary provenance and a :held cutover state, so the same fence-first, RFC 1982-monotonic, full-zone-replace transaction the operator text path uses runs here too, and no serving-view install runs, because a held secondary is tracked but does not answer.

A migrated zone moves through three lifecycle states (:held, :answer-as-secondary, :primary), and valis flips it only on an explicit operator write. The two forward transitions ride the capability-gated :names /ctl control surface (src/namespace/names.lisp): an axis-level declare-secondary verb bootstraps a cold held zone (creating the held shell and the master allowlist entry in foreign-key order so the very first transfer can self-authorize), then a per-zone answer-as-secondary verb makes the zone answer from the upstream's data, and finally promote-to-primary makes valis the system of record for it. Each verb is an ordinary owner-gated 9P write whose clunk is the commit, exactly like a zone import.

Legality is runciter's, not valis's. commit-cutover-transition asks cutover-transition-legal-p through the seam whether the requested flip is a legal forward step from the persisted state; an illegal or out-of-order flip signals illegal-cutover-transition and persists nothing, and valis never advances a zone's state on its own initiative. A held secondary never answers: it surfaces :held through zone-cutover-status, and the nameserver refuses to answer it; the gate that enforces this is structural, described next, not a convention each caller must remember.

Two invariants keep a non-authoritative zone from ever answering when it should not, and under the data/answer split they straddle the seam: valis owns the facts, runciter owns the gate, and the flip door owns a write-time refusal.

The data valis owns is the cutover-status pair. zone-cutover-status surfaces a zone's (cutover-state, expire-deadline): :held for a not-yet-answerable secondary, :answer-as-secondary with its absolute epoch-second expire-deadline, or :primary with a NIL deadline (a primary never expires; valis is the system of record). The deadline is persisted as an absolute instant (the ndb-entry timer columns, written through persist-refresh-timer-state), never an uptime offset, and the read is fail-closed: an unstored origin, and a secondary with no recorded deadline, surface no answerable deadline. The nameserver gates on this (runciter's may-answer-p treats a :held zone, an expired secondary, or one with no deadline as not answering, and an expired owning zone as not owning the name at all), so a :held or expired secondary cannot answer regardless of which path loaded it. These choices are load-bearing: a restart must not silently extend a secondary's lifetime past the expiry it inherited from its last transfer, and a master gone unreachable must eventually cause the secondary to stop answering rather than serve stale data forever. The valis side of this guarantee is verified in tests/cutover-status-source-test.lisp (the :held, absolute-deadline, primary-NIL, and fail-closed cases); the gate itself is runciter's may-answer-p parity.

The flip door adds a write-time refusal: a flip to :answer-as-secondary is refused (secondary-timer-not-ready) unless a populated, non-expired deadline already exists, checked against the live clock (*zone-view-clock*, the surviving serve-time absolute clock in src/operator-state/zone-view.lisp, Unix epoch-seconds), so a secondary can never even be made answerable with a stale or missing timer.

valis is also a source of zones for downstream secondaries, and that outbound side is pure in-process data. src/operator-state/zone-feed.lisp holds an in-process listener registry (*zone-change-listeners*, mirroring the DNS-adapter registry with the same register-time fail-closed contract-version check) that fires off the shared zone-commit point: commit-zone-records invokes its post-commit hook after a durable commit, and the feed installs fire-zone-change onto it. Because both the operator text-import path and the secondary-ingest path converge on that one door, a committed change on either path emits a single change signal with no per-door wiring; a cutover flip emits the same signal from its own commit point. A downstream secondary-peer allowlist (zone-feed-peers, the secondary_peer table) gates the data side, so the feed never offers a zone to an un-allowlisted peer.

The registry is fault-isolated by construction. fire-zone-change runs each listener under its own handler so a listener that signals is warned and skipped, its siblings still fire, and the error never unwinds out of the post-commit hook: an out-of-tree consumer throwing cannot turn a durably committed transfer into an apparent failure. This is strictly the data side: whether a given change warrants an actual wire NOTIFY, and the binary AXFR-out that carries the zone, are the sister DNS engine's concern, not the substrate's.

The secondary substrate holds no wire and no secret. There is no port-53 serving loop, no binary AXFR codec, and (by construction) no transport-secret or TSIG column anywhere in its schema: every reference it stores is a public master or peer name or address, and the transport secrets that authenticate a real transfer are the factotum's domain (mercer), never :names's. The record boundary is the same one the primary path observes: the typed envelope (owner, TTL, class, type) is valis's, the per-type rdata grammar is runciter's, and only the rdata text crosses between them. A record whose stored rdata is malformed fails closed at the node read boundary: %render-zone maps runciter's typed rdata-parse error to a clean 9P protocol error scoped to that one zone, rather than letting an arbitrary Lisp error escape past the read into the serve path.

Each guarantee of the secondary substrate is anchored to a named suite. Together they pin the authorization boundary, the held-never-serves invariant, serve-time expiry, the outbound feed's fault isolation, restart-safe deadlines, and the read-path typed guard.

The hostile edge is the part eating untrusted input, so the long-term target is to run edge modules as sandboxed OS processes that reach the core only over 9P with their narrow capabilities: a compromised edge process then holds nothing but its own anonymous-scoped authority. The near-term implementation keeps edge and core co-located in one image with a logical boundary (fast to build), hardening the anonymous path first.

The durable commitment that makes this an evolution rather than a rewrite is that the edge↔core boundary is a 9P/capability interface from the start, never a shared-memory assumption. Co-location is then 9P over an in-process transport; isolation is the same 9P over a pipe between processes. This is the same discipline applied to the event multiplexer (epoll now, io_uring later) and to module placement (local thread or remote node): design the seam at the eventual boundary, implement the cheap version first.

The seam is a single module (src/edge/seam.lisp) and it is the only place an edge module reaches the sovereign core. An adapter never touches the namespace directly; it asks the seam for the view its connection is entitled to and walks that. The entitlement is the connection's principal and its request-scoped capabilities, carried across a real 9P interface: the same attach, walk, and read a remote 9P client performs, with no privileged shortcut.

The seam holds one live attach per principal class, not per connection. Every anonymous connection shares a single cached attach to the public view, because they are all the same principal and opening a fresh 9P session per request would be ruinous on a busy port; a keyed principal, when keyed edge service arrives, gets its own attach through the identical mechanism. The cache key is the principal class rather than the principal object, because the anonymous sentinel and a keyed principal are the same Lisp type: only the class of authority distinguishes the slots.

A second, deliberately separate path serves the request-scoped phase: the with-request-capability entry point mounts a capability surfaced inside a request into a fresh private per-request view, runs the request body bound to that view, and unmounts on the way out, including on a non-local exit. The private view is not the shared cached attach, and the reason is a concrete leak it forecloses: mounting into a shared view would make one connection's request-scoped grant briefly visible to every other connection on the same principal. A per-request view is structurally incapable of that cross-connection disclosure: the mount lives and dies inside one request's dynamic extent.

The transport under the seam is a rebindable factory: *edge-channel-factory* is a function returning the two endpoints of a channel, defaulting to an in-process channel served against the assembler root. Rebinding it swaps the transport with no change to any adapter: the co-located case (an in-process channel), a TCP loopback to the fabric's own 9P listener, and a real inter-process socket pair have all been driven through this one point, each serving the same publication byte-for-byte. An adapter names no transport symbol at all; it imports only view-for from the seam. That import boundary is what makes "co-located now, sandboxed later" a binding rebind rather than a rewrite.

The public edge runs on exactly one bearer grant. At fabric start (src/fabric.lisp), start-fabric mints a single edge-wide capability name designating the public view with read-only rights and installs it as the anonymous grant; the seam attaches against it on first use. There is no per-adapter grant and no per-connection minting: one name is the entire public authority, and an auditor can find its single mint site and its single designation.

Because that one attach is long-lived, the seam has to survive losing it, and it discriminates why the view was lost before deciding what to do. The discriminator is membership in the revocation store. If the grant's hash is in the store, the loss was a deliberate unpublish: the view goes dark and stays dark (walks fail, adapters serve absence) until the operator re-establishes the public view. The seam never silently re-mints a revoked grant. Any other loss (a closed session, a dropped channel, an expired grant) self-heals: the heal path consults the revocation store first and re-checks it on every retry (so a revocation landing mid-heal still wins), re-attaches with a bounded inline retry, and re-mints through the grant's mint hook only on genuine expiry. The re-mint can therefore never resurrect a revoked grant, because the store is consulted before the mint is reached.

Sovereignty on the wire is the absence of a name, not a policy refusal. When an anonymous caller names anything outside the public view, the walk simply fails, and the adapter surfaces that failure as the protocol's own absence response: an HTTP 404-class answer, a Gopher type-3 error item. There is no "permission denied" code path at the edge to disclose that a thing exists but is forbidden; the owner's axes have no name in the anonymous view, so the only honest answer is that they are not there.

The edge controller (src/edge/controller.lisp) binds and unbinds the edge ports through start-edge / stop-edge, riding the listener's already-running event loop rather than owning a listener of its own. Dispatch is purely port-addressed: a connection's recovered destination port selects its protocol module through the registry, exactly as the central abstraction promises.

The bind order is fail-closed, and the gate is a real resolution, not a presence check. Before start-edge binds a single port it asserts the fabric is up, the anonymous grant is wired, and a real view-for for the anonymous principal can attach and walk the public view through the seam. A grant string that decodes but no longer resolves (revoked, or pointing at a view that has gone dark) fails this gate, so the edge refuses to come up serving a public face that cannot actually be reached. No namespace means no open port. Binding a port here opens it only for dispatch, though: whether that port is reachable from off the host is a separate, privileged decision at the host agent's firewall, not a consequence of the edge binding it: see The public surface. Teardown runs in strict reverse: stop-edge closes the ports before the seam resets, so the wire stops feeding a session before that session is torn down, and a mid-start failure unwinds whatever bound in reverse order.

The one construction point a later phase rebinds is named and isolated: *edge-source-constructor* builds each port's event source, defaulting to a plain bind, and is the seam where a steered file descriptor handed over by the privileged host agent arrives. The resident boot already rebinds it (src/main.lisp), so the edge binds a source around a passed-in fd instead of opening its own, with nothing else in the controller changing. Alongside the wiring, the controller publishes a read-only /edge status subtree (src/namespace/edge.lisp): a directory per bound port carrying live connection, budget, and deadline-cut counters rendered fresh on every read, plus an anonymous file reporting whether the public view is unwired, dark, undetermined, or serving. Undetermined is kept distinct from dark because the two want different repairs: dark means the grant was found revoked and is answered by minting a fresh one, while undetermined means the node could not establish whether the grant is revoked at all, refuses to serve on that, and would be no better off with a fresh grant. The subtree is observable as ordinary files, and it is named only in the owner's canonical frame: an anonymous attach cannot walk to /edge at all, so the diagnostic surface is itself sovereign.

The edge faces the open internet, so abuse defense is layered, and the layering is deliberate: each defense lives at the tier that can express it most cheaply, and none of it lives in the sovereign core.

At the adapter tier, each connection carries a read deadline and a hard cap on input size: a client that connects and sends nothing, or dribbles bytes slower than the deadline, cannot hold a handler thread, and an oversized request line is refused rather than buffered. At the edge tier, each bound port carries its own concurrent-connection budget. When a port reaches its budget the controller stops accepting on that port: it deregisters the listening source, so overflow connections wait in the kernel's listen backlog and no valis thread or write is ever spent refusing an over-budget client. A connection's whole lifetime is wrapped in one place in the controller (never in adapter code), so the live count is decremented on every exit path (normal, error, or deadline cut) and the port re-arms its accept as soon as a slot frees. A flood on one protocol's port cannot starve another, because the budgets are per-port. The third tier (per-IP tracking, rate limiting, and volumetric or amplification defense) belongs to the privileged host agent that sits in front of valis, outside the process entirely.

The rationale for the split is the sovereignty invariant. Per-IP and volumetric defense need a view of the network the unprivileged, migratable valis process deliberately does not hold, and the sovereign core must carry no abuse logic at all: the core moves and mounts views, it does not reason about hostile traffic. Pushing the outermost defenses to the host agent and keeping only connection-occupancy and per-port budgets inside valis keeps the core clean while still bounding what a single open port can consume.

Nearly everything the edge serves today is request shaped: a client connects, says what it wants, is answered, and goes away. The connection exists to carry one exchange and has no reason to outlive it. For that traffic the shape described above is the right one and is deliberately unchanged. A thread per connection is cheap when the thread lives as long as one short exchange; a per-port concurrency budget is a true measure of work in flight when every live connection is work in flight; and a wall-clock deadline is a sound liveness test when silence past the deadline means a client that was never going to finish.

A protocol whose connections are long lived, mostly idle, and written to unprompted breaks all three at once, and it breaks them for one reason rather than three. The thread cost, the per-port budget and the one-shot deadline read as separate limits, but each is an expression of a single assumption nobody had written down: a connection lives exactly as long as the request that created it. The table below states that assumption and its relatives plainly and disposes of each. The disposition is rarely a removal. Most are SPLIT: the request-shaped path keeps the shape it has, and a protocol that declares itself continuous gets the other one. A protocol declares which it is; the seam never guesses.

The dispositions above leave a set of design questions that each have exactly one answer. They are recorded here so the implementation does not re-decide them one file at a time.

Where the send-queue cap is tested

The cap is tested against the length the queue would have once the message is added, before the message is buffered. The reason is arithmetic rather than taste: testing the already-queued length bounds the queue at the cap plus one maximum message, and no maximum message exists on this path, so that placement bounds nothing at all. src/transport/client-secure-endpoint.lisp:148 is the precedent already in the tree, rejecting an over-long declared length before any body is read.

A message larger than the whole cap

A single message that exceeds the entire cap is refused outright rather than split across several sends. The reason: splitting does not reduce the bytes the queue holds, and the seam has no producer it can pause part way through a message, so splitting would relabel an unbounded hold rather than bound it. That refusal is reported distinctly from an ordinary over-budget refusal, because an over-budget send can succeed on a later attempt once the queue drains and this one can never succeed at all.

Who closes on a breach

Closing a connection that breaches the cap is the edge's act and never the protocol module's. The reason: the queue and the cap belong to the edge, and a component cannot enforce a bound it does not hold. What this leaves with the module is an obligation rather than a power. It must notice that a send was rejected, and must never assume a send lands.

The cap is not the only backpressure

A bulk producer can read how full the queue is and suspend itself at a fraction of the cap, which makes the close a last resort instead of the only one. The reason: a producer that can pause is far cheaper to stop than a connection is to lose.

A registration timeout is not an idle timeout

These are two different mechanisms and are kept apart deliberately. The registration timeout runs from the moment the connection was established and is not reset by activity, while the idle timeout runs from the last activity and is paired with a protocol-level probe that asks the peer to prove it is still there.

A session with no liveness probe

A session whose protocol offers no way to probe the peer gets no idle cut at all, and only the registration timeout applies to it. The reason has to be stated out loud because the opposite is the tempting default: cutting an idle session that cannot be probed reinstates the wall-clock cut on exactly the connection that is idle by design, which is the mechanism this work exists to replace. Such a session ends when its peer goes away or when the edge tears its port down, never on a clock.

The send path copies

What a caller hands the send path is copied at the moment it is handed over, and never retained by reference. The reason: the per-session read buffer is reused on the next read, and a short write leaves queued bytes waiting across callback boundaries, so a caller echoing straight from a read into a send would otherwise ship whatever arrived next. The cost is one allocation per enqueued message, and it is reported as a measured per-unit figure rather than left implicit.

Every sizing constant here is provisional

Each sizing constant this seam introduces says so in its own docstring, and each is derived from a bound measured in this tree rather than adopted from another implementation. The reason: asymptotic shape is a design-time decision while constants come from profiling this system, so a number borrowed from a daemon carrying different message sizes would be a guess wearing the authority of someone else's measurement.

Each edge success criterion and security property is anchored to a named test an auditor can run. The acceptance suite drives plain loopback TCP clients against fully shipped wiring; the seam and controller suites exercise the seam internals and the budget machinery directly.

The edge faces the anonymous internet, but one caller on the same port is not anonymous: the owner. The owner reaches a management view by proving possession of the custody master key on every request, not by presenting a token. Each request the owner makes is an HTTP Message Signature (RFC 9421): the owner signs the canonical request material with the same Ed25519 custody key that roots all valis authority, and the edge verifies that signature against the owner's public key. This is the deliberate choice that separates owner authentication from the anonymous grant. A bearer token is replayable by anyone who holds it (which is exactly the anonymous /pub model, an unscoped grant pointed at a public view), and pointing a bearer model at the management view would let a token-holder act as the owner without ever holding the owner's key. A live per-request signature cannot be lifted and reused, and it carries no server-held session state to leak or to outlive its purpose: the proof is the key-possession itself, re-demonstrated each time.

Verification routes through the same single seam the rest of identity admission already uses. The authenticate generic in src/identity/authenticator.lisp is the one named operation that turns a completed proof into a principal; the Noise handshake is the first method on it and the anonymous resolution is the second. The seam was built reserving exactly a third method for an HTTP-edge proof, and this is what fills it: a signature authenticator specialises authenticate to mint the owner principal from a valid signature, with no code above the seam changing: the connection layer, the capability layer, and the namespace mounter still see only a principal and never learn what proved it. The verifier itself lives in src/identity/http-signature.lisp: it reconstructs the RFC 9421 signature base over the covered components (the request method, the request authority, and the request path) through the same base builder the owner's signer used, so the bytes signed and the bytes verified are identical by construction and cannot drift apart into a canonicalization mismatch. It checks the signature's key identifier against the owner DID and verifies the Ed25519 signature against the owner public key.

The custody boundary holds at the edge exactly as it does everywhere else: the edge module relays only the signed request material (the method, the authority, the path, and the two signature header values) to the seam, and never sees a key. Verification needs only the owner public key, which is already in the image on the factotum side; the private custody key never crosses into the edge tier, and no ambient authority is granted to a module that eats hostile input. The replay defence is twofold and lives with the verifier: a bounded acceptance window over the signature's created / expires stamps rejects a signature presented too early, too late, or long after it was minted, and a bounded, expiry-pruned nonce cache rejects a second presentation of a nonce already seen inside the window. A signature that is absent, malformed, signed by the wrong key, expired, or replayed does not raise an error and does not reach management: every such failure resolves to the anonymous principal, so the management view is reachable only by a valid, live, first-use signature. Falling open to anonymous, never to an error and never to elevated access, is the fail-closed posture carried to the auth path.

Anonymous and owner walk the same URLs on the same port. What differs between them is not the path they ask for but what is mounted under it. The anonymous caller resolves to the published view: the /pub scope, the same public face the anonymous grant has always served. The owner, once a valid signature has resolved to the owner principal, resolves to the full sovereign canonical frame (/pub /id /cap /edge /bus) rendered as a browsable read projection. The discrimination happens at one site: view-for (src/edge/seam.lisp) hands every non-anonymous principal to build-base-view (src/namespace/assembler.lisp), which dispatches the owner DID to assemble-canonical-frame server-side; the seam re-implements no identity comparison of its own. The HTTP adapter then walks an identity-dependent root: the anonymous request walks under the /pub scope, the owner request walks the canonical frame directly, because for the owner that frame is the root. The principal is re-resolved for each request and never cached on the connection, so under a persistent connection a signed request and a later unsigned request on the same socket each resolve their own principal and their own view; a signed request cannot infect an unsigned one that follows it.

This is sovereignty expressed as absence, carried now to the HTTP wire. An anonymous caller does not receive a permission refusal when it names a management axis: it has no name for one. The management names are simply not mounted in the anonymous view, so a walk toward them fails the way a walk toward any non-existent name fails, and the adapter surfaces that failure as the protocol's own not-found answer. There is no code path at the edge that says a thing exists but is forbidden, because such a path would itself disclose that the thing exists. The honest answer to an anonymous caller reaching for the owner's axes is that, in its view, they are not there.

The published view is served by a real HTTP/1.1 server, not a thin compatibility skin, so an ordinary client treats valis as an ordinary origin. The surface is deliberately bounded to the read path. A Host header is required and validated: an HTTP/1.1 request that omits it is answered 400, per the messaging specification. GET and HEAD are served, with HEAD returning the computed headers and no body; any other method is answered 405 with an Allow header. Connections are persistent, framed by Content-Length, with Date and Server on every response and the real status taxonomy (400 / 404 / 405 / 408 / 411 / 505 alongside 200 / 304). Conditional requests are answered from the substrate's own version stamp: the 9P qid.version of the addressed leaf becomes a strong ETag, and an If-None-Match that matches it yields 304 Not Modified with the validator and no body. That mapping is the substrate-alignment win: an ordinary HTTP cache works correctly against the sovereign namespace because the namespace already carries the exact per-node version a validator needs. That version is now derived from the node's content score (the low 32 bits of its Merkle hash; see the read-side caching tier), so the ETag is itself a content hash rather than an opaque counter, the content-addressed norm a strong validator is meant to be. A body mutation changes the leaf's score, so its ETag changes with it, and a conditional GET that no longer matches gets a fresh 200 carrying the new validator. The write-path long tail of HTTP/1.1 (chunked request bodies, =Expect=/100-continue, request pipelining) is out of scope by design: it bites almost entirely on request bodies and writes, and this is a read server.

The conformance surface composes cleanly with the edge abuse posture documented above rather than weakening it. A persistent connection holds exactly one of its port's concurrent-connection budget slots for its whole lifetime, while the per-request read deadline re-arms at the top of every request on that connection. The two together give the right behavior under keep-alive: a slow or dribbling client is cut by the deadline on the request it is starving, without a healthy persistent connection being dropped between requests, and the per-port budget continues to bound a flood of connections regardless of how many requests each one carries. The existing guards remain in force on the new surface as well (every response header value passes through the response-splitting guard before it is emitted, and every request path passes through the traversal-safe decode before it is walked), so the broadened method, header, and conditional-request handling adds no new injection or traversal surface.

Each HTTP-edge criterion is anchored to a named test an auditor can run. The conformance cases drive plain loopback HTTP clients against fully shipped wiring; the owner-proof cases drive an in-image RFC 9421 signer over the same loopback; the signature unit verifies the cryptographic round-trip directly.

The fail-closed bind order above names *edge-source-constructor* as the one construction point that is rebound to a steered descriptor. That descriptor arrives by a deliberate trust choice, and the choice is the load-bearing security property of the whole steering arrangement: valis hands a descriptor out; the agent never reaches in.

valis creates and owns its listening socket (it is the only party that calls bind and listen), and the socket reaches the LISTEN state inside valis's own unprivileged process. To let the privileged host agent steer traffic to that socket, valis sends the agent a duplicate of that one descriptor as an SCM_RIGHTS ancillary message over the very Unix-domain connection the 9P control session already runs on. There is no second channel: the same AF_UNIX transport carries both the in-band 9P frames and the out-of-band descriptor. valis chooses exactly which descriptor crosses the boundary, and nothing else of valis's descriptor table is exposed. This is consent expressed as a capability: possession of the passed descriptor is the entire grant.

The rejected alternative is what makes the choice legible. The kernel also offers an agent-pull path: the privileged process could open valis's process descriptor and lift a descriptor out of its table directly. That was refused on purpose: it would grant the agent the standing authority to reach into an unprivileged process and take any descriptor, a far broader and more durable trust than "valis decided to send you this one socket." The push model grants the minimum; the pull model grants a reach-in. The seam where the inherited socket lands wraps it without re-binding (an already-LISTEN descriptor cannot be bound again), so the steered source is the same event source the bind path builds, recovering the dialed destination port exactly as the ordinary listener does (see Edge wiring and the fail-closed bind order, and the four-tuple preservation the listener relies on in the steering layer).

The descriptor crossing is also strictly sequenced against the 9P stream, not concurrent with it. valis declares its port set over 9P first; the control service advances a handoff gate to a ready state only after a valid declaration; then the standalone descriptor message crosses while no frame is in flight. The order is what keeps the zero-data ancillary message from racing the length-framed 9P bytes on the shared socket, and it is why the agent never holds a descriptor it has no port contract for.

sk_lookup selects a socket per network namespace. The kernel runs the steering program only for traffic in the namespace the program's link is attached to, and it will only select a socket that lives in that same namespace. valis's listening socket and the agent's link must therefore share one namespace, or the steer silently never fires: load succeeds, the socket map is populated, the link attaches, and connections are still refused, with nothing in any log to point at.

This constraint is also the unit's boundary of authority, though it bounds what the steer can offer rather than what the unit answers. The steering program is a catchall: it fans every port on the unit's IP out to valis's one socket, so the namespace and the IP it carries fix the traffic that can be offered at all. That is not the answered set. A valis unit declares the ports it intends to serve, and on a routable IP the catchall does not narrow what it offers to that declaration. What narrows the reachable set back to the ports the agent admits is a separate control, the agent's default-deny firewall inside the namespace, and not the namespace itself. On a loopback-only island the two coincided and the namespace was the whole boundary; once the namespace carries a routable address they are two mechanisms, and the surface control is the firewall. This is the subject of The public surface, including why the allowlist must stay the agent's and never a module's. The first-cut topology resolves the shared-namespace requirement the simplest correct way: the agent creates the namespace and the unit's IP, then valis is launched into that namespace so its socket is born in the right place.

Every capability that needs the kernel's trust lives in the external host agent and only there. CAP_BPF to load and attach the steering program, and CAP_NET_ADMIN (with CAP_SYS_ADMIN) to create the namespace and assign the unit's address, are held by the agent, a separate component in a separate repository. The migratable valis unit holds none of them. The privilege boundary is therefore not a runtime check that could be misconfigured; it is a boundary drawn in the filesystem, where an auditor who wants to know what runs with elevated privilege reads one repository and a compromised valis unit cannot reach for authority it was never granted.

This is the same property described in the edge abuse posture (the outermost, network-aware defenses belong to the agent because the unprivileged unit deliberately cannot see what they need), stated here as a privilege invariant rather than an abuse one. The steered socket needs only LISTEN state, nothing privileged: valis binds loopback or an ephemeral high port inside the agent's namespace and never binds the designated public ports. That valis holds no privileged kernel state is the very property that makes it migratable, because there is nothing host-specific for it to carry; on migration the destination host's agent re-establishes the steer so the arriving unit answers its ports again. The dialed port survives the steer because the kernel preserves the original four-tuple under bpf_sk_assign, so getsockname on the accepted socket recovers the real port the client dialed, the same recovery the listener already proves over loopback (see the fail-closed bind order and the four-tuple commitment in the listener section).

The steering data path cannot be exercised from the Lisp image, since it needs a real kernel, a network namespace, and CAP_BPF=/=CAP_NET_ADMIN. The image-testable glue (descriptor framing, port declaration, the seam's recovered-port wrap) carries cold in-suite coverage. Past that there are two out-of-band gates rather than one, and they cross different boundaries. make steer-test runs in the agent's repository on the privileged side, signed off out of band exactly as the v9fs mount interop test is. The proving ground's steered-delivery gate builds a node and then drives it from a separate host, which is what puts a real off-host client on the far side of the steer and lets it read the delivery off accept queues rather than off an answer. The agent repository's docs/steering.org carries the same coverage table from the privileged side.

The substrate models the semantic object (a message, a contact, a publication, a contract), and the wire protocols are projections over it. This is the mechanism behind the doctrine's claim that "messaging is one thing": SMTP, IMAP, and NNTP are not three stores but three skins over a single message substrate; a message is the same object whether it arrived by SMTP or was posted by NNTP. Publishing (web, forum, and social protocols) likewise projects one publication substrate. The substrate de-duplicates reality; protocols are views onto it. This is how the protocols are "given back": the user owns the object and chooses which protocols answer for it.

A protocol module (the edge tier) is therefore a wire-format adapter between an IETF protocol on its port and a semantic subtree of the namespace, gated by the connection's capabilities. The substrate is protocol-agnostic; the protocol is storage-agnostic; they meet at the namespace.

• Foundation - crypto (1), names (2), identity (3). Every other category reaches these. Crypto is the autonegotiated, invisible-by-default layer the capability model already rests on: the factotum-shaped agent, content encryption, transport security, key custody. Names are the user's sovereign namespace of people, places, and things; identity is the user's own, canonical and transient. Identity is where the principals the connection layer authenticates come from, and names and identity are who capabilities are granted to.
• Data - data (4): the relational and reactive store over the migration backing store; the queryable substrate the semantic domains build on.
• Semantic domains - messaging (5), publishing (6), contracts (7). Each is one substrate with many protocol projections. Publishing's public face is the unencrypted, content-addressed path served from many places; contracts (services and payments) is the most forward category, capability- and crypto-adjacent.
• Composite - composite protocols (8) such as IPFS and GNU Social are assemblies of the layers below (content addressing; identity, publishing, and messaging, federated). Their place at the top confirms the stack.

Content-addressed storage (IPFS) doubles as how a migratable instance stays coherent across hosts. There is no native Common Lisp libp2p/IPFS stack; the intended path is CFFI bindings to a libp2p built as a C-ABI shared library, with an external-daemon HTTP bridge as an interim stopgap and a fully native implementation as a long-horizon ideal.

Framed: the layering, and that the substrate models semantic objects with protocols as projections. Open, and recorded as research questions: how richly a semantic object must be modelled so a protocol projection is faithful rather than lossy (email threading, NNTP groups, social-graph semantics); what the data engine actually is in Common Lisp; whether names is one model with two faces (a sovereign address book that also answers DNS); and the shape of the contracts category. These are named so each domain is built against shared substrate interfaces rather than re-inventing storage and identity per protocol, the discipline that keeps "their computer, their data" true.

A protocol module is a single ASDF system that is both an asdf:package-inferred-system (valis's one-package-per-file discipline, where each file's defpackage declares its own dependencies and the build graph derives from :import-from) and a modularize:virtual-module, a named, discoverable unit with a metadata store and a teardown lifecycle. The two are not rivals: one class is both, package-inferred derivation still fires, and the module's :packages grouping gathers the inferred sub-packages under one name. valis-core stays an ordinary system; only the pluggables become modules.

The core's one structural change is to stop naming concrete adapters. The edge controller's hard-coded adapter list (%adapter-specs) becomes an *edge-adapters* registry that modules install into on load, the same "downstream installs the hook" idiom valis already uses for *edge-source-constructor*, *ctl-node-factory*, and *bearer-view-decorate-fn*. A module declares its adapter in one line of module storage (an :edge-adapter spec); a load hook registers it; a delete hook drains then retires it. Drain-before-delete is not optional: a live protocol has in-flight connections, so the delete hook runs the ordered edge teardown (deregister the source, drain in-flight work, unregister) before the package is unbound. That drain is the same primitive evacuation uses: the session drain on the 9P listener. Two correctness disciplines fall out of the lifecycle: registration must be idempotent (the grouping form runs twice under compile-then-load), and a protocol's macros stay module-local: cross a module boundary with functions, not macros, because a reloaded producer leaves a consumer's already-expanded macro call site running the stale expansion, silently and without error.

Content addressing answers which module: a module package, held in the content-addressed store or fetched over IPFS, is named by its hash, so an instance pulls exactly the bytes it asked for and verifies them on read. But a hash answers identity, not trust. Loading a module means compiling and running code, and code pulled by hash from the network is, unqualified, a supply-chain hole: running code validated only by its hash is a recipe for pain. So which modules an instance will load and compile is a capability decision, gated by the same owner-rooted authority that gates every mount: a module is admitted only when the owner, or an authority the owner delegated to, has vouched for its hash, exactly as a capability vouches for a subtree. The hash is the name; the owner's signature is the permission. This keeps the "evaporate and condense elsewhere" malleability without turning a recondensing instance into an open code-execution endpoint, the discipline that matters most before the system is opened to outside contributors.

A valis instance is defined by two content-addressed manifests, not one. The namespace manifest records what is mounted: the data side, which migration already reassembles. A module manifest records what the instance is composed of: the protocol and plugin set it answers with. Both are durable, content-addressed, and reassembled on recondensation: a fleeing instance does not carry its code, it records the capability-vouched hashes of the modules it ran, and the destination pulls, verifies, and compiles them to stand up functionally equal to the instance that evaporated. Because the substrate already content-addresses data, it content-addresses the modules too, and IPFS becomes the distribution layer for protocols, not only a backend for bytes. modularize's in-image list-modules plus per-module storage is the live projection of this manifest; the durable module manifest is its persisted, migratable form. This closes the migration story for code the way the namespace manifest closed it for data: a valis instance is its mounts and its modules, both reassembled from hashes the owner vouched for.

The module manifest is a durable, content-addressed record distinct from the namespace manifest, and the distinction is the whole point. The namespace manifest records mount roots: what an instance has mounted, the data side. The module manifest records the module set as code: each entry is a system name, the module's ordered source files as paths relative to the module root, and a 32-byte content score over those bytes. Names and relative paths and a score: never a key, never a secret, never the vouch itself. The record is built once, its entries sorted by system name, so the same module set serializes to the same bytes regardless of discovery order; a content-addressed record demands that determinism. Decode is fail-closed: a bad width, an unknown version, a malformed entry, or a missing referenced byte stream aborts the read rather than yielding a partial set.

The two manifests are siblings (a manifest child and a modules child) under one durable head tree. At genesis they are written by a single combined publish that obtains both envelopes without advancing, builds one root tree naming both children, and advances the head exactly once. This is not a convenience: it is the only correct sequence. Two separate publishes cannot work, because the first advance moves the head off the genesis generation and the second's generation-fenced compare-and-set fails closed. So the manifests are atomic siblings by construction, and the evacuative reassembly that reads the modules child is correct precisely because the genesis publish guaranteed that child exists under the same root.

The record stores no vouch and no key, and that absence is deliberate. A credential frozen into a durable record would carry the authority lifetime of the moment it was written into a record that outlives it: a revoked owner key still vouching for code months later. Instead trust is decided fresh at reassembly: the owner re-vouches each module's score against live custody and live revocation/fence state at the moment of condensation. The record's job is to name which modules; the live authority decides whether to admit them. Authority lifetime is decoupled from record lifetime.

A successor instance stands its module set up from the durable record the same way the namespace assembler stands a namespace up from its manifest: reassembly, not transfer. The source instance does not hand its running code to the destination: it records the vouched hashes of what it ran, evaporates, and the destination re-derives equivalent running code from the record. This is the code-side symmetry of the data-side migration: an instance's identity is its mounts and its modules, both reassembled from hashes the owner vouched for.

The reassembly is two-pass and all-or-nothing. The first pass reads the manifest fail-closed. The second pass, over every record before any module loads, resolves the recorded relative paths against the destination's source root, pulls the bytes, re-derives the content score, and asserts it equals the recorded score: a wrong-hash record aborts the whole reassembly here, in front of the first load. The pull is transport-agnostic: a rebindable puller seam means the bytes can come from the local store today and from a content-addressed network (IPFS/libp2p) tomorrow without reshaping the record: the IPFS gate stays open. Then each vouch is located: the owner re-vouches each score against live state, and a missing vouch aborts the set. Only after the whole set passes does the third pass load, routing every module through the same capability-gated admission chokepoint that gates an interactive load, never calling the loader directly, so the gate is structurally in front of compilation. If any module is refused at the gate, the adapter registry is restored to its pre-reassembly snapshot, so an earlier-admitted module's adapter cannot leak past a later refusal. A partial module set never boots.

The resident default set (HTTP and Gopher) is handled honestly rather than forced through this path: it is recorded name-only with a zero score, is already present as part of valis itself, and is skipped by the reassembly. Only genuine non-resident modules (those carrying a real content score) run the pull-verify-vouch-admit path.

One claim must not be overstated. The resident default adapters are recorded name-only with a zero-score sentinel, because they are part of the valis system and are already loaded: there is no separate bundle to content-address. So the migration guarantee for the resident set is naming parity: a successor's recorded module set names exactly the source's set, and the resident edge registry the successor serves through names that same set. It is not content-score parity for those entries, and the documentation does not pretend it is.

The genuine content path (re-derive the score, match it against the record, locate an owner vouch, route through the admission gate) is exercised and proven by the non-resident scratch-module reassembly, not by the resident default. A reader who wants to see the score-to-admit guarantee should look at the non-resident reassembly test, where a module with a real content score is pulled, verified, vouched, and admitted, with an unvouched control proving the successor fails closed. The resident set proves the set-naming parity; the non-resident set proves the content gate.

The trust boundary the reassembly defends is the one between the durable record and the live authority that admits its modules. The record is published data (anyone who can read the store can read which modules an instance named), so the record holds no secret, and the decision to run those modules is made fresh against live state. The threats and the assertions that pin them:

The record shape and the reassembly are anchored to named tests an auditor can run and watch stand or fail. The record codec and its fail-closed decode are pinned in tests/module-manifest-test.lisp; the reassembly chokepoint's fail-closed, all-or-nothing contract is pinned in the same file's condensation suite; the end-to-end migration parity (a source instance records its module set, evaporates, and a successor reassembles it through the production path) is pinned in tests/migration-end-to-end-test.lisp.

Framed: that a plugin is a combined package-inferred module; that the edge controller iterates an installed *edge-adapters* registry rather than naming adapters; that module load is a capability decision over a content-addressed hash; that the active module set is migration-recorded alongside the namespace; and now the record shape itself: names, relative source paths, and a content score, sibling to the namespace manifest under one genesis root, carrying no stored vouch because trust is re-decided against live authority at reassembly. The modularize fit with the package-inferred discipline is settled and cold-verified, the idempotency trap mapped, and the reassembly proven end to end. Open, and the work the next arc takes up: the protocol adapters move to their own sibling repository, c3po (the home for every wire-format module a valis consumes) extracted on the discipline of real need rather than anticipation, with the existing HTTP and Gopher adapters relocated so the conversion proves the seam against their already-green tests; the production capture path that records a real non-resident module set at publish time (the reassembly and content gate are proven, the publish-side capture of a live non-resident set is the remaining wiring); and whether runtime unload is exercised in production or modules are load-once per image. These are named so the plugin layer is built against one uniform module abstraction (discoverable, lifecycled, content-addressed, capability-gated) rather than a bespoke registry reinvented per plugin kind.

A message body never enters PostgreSQL. It stays an opaque content-addressed block on the store, and the mail-transport-state row names it only by a content-hash pointer, body_ptr: an address, never invertible to content (the opaque-block view of the mail spine is detailed at the content boundary).

Threat. A confused deputy (an operations or migration path that could name, decode, or copy a body byte through the queue or state seam) would turn a substrate-management capability into a content read. That is the leak this boundary forecloses: operations moves and meters the spine and reaches no body.

Enforcement point. mail-transport-state (src/operator-state/mail-state.lisp) carries only body_ptr (a 64-char content-hash pointer) plus envelope and lifecycle metadata (no body or header column), and its package imports no body-octet reader (read-block / decode-file). The schema audit above bans any body/header column across the operator-state tables on every migration, so the row shape cannot regress.

Audit proof. The import-firewall sweeps ops-queue-projection-imports-no-body-read-symbol and ops-queue-grant-resolves-no-message-body-name (tests/mail-sovereignty-audit-test.lisp) prove the operations view reaches no body both by construction and over a really-queued message; the in-runner gate a-body-bearing-mail-migration-aborts and mail-state-migration-unit-passes-the-in-runner-audit (tests/operator-state-sovereignty-audit-test.lisp) prove the schema audit accepts the real mail unit and rejects a body-bearing one.

DNS zone data is published by design: the records are meant to be world-readable. The protected asset is therefore not secrecy but write-authority: who may mutate a zone. valis is the authoritative ndb data owner over PostgreSQL; the nameserver reads through a narrow read seam and composes answers, holding no write authority of its own.

Threat. Unauthorised zone mutation (a session or a confused deputy committing a zone change it does not own, or smuggling its claimed authority in through the submitted bytes) is the leak this boundary forecloses.

Enforcement point. The :names write gate stamps the owning principal from the session, never from the message bytes: node-create reads the session principal at submission (%current-submission-did, src/namespace/names.lisp) and node-close commits it as the zone's owner_did at the 9P clunk. owner_did is an allowlisted operator-state column carrying the zone's write-authority owner principal, and serving is a read-only projection over the committed data.

Audit proof. dns-schema-has-no-forbidden-column, ndb-facet-columns-pass-confused-deputy-audit, and existing-zone-backfilled-as-primary-on-ndb-anchor (tests/operator-state-zone-audit-test.lisp) prove the zone schema passes the confused-deputy audit and that the write-authority facet is carried as metadata, not content.

A read of the operator's social graph is gated by a dedicated, independently grantable and revocable /social capability, not an ambient operator-wide power and not piggybacked on another grant. The graph is private operator state; access to it must be designated, never assumed.

Threat. An ambient or confused read of the graph (a module or operator tool that reaches the adjacency without holding a designated /social authority) is the leak this boundary forecloses.

Enforcement point. The raw recursive-CTE traversal traverse-reachable (src/operator-state/social-edge.lisp) is unauthenticated by design and capability-clean: it imports nothing from the capability or identity clusters and is not caller-facing. The single gated entry is query-reachable (src/plugin/social-admission.lisp), which calls verify-social-vouch first (an exact /social designation [=+social-designation+=] plus the :read right, decided fail-closed through the shared capability verifier) and only then applies the traversal. A source-level one-caller assertion pins query-reachable as the sole caller of the raw primitive, so the gate cannot be flanked.

Audit proof. social-read-vouch-admits-query proves a valid /social :read vouch admits; the four fail-closed refusals non-social-designation-refused, mount-only-vouch-over-social-refused, revoked-social-vouch-refused, and absent-vouch-refused-fail-closed prove every bad-vouch case is refused; and query-reachable-is-the-only-caller-facing-entry-to-the-raw-traversal (tests/social-capability-scope-test.lisp) pins the gate non-bypassable.

Each boundary is anchored to its enforcement point and the test that proves it. The common principle (pointers and metadata, never bodies or headers) is the schema audit the migration runner runs before every COMMIT.

The paragraph above is a statement about operations, and a reader is owed its limits in the same place, because the gap between them is where a wrong decision gets made.

Ordering. valis is first a way for a person to hold their own data, against the capture of a network architecture that did not have to end up this way. Resistance to a well resourced adversary is a real secondary capability and it is not the headline. Where the two conflict, holding the data wins. Anyone weighing a feature that trades availability of a user's own data for resistance to seizure should know that trade has already been decided in that direction.

The ceiling, stated rather than implied. A machine that is seized and carried off yields its processor, memory and storage state to an adversary who can then work on it without time pressure. There is no defence at that scale and none is claimed. What is achievable is narrower: notice physical interference, and make the relevant data unreadable afterwards.

That last part is harder than it sounds, and the reason is structural. Overwriting does not reliably erase modern persistent storage, because wear levelling leaves the controller deciding which physical cells a write lands on. Destroying a key is the only fast and checkable way to make data unreadable. So the arrangement has to put a small secret in a position where destroying it is sufficient, with no plaintext having reached swap, hibernation, or any store that outlives the key. That is a property of how the system is laid out. It cannot be added later as a panic button.

One tension that does not dissolve. A node that stays online without a person attending it must be able to restart on its own, so its operating key has to be reachable by the machine with nobody present. Putting that key behind a person's presence defeats what the system is for. So a node that can restart unattended will surrender its operating key to whoever takes the machine. That is a consequence of the goal rather than a defect awaiting a fix, and it is why authority to reconstitute a node elsewhere is worth separating from the key the node runs on.

⚠ Sealed backup is built; splitting the secret is not. What exists today is passphrase-sealed off-host backup (src/backup.lisp). Splitting a secret across several holders, so that no single seized machine holds enough to reconstitute anything, is design intent and is not implemented: src/ contains no secret-sharing of any kind. Read any description of reconstitution elsewhere in this document with that distinction in hand.

The privileged host agent's sk_lookup program is a catchall (fulcrum/src/steering.lisp): it stashes valis's one socket in a single-slot map and redirects every TCP and UDP port on the unit's IP to it, transport- and port-agnostic by construction. On a loopback-only island that was harmless: nothing off-host could reach the namespace, so the ports the node answered were exactly the ports anything bothered to connect to. Once the namespace carries a routable address, the same catchall would fan every port on the public IP into valis.

What narrows the public surface back to the ports the agent admits is a second mechanism: a default-deny firewall the agent installs inside the namespace (fulcrum/src/firewall.lisp). Its input chain accepts loopback, established and related return traffic, :53 on both transports, and then, each one only when the agent's own config carries it, the owner port and the public TLS edge port. Everything else drops. The steer says "all ports to valis"; the firewall says "only these enter." They are complementary and both required, and the firewall (not the namespace) is the public-surface boundary. The distinction is not pedantic: a namespace boundary is structural and cannot be misconfigured open, whereas a firewall is a maintained rule that must be installed correctly, before any traffic, and that can in principle fail open. On a public node the surface control is therefore a security-critical, order-sensitive invariant of the same rank as the write fence, documented here rather than treated as an afterthought.

Because the boundary is a policy and not a topology, who writes the policy is the load-bearing security question, and the invariant is that the allowlist is the privileged host agent's alone. A valis module declares the ports it intends to serve, and that declaration reaches the agent as a contract (fulcrum/src/control.lisp's recorded port set), but it gates the descriptor handoff only; it opens nothing. The firewall ruleset takes no valis-supplied input at all: it is a pure function over the agent's own configuration, fed to a privileged nft inside the namespace. Widening it takes a privileged act at the agent, and there are two of them rather than one. A change to the agent's source is the obvious one. The other is a change to the agent's config store: :open-owner-port and :edge-port (fulcrum/src/launcher.lisp, read through ubiquitous) each add an accept line with no source change at all. An operator auditing what a live node exposes has to read both, and the config is the one that is easy to miss.

This decoupling is what keeps a node safe when it hosts code it does not fully trust. valis is the default home for every process not delegated to a sister, including the active-module archetype's untrusted executors; if a module's declaration could open a public port, registering a hostile module would expose an arbitrary listener on a routable IP. It cannot, because reachability is granted by a privileged act at the agent, admitting a port in the agent's own ruleset, that a module can request but never perform. Registration wires dispatch; the agent grants reach; the two must never be collapsed. The pattern for adding a protocol (the constellation map) is written so they are not: a new public port is a host-agent change, deliberately.

⚠ The set the firewall admits and the set the steer carries are disjoint, and one word doing duty for both is how a reader gets this backwards. A module's declaration reaches the agent as its designated port, and designated-port is precisely the key the firewall does not read: grep fulcrum/src/firewall.lisp for the word and it is not there. What the ruleset reads is owner-port and edge-port, both drawn from the agent's own config. A declared port is therefore steered inward and still dropped at the public IP unless the agent's config independently admits that same number, and that gap is the whole safety property. Read "designated" into the firewall and you will believe it admits what the steer carries.

The carve-out is UDP only, and it is physical rather than a preference. sk_lookup chooses which socket receives an inbound packet but does not govern the reply: a UDP answer is a fresh datagram that must source from the address and port the client sent to, or the client rejects it. A TCP connection escapes that, because once the steer selects the listener the kernel tracks the four-tuple and sources replies correctly, whereas valis answering UDP from its generic steered socket would source from the wrong address. The argument covers UDP replies and nothing else. I have ruled that it must not be stretched to cover TCP: DNS over TCP is required in a nameserver, and opening a second special case beside the UDP one buys nothing, so the steer carrying :53 TCP is the correct path.

The kernel program matches that ruling because it never had a port or protocol test in it. fulcrum/bpf/sk-lookup-catchall.lisp is a lookup of slot zero in a single-entry sockmap, an sk-assign, and SK_PASS: one map, one program, no port table, no protocol constant, and the compiled object is byte-identical everywhere it ships. There is no build variant in which it declines a port, so "transport- and port-agnostic by construction" above is the whole truth about it.

The privileged agent still binds the unit-IP :53 sockets on both transports and hands the descriptors down, for the reason that covers every inherited descriptor: binding a privileged port is the agent's to do, since valis runs unprivileged in the namespace. What differs by transport is what becomes of those descriptors on a node whose catchall is live. The inherited UDP socket serves. The inherited TCP socket is bound, handed down, adopted, and then never receives a connection, because the steer takes TCP on that port at the unit's address away from it.

The owner manages the node (mints and revokes capabilities, edits zones, enrols keys, drives the mail spine) through the 9P namespace, as a client that mounts the owner-proven management view. That control plane is deliberately not on the public surface: run-daemon binds the fabric on the namespace's loopback, the firewall drops the fabric port at the public IP and drops the owner port too unless the agent's config deliberately opens it, and an attach is admitted only after a Noise_XX handshake proves the owner's key (fabric.lisp's node-auth responder, seven's Tauth=/=Tattach path, mercer's sealed transport). Reachability and authorization are separate axes: the fabric is never open, it is authenticated, and loopback-binding is what makes "reachable" require first arriving on that namespace's loopback. The firewall reserves the loopback path ("the owner's loopback fabric path") for exactly this.

Reaching that loopback from off the host is a second keyed listener, not a hole in the first. When the resident inherits an owner-port descriptor it adopts it as the routable owner terminus (--owner-fd, threaded into start-fabric), and that adoption asserts the auth seam is engaged before it binds: a routable terminus that admitted an attach without the Noise handshake would be an open owner surface, so it fails closed exactly as the non-loopback bind assert does. *fabric-auth-enabled-p* is what lets the fabric bind a non-loopback host at all, and it does so because the handshake guards the attach rather than in spite of it.

The port is shipped closed. The host agent's launcher carries :open-owner-port, defaulting to nil, so the firewall drops the owner port and no owner socket is bound until an operator deliberately opens it. Opening it is the highest-value application of the host-agent allowlist above, though not the first: the public TLS edge port already carries its own accept line under the same mechanism.

⚠ A same-host proof and a cross-host proof are separate propositions, and neither stands in for the other. Driving the fence, the session listing, and a publication from a client over a real sealed socket proves that the behaviour meets a client as opposed to an in-image caller. It proves nothing about reach through the namespace and firewall boundary, which is a different path. Read any "verified live" against which of the two it actually crossed. TODO.org carries where that stands.

⚠ One detail of that path is easy to get backwards. A session admitted over the wire registers under the transport key's DID, because a Noise handshake proves the transport key and derives the principal from it, not from the signing key custody holds for the owner. The owner check therefore accepts either DID. A test that constructs principals in the image never crosses a handshake and so cannot observe this at all; only a test driving a real client does.

The design is that every valis serves its own documentation on :80, in the clear, with that port enabled on every node. I rank it with the owner control plane rather than with the protocol adapters because it is the surface a person meets first: before a certificate exists, before a name resolves anywhere, and before anything else on the node is working. A node whose manual you cannot read is not one you own, so the manual travels with the node and is answered by the node.

Plain HTTP is the reason rather than a shortcut. Point a phone, a handheld, a decade-old browser, or a text-mode client on a borrowed machine at the address you were given, and you get the documentation, because nothing in that path asks for a modern cipher suite, a trusted root, or a credential the node must first go and obtain from somebody else. A surface that comes up only after the credential machinery has succeeded cannot be the surface that tells you how to make the credential machinery succeed. That is a sovereignty property before it is a convenience: the one door that is open on a node you have just stood up is the one that explains the rest of it.

The content is the published documentation site the tree already carries (site/, landing/), served as an ordinary publication. The descriptor for :80 is inherited from the privileged host agent for the same privilege reason :443 is, and it is the same port an ACME http-01 responder would answer a challenge on: that use is real and it is secondary, never the reason the port is open.

⚠ This is the design, and the node is behind it. The resident parses the inherited descriptor and hands it to no adapter, so a node that inherits :80 answers nothing on it. TODO.org carries the item that closes the gap and the shape it copies.

The two-mechanism split (a catchall steer plus a separate firewall) is the current shape, not the settled end state, and this section records the intended direction without asserting it as built. The unification is to make the sk_lookup program itself the allowlist: a map of admitted ports, written by the agent under privilege, that the program consults, redirecting only admitted ports to valis and letting the rest fall through to closed. The word matters: the map holds what the agent admits, which is not what a module designates. The boundary then lives in one place, in the kernel, and the separate firewall becomes defence-in-depth rather than the primary control. Two constraints survive the unification and are worth stating so the direction is not mistaken for a cure-all: the allowlist map must remain the agent's, never derived from a module's declaration (the invariant above is independent of mechanism), and UDP keeps its socket-activation carve-out regardless, since the steer cannot source a UDP reply. That second constraint carries a consequence worth naming here rather than rediscovering later: with UDP inherited and TCP admitted through the map, a service offering both transports still has them arriving on separate sockets with separate fates, so unifying the boundary does not close the transport split. Any move here changes the privileged kernel path that decides what the internet reaches, so it is gated on a steering test harness before the program is touched.

The resident's production entry is run-daemon (src/main.lisp), which shares run-foreground's fail-closed bring-up: the fabric comes up and the anonymous public view resolves before the edge binds. For the public :53 service, fulcrum (privileged) creates the netns and moves a dedicated public NIC wholesale into it (the launcher's mode :dedicated, with the netns default route via that interface's own gateway), binds :53 UDP and TCP in the netns, clears CLOEXEC, and execs the unprivileged valis (ip netns exec → setpriv → env → valis) with the inherited descriptors; run-daemon adopts them, constructs a pg-zone-source over the operator-state rows, and drives the sibling serve loop over the inherited fds, binding no privileged port itself. (Both :53 descriptors are inherited because binding a privileged port is the agent's to do, but on a node whose catchall is live only the UDP one goes on to serve: the steer takes :53 TCP away from the inherited listener, so DNS over TCP arrives by the same route as the steered push-boot handoff and carries the split set out at what the transport split costs.) The invariants a deploy must preserve are the substrate's own: unprivileged valis dies rather than privileged-bind; a binary without the serving codec fails closed at boot; only the exposed ports are reachable behind fulcrum's default-deny (the surface control, the boundary that admits them); and two instances sharing one database are held to a single writer by the generation fence (the fence and the sweep). The written contract is the host-deployment contract.

A certificate is obtained through a dns-01 challenge, and the authority that answers that challenge is the node itself. I made the :443 edge cert-gated rather than required because of that circularity: a node must already be serving :53 before it can ever be issued a certificate, so a certless genesis boot has to be a healthy state and not a failure. With no usable certificate in custody for the configured name, the public edge stays dark and the resident still comes up, and the boot output says which case held. A silently dark port is indistinguishable from a descriptor that never arrived, which is the confusion that costs an operator an evening.

The edge holds one credential per name it serves and resolves it per connection, so a request for one name is never answered under another name's certificate. A renewal swaps the live leaf on the same cell the connection path reads, and the listening socket is never touched.

Two constraints carry into any operation on this path. Both are irreversible.

• One certificate per registrable domain. Never SAN-pack. Certificate Transparency records the set of names on a certificate permanently and publicly. Pack several of the owner's domains into one credential and you have published, for good, the fact that one party holds them all. Nothing retracts it afterwards.
• The ACME account key shares the certificate store path. Rename or move that store and the next order registers a fresh account, spending production rate limits that do not come back.

Because deployment is the genesis case of condense, the harness that exercises a deploy is the same harness that exercises evacuate and restore: the migration-thesis regression harness. It lives under proving-ground/ as committed, declarative tooling: a Nix devshell pins the verification fabric (the guests it boots stay stock Debian, and the core is built impurely from the working tree, never as a Nix derivation); Terraform-libvirt boots Debian guests on two distinct VLAN-tagged network locations so a successor and predecessor sit at genuinely different locations: the topology a single-VM harness cannot express, and the precondition for the fence-and-reconnect path; and cloud-init provisions each guest to the adopt-below seam, staging the serving binary rather than rebuilding it. An in-image Lisp assertion layer (valis-proving-ground, its own ASDF system, never entering the resident binary) drives three scenarios over one mechanism (deploy-from-genesis, evacuate-cross-location, restore-from-backup) through three real interfaces: SSH for unit/netns/fd state, off-host dig for authoritative :53, and a fabric-liveness probe on the owner-proven loopback path. Each assertion is exit-coded and fail-closed; a scenario reduces to one go/no-go verdict. The scenarios assert the effects of the shipped condense and fence path, they do not re-implement it. See proving-ground/README.org.

The restore scenario exercises a passphrase-escrowed backup of the irreplaceable durable state, and a deployed resident reports substrate-only health so a silent failure surfaces before it becomes an outage. Both surfaces (the backup/restore and passphrase-escrow flow, and the logging/liveness/certificate-expiry observability surface) are documented for the operator in Backup and observability.

• BPF sk_lookup program type - the kernel mechanism that lets one socket answer every port (the steering layer).

• iolib - the Common Lisp I/O library whose epoll multiplexer the listener is built on.
• Efficient IO with io_uring (Jens Axboe) - the eventual multiplexer backend behind valis's own interface.

• RFC 1035 - domain names: the message format and master-file presentation the substrate serves and the wire engine encodes.
• RFC 2308 - negative caching: the apex SOA on a negative answer and the min(SOA.MINIMUM, SOA.TTL) negative-cache lifetime the seam contract requires.
• RFC 4592 - the role of wildcards: the synthesis-and-existence rules the nameserver's lookup tree follows.
• RFC 3597 - handling of unknown RR types: the generic rdata form the record boundary round-trips through.

• The Use of Name Spaces in Plan 9 - per-process namespaces and 9P, the model the substrate reifies.
• 9P specification and papers - the protocol that is both substrate and bus.
• v9fs (Linux 9P client) - lets the host kernel mount a valis namespace.
• factotum(4) - Plan 9's auth agent (a 9P file system holding keys); the model for valis's auth agent.
• c9 - a small 9P client and server; reference for a Common Lisp implementation.
• Interim - a Lisp environment where "everything is a file is a symbol"; closest prior art.
• awesome-plan9 - curated index of Plan 9 / 9P software.

• Venti: a new approach to archival storage - content-addressed, write-once block storage (the immutable-bulk model).
• Fossil, an Archival File Server - the mutable file server over Venti (the single-writer mutable head).
• CephFS Dynamic Subtree Partitioning - the per-subtree-authority write-scaling growth path.
• Conflict-free replicated data types - leaderless merge model, considered and rejected for the authoritative namespace.
• Git internals: objects - the canonical immutable-objects + mutable-refs pattern.
• CRIU live migration - checkpoint/restore including established TCP connections (TCP_REPAIR); the optional in-flight-continuity enhancement.
• Tahoe-LAFS architecture - a least-authority store where the capability is the name (read/write/verify caps).

• UCAN specification - delegable, attenuatable, public-key/DID-rooted capabilities; the primary token model.
• Macaroons - bearer capabilities with contextual caveats (the attenuation/confinement idea).
• Good Practices for Capability URLs (W3C) - the unguessable-URL-as-capability pattern for anonymous publishing.
• Capability Myths Demolished - ambient authority and the confused deputy; the no-ambient-authority discipline.
• The Noise Protocol Framework - connection-time mutual key authentication (also libp2p's secure channel).
• SPKI/SDSI (RFC 2693) - the certificate-capability ancestry of UCAN.
• Decentralized Identifiers (DIDs) (W3C) - the principal identifiers UCAN uses.

• IPFS - content-addressed storage for bulk and published data.
• libp2p - the networking stack a future Common Lisp CFFI binding would expose.
• cl-ipfs-api2 - an existing CL HTTP-API client to an external IPFS daemon (the interim bridge).

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