hermes-brain/projects/passepartout/architecture/architecture.org

:PROPERTIES:
:CREATED:  [2026-05-24 Sun]
:ID:       1c3ec48b-446c-50d2-b53e-126a81f5143f
:ID:       a1fac32a-47de-5fbd-b67d-29152c851747
:ID:       42c86e6f-4f27-4993-8238-b7bc7d15fb7b
:END:
#+title: Architecture
#+filetags: :passepartout:architecture:

The project index introduces Passepartout as a personal computing environment. This page describes the architecture in detail: the four subsystems, how they compose, how the gate works, how the memex is structured, and why the stack compresses into a single address space.

**The four subsystems, one address space.**

Passepartout is one system built from four subsystems that share one evaluation semantics, one memory graph, and one proof chain:

- **Environment** — the personal computing environment
- **Knowledge** — the unified memex
- **Verification** — the gate
- **Social Protocol** — provable communication between instances

Each is described below.

**The environment: one address space.**

The environment eliminates the layered trust model of a conventional OS by eliminating the layers. Instead of an editor that sends keystrokes through a terminal emulator to a shell that forks processes that read files through a kernel VFS layer — each boundary a potential vulnerability — the environment runs everything in a single Lisp address space. (Lisp is a family of programming languages where code and data share the same representation. This property means the machine can verify what code does and modify itself without restarting. It is the foundation that makes the entire architecture possible.)

The editor is a Lisp function that manipulates text buffers in the evaluated memory graph. The shell is a Lisp read-eval-print loop that compiles to the same evaluator. The browser renders HTML through a Lisp-based rendering engine, not a separate process. The agent runtime invokes Lisp functions, not subprocesses. (The specific implementations that realize this today use Lish for the shell and editor, Nyxt for the browser, and SBCL as the host Lisp — but the architectural principle is uniform semantics in one address space, not these particular packages.)

There is no MMU boundary between components because there are no separate processes. There is no IPC because there is nothing to communicate between. Everything shares the same memory graph. Your editor buffer, your shell history, your agent's state, and your social protocol messages all live in the same evaluated object graph, protected by the same gate, verified by the same prover.

**The knowledge subsystem: Org-mode as unified memex.**

The knowledge subsystem makes a bet that most systems consider too expensive: that humans and machines should share the same file format. That bet is Org-mode.

Most systems separate human-readable notes from machine-readable data. The user writes Markdown. The system stores it, indexes it, searches it. But the system maintains its own internal model — a database, a knowledge graph — disconnected from the Markdown. When the user leaves, the Markdown survives but the model must be reconstructed.

Passepartout refuses this separation. The Org file is not a representation of the data; the Org file IS the data. The same text the user reads and edits is what the system parses and operates on. There is no translation layer between human and machine — no schema, no import/export, no API boundary between what you write and what the system knows.

Sparse tree retrieval makes this efficient at scale. Org-mode's headline hierarchy is a semantic structure the system can query. When the agent needs information about a specific function, it retrieves exactly the subtree under that heading — not the entire file. Context stays lean (2,000 to 4,000 tokens) while the full knowledge base remains accessible through structural retrieval. This is fundamentally different from Markdown, where retrieval is either imprecise (grep) or entire-file (expensive).

The knowledge subsystem maintains two indices over the Org prose:

1. A neural index using vector embeddings for semantic search — the gateway to the full richness of natural language.
2. A symbolic index storing formal assertions about what the prose says — predicates, relations, constraints — each grounded to a specific heading or block.

The prose is always ground truth. Both indices are derived views that can be rebuilt from scratch. Nothing is lost in the indices that was not already in the Org files.

The same principle extends beyond prose to structured data. Empirical parameters, validity envelopes, provenance chains, and benchmark results live in Org as property drawers and tables — the same format the user reads and edits. The system maintains a derived representation — the provenance store — optimized for machine queries: filter by confidence interval, find all models valid for a given input class, trace a parameter to its experimental source. Like the two indices, the provenance store is a derived view rebuilt from Org, not a separate system with its own canonical copy. Nothing is lost in the store that was not already in the Org files. And when the system learns something new — a validated parameter, a benchmark result — it writes back to the Org files, keeping the human layer current.

This is what sovereignty means in technical terms: the user owns the data in a format they can access, and the system operates on the data in the same format they own. The format is stable — Org-mode has been in active development since 2003. There is no schema migration, no database upgrade, no vendor lock-in. Your notes survive the system.

**The verification subsystem: the gate.**

The gate is a function that takes (action, context, policy) and returns (permit | deny). Every action passes through it — a shell command from the user, a proposal from the LLM, a message from the network, a file write by a scheduled job. There is no privileged path around the gate. Root is not a concept in the gate model — root is a convention enforced by an OS that the gate replaces.

The gate combines two decision layers:

1. ACL2-verified decision procedures for security-critical checks — access control, message authentication, capability resolution. (ACL2 is a theorem prover and programming language for formal verification. It proves that code behaves correctly for all possible inputs, not just the ones tested.)
2. An LLM for natural-language reasoning — parsing the user's intent, evaluating whether an action falls within policy boundaries that require human judgment.

The LLM layer is probabilistic. The ACL2 layer is deductive. The gate architecture ensures the deductive layer is authoritative where it applies and the probabilistic layer is bounded by it — the LLM cannot overrule a verified denial.

The gate does not depend on OS privilege boundaries because it is in the evaluation loop itself. This is the architectural reason for the Lisp machine: a conventional OS interposes between the gate and the hardware. A Lisp machine eliminates that interposition by making the gate part of the evaluator.

**How the gate knows which procedure belongs to which domain.**

Every action entering the gate carries a domain tag. The tag is set by context — a file write under /home/user/documents/ gets the "documents" domain, a network call to an approved registry gets "network", a shell command running a compiler gets "software-engineering". The domain tags form a tree: "files" has children "documents", "code", "config", "system", each with its own rule set.

The gate maintains a procedure registry mapping domain tags to ACL2-verified boundary functions. When an action arrives, the gate looks up the most specific domain tag that has a registered procedure. If "documents" has one, it uses that. If not, it walks up to "files". If no domain in the tree has a procedure, the action falls under LLM authority bounded only by the generic outer fence.

Domain tags are defined in the policy configuration — a hierarchy of Org headings or YAML that maps path patterns, network destinations, and command prefixes to domain names. New domains can be added at any time with no code changes, just a policy edit. New domains start with no verified procedures and rely entirely on the LLM until experience accumulates and ACL2 boundaries are written.

**How the verified procedure registry grows.**

Verified procedures are not all written upfront. The initial gate ships with a minimal set of obviously correct outer boundaries — three to five rules that prevent catastrophic, irreversible actions. The registry grows through two mechanisms:

1. Mistake-driven hardening: when the LLM's provisional authority causes harm, that action is logged, a human or automated process writes an ACL2 conjecture to prevent it, the Prover verifies it, and the resulting boundary function is added to the registry under the relevant domain tag.

2. Adversarial probing: the gate randomly injects probe actions that would violate known desirable boundaries but are caught before execution. These probes generate the same hardening signal even when no mistake occurred. They cover the blind spot where the LLM always gets it right and no error is ever logged.

3. Syscall wrappers: every action that crosses from the Lisp image into the host OS passes through a gate wrapper that records the kernel's response. When the kernel denies an action (permissions, seccomp, namespaces) that the gate had no rule for, the wrapper translates that kernel denial into a hardening signal — "the kernel prevented this. Consider codifying it as an ACL2 boundary." This covers the blind spot where the kernel catches the problem first and the gate never sees the danger.

These three channels feed a queue. The autodidactic loop (or a human reviewer) periodically processes the queue, drafts ACL2 conjectures, runs the Prover, and deploys new verified boundaries. The gate's procedure registry grows transaction by transaction, domain by domain, from three rules to hundreds to thousands over the lifetime of the system.

**The two blind spots and their mitigations.**

Blind spot 1 — the LLM always gets it right. If the LLM never attempts a dangerous action in a domain, no mistake is logged, and no ACL2 boundary is proposed. Mitigation: adversarial probing. The gate regularly tests the LLM with actions that would violate known safety properties, logged before execution. These probes generate hardening signals regardless of the LLM's accuracy.

Blind spot 2 — the kernel prevents the action before the gate sees it. If the LLM tries to write to /etc/shadow and the kernel's DAC permissions reject it, the LLM sees a permission error, the gate sees a failed action, but neither knows a safety boundary was enforced. Mitigation: syscall wrappers. The gate wraps every kernel transition and records the reason for denial. A kernel EACCES on /etc/shadow becomes a hardening signal: "the kernel has a rule about /etc/shadow that the gate doesn't. Codify it."

Without these mitigations, the gate's coverage converges to a plateau determined only by what has already broken, leaving large regions permanently dependent on the LLM's probabilistic reliability.

**The social protocol: provable communication.**

The social protocol extends the verified semantics beyond a single machine. It provides:

- Self-sovereign DID identity (every instance has a cryptographic identity it controls)
- DIDComm encrypted messaging (end-to-end encrypted, signed, DAG-tracked)
- Personal data stores (user-owned, gate-controlled)
- Relay network (asynchronous message delivery across trust boundaries)
- Compute marketplace (provision verified compute you rent)
- Liquid democracy (delegable voting over protocol governance)

Every message is signed by the sender's DID, tracked in a content-addressed DAG, and optionally notarized. Communication is provable when you choose it to be — you can prove what you sent, to whom, when, without revealing content.

The social protocol is not a blockchain. DAG-based ordering handles causality; delegable trust replaces proof of work.

**The staged progression.**

The full architecture — gate-verified Lisp machine on custom silicon — is the destination. The staged roadmap describes how each successive replacement eliminates a class of threat:

- Stage 0: Conventional Linux, Python agent (Hermes), SQLite knowledge store (gbrain). The starting point. Zero days exist; patches are manual.
- Stage 1: Message-level authentication via the social protocol. Communication becomes provable.
- Stage 2: The gate operates as a software layer over the host OS. Shell commands, LLM proposals, and network messages all pass through the same decision procedure. Root is eliminated as an attack path.
- Stage 3: The host OS is replaced by a bare-metal Lisp image. One address space, one evaluator, no MMU to attack.
- Stage 4: LLM inference moves into the Lisp process. No API calls across network boundaries. The LLM becomes a function in the same evaluated graph.
- Stage 5: Neural weights stored as plist-native data structures. The gap between symbolic and neural representations closes.
- Stage 6: Verified fine-tuning. Every weight update is gate-checked against policy.
- Stage 7: What remains. Physical theft, electronic warfare, holes in the specification itself, and the fallibility of the LLM oracle. Limits of computation, not of this design.

Each stage is independently useful. Stage 0 is running today. The migration is progressive component swap, not a cut-over.

**Downstream effects.**

When every action is gate-checked, every message is provable, and every computation runs on verified semantics, the security model shifts from empirical to deductive. The downstream effects cascade beyond personal computing:

- **Compliance** becomes executable gate rules instead of annual audits. A SOC 2 report is a gate configuration, not a PDF.
- **AI safety** becomes a verified gate between the LLM and the action stream instead of probabilistic guardrails or RLHF.
- **Software certification** becomes the accumulated regression suite of every deployed instance — the Underwriters Laboratory for AI.
- **Operating systems** become obsolete. The gate replaces the kernel, the address space replaces process isolation, and the verified evaluator replaces the privilege model.