The Living Registry

Structure declares itself in plain files. Appearance is a token layer above it. YAML is the CSS of the substrate.

The system does not hardcode its behavior. It declares it. Every YAML file is readable by a human, editable by a human, and enforceable by a machine.

There is a discipline in this project that predates any specific feature and outlives any specific model: the insistence that the system's behavior be declared, not coded. The agent does not decide which body to use by running a series of if-statements. It reads a YAML file. The broker does not decide which tools are available by checking a hard-coded list. It reads a YAML file. The learning loop does not decide which seats participate in an experiment by consulting a database. It reads a YAML file.

This is not laziness. It is a deliberate architectural choice with a specific purpose: every decision the system makes should be inspectable by a human being who can read plain text. No hidden state. No magic constants. No behavior that lives only in compiled code and can only be discovered by running the system and observing what happens.

The body registry

The body registry is the system's map of itself. It defines every agent body — every distinct cognitive persona that can handle a turn — with its context window, its sacred clearance, its routing rules, its fallback chain, its delegate targets, and its model identity.

A body entry specifies whether that body is sacred (whether it may see the Sacred Boundary files), what delegate kinds it handles (code, review, reasoning, vision, audio, pretext, teaching), what its primary and fallback model routes are, and what its context budget is. The conductor body — the primary conversational agent — has the largest context window, full sacred clearance, and access to every delegate kind. A specialist body has narrower scope: it handles one kind of work, with one set of tools, at one context budget.

The routing layer reads the body registry on every turn. When a turn arrives, the broker determines which body should handle it based on the turn's surface, its content, and the operator's preferences. The body registry is the lookup table. Changing the registry changes the system's behavior — not by redeploying code, but by editing a file.

The family registry

The family registry is the system's social map. It defines every person the system serves — their preferred language, their pronouns, their vault scope, their rate limits, their surfaces, their agent assignments, their shared credentials.

Each person in the registry has a tools role (what operations their agent may perform), a sacred clearance (what content their agent may see), and a set of surfaces (where their agent may operate — chat, voice, phone, browser, IDE). The registry also defines the operators — the doctor, the engineer, the steward, the keeper, the seeker, the healer, the voice, the scribe, the lane-watcher — each with their own scope and their own responsibilities.

The family registry is the single source of truth for people. When the system needs to know who someone is, what they are allowed to do, or how they prefer to be addressed, it reads the registry. There is no separate user database, no separate permissions table, no separate preferences store. The registry is the answer.

The seat registry

The seat registry defines the evolution seats — the eight specialized roles that the system uses to improve itself. Each seat has an experiment directory, an evaluator, a status flag, a sacred guard, a bounded flag, and a smoke timeout.

The Engineer's Bench judges code. The Seeker's Library judges research. The Broker's Hall judges tool routing. The Atelier judges design. The Compositor's Press judges the expression layer. The Conductor's Score judges orchestration. The Telephony Bench judges call quality. The Sovereign Chat Bench judges latency and tool use. Each seat is a self-contained evaluation unit with its own criteria, its own gold sets, its own metrics.

The seat registry is what makes the learning loop's detector possible. The detector does not judge in a vacuum. It judges against the criteria defined by the seats — each axis of quality maps to a seat's evaluator. The seats are the system's taste, declared in plain files.

The capability policy

The capability policy defines what the system is allowed to do. It is the most safety-critical registry in the project, and it is also the simplest.

The policy has two modes: unrestricted (the default for the sovereign node, where the operator has full control) and restricted (the default for the Docker distribution, where the operator may not want every capability enabled). Each domain — database, filesystem, network, model, agent, tool — has a set of actions that are either permitted or denied. The policy is read by the capability gate before any action is taken.

The restricted profile ships as the default because the distribution must be safe for someone who does not know what the capabilities are. The unrestricted profile is one edit away because the sovereign node must be powerful for someone who does. The capability policy is the system's conscience, declared in YAML and enforced by the routing layer.

YAML as CSS of the substrate

The same discipline that governs the knowledge substrate governs the interface substrate. Color, type, spacing, motion — all captured as data in token files, version-controllable, swappable, owned. YAML is the CSS of the substrate: the declarative layer that names what a thing is, separable from the layer that decides how it looks.

A user who restyles their interface is performing an act of ownership equivalent to a user who re-embeds their corpus. Both are first-class. Both are designed for. The appearance layer never becomes load-bearing for the structure, the same way the index never becomes load-bearing for the substrate.

The design system that implements this principle is token-first. Every visual decision — the color of a node in the constellation, the weight of a heading, the duration of a transition, the glow of a focused element — is a named token in a YAML file. The CSS that implements the visual layer reads the tokens. The tokens are the source of truth. The CSS is the disposable index. The HTML is the substrate.

This is not over-engineering. It is the three-layer model applied to the visual domain. The substrate (HTML) is owned. The index (CSS) is disposable. The cognition (the user's perception) is interchangeable — a different theme changes the experience without changing the structure. The same person who cannot re-embed their corpus can restyle their interface with a single YAML edit. The principle scales from the deepest technical layer to the most visible surface layer, because the principle is the same at every depth: own the substrate, dispose the index, interchange the cognition.