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

A Conceptual Walkthrough of Passepartout

This note explains how Passepartout works from beginning to end — what the parts are, how they compose, how the system grows itself, and what happens at each stage. It is the single document that ties all the others together.

What is Passepartout?

A personal computing environment where every action is verified, every communication is provable, and every piece of data is owned by you in a format you control. It is one system built from four subsystems that share one evaluation semantics, one memory graph, and one proof chain:

• The Environment — your editor, shell, browser, and agent running in a single Lisp address space
• The Knowledge subsystem — your notes, structured data, and symbolic assertions in Org-mode, with neural and symbolic indices built on top
• The Verification subsystem — the Gate, which sits between every action and the system, deciding permit or deny
• The Social Protocol — DID identity, encrypted messaging, PDS, relay, compute marketplace, liquid democracy

Stage-by-stage what the system looks like:

Stage 0 — the starting point. Conventional Linux, a Python agent (Hermes), SQLite knowledge store (gbrain). The Gate does not exist yet as software — it exists as a design. You use Hermes and gbrain while the Gate is being written. This is Passepartout's bootloader. Zero-day exploits exist. Patches are manual. No action is verified.

Stage 1 — the social protocol layer goes live. Messages between instances become provable. Each instance gets a self-sovereign DID. The relay network forms. Revenue streams start from relay operation and PDS hosting. The Gate is being designed on this working infrastructure that generates income.

Stage 2 — the Gate deploys as a software layer over the host OS. Every shell command, LLM proposal, and network message now passes through the same decision procedure. The Gate has two layers: a deductive layer running pre-verified ACL2 functions (for formal boundaries) and an LLM layer for everything else. The procedure registry starts with three to five ACL2-verified rules — the minimum fence that prevents catastrophic failure. The registry grows over time.

Stage 3 — the host OS is replaced by a bare-metal Lisp image. No layers between the Gate and the hardware anymore. No kernel to attack, no MMU boundary, no syscall interface. The Gate is now the evaluator itself.

Stage 4 — LLM inference moves into the Lisp process. No more API calls. The LLM becomes a function in the same address space. Token costs vanish. The autodidactic loop speeds up by orders of magnitude because every Gate decision can query the LLM without latency or cost.

Stage 5 — neural weights are stored as plist-native data structures. The gap between symbolic and neural representations closes. The symbolic index and the neural index can cross-validate each other.

Stage 6 — verified fine-tuning. Every weight update is Gate-checked against policy. The LLM itself is now subject to the same verification as everything else.

Stage 7 — what remains: physical theft, electronic warfare, holes in the specification, LLM fallibility. Limits of computation.

How the Gate processes an action at Stage 2:

An action arrives — a shell command from the user, a proposal from the LLM, a message from the network. The action carries a domain tag determined by context (path prefix, network destination, entity cluster).

First, the Gate checks the deductive layer. Does the action's domain have any registered ACL2-verified boundary procedures? If yes, check them one by one. If any denies, reject instantly. The LLM cannot overrule.

If no verified procedure denies, the Gate checks with Screamer. Does a constraint network exist that resolves this question? Screamer has rules extracted by the LLM and corrected by humans — domain-specific constraints, rights, and prohibitions. If Screamer finds a resolution, apply it. Done.

If Screamer has no matching constraint, the Gate asks the LLM. The LLM reasons about the action given its understanding of the domain — extracted from Org files, Wikipedia, regulations, and past corrections. The LLM proposes permit or deny. The Gate checks the proposal against the deductive layer boundaries again (defense in depth). If it passes, permit.

The entire decision — action, context, which boundaries were checked, whether the LLM was invoked, what it proposed, what happened — is logged to the Gate's decision log.

How the Gate learns:

The autodidactic loop reads the decision log and looks for patterns:

• If the LLM is frequently invoked for the same type of action, Screamer should get a new constraint to cover it. The LLM generates the constraint. Screamer adds it.
• If the LLM made a mistake and was corrected, the correction is logged. Screamer's constraint network is updated. The mistake joins the hardening queue for ACL2.
• If the Gate logged a kernel-level denial it didn't have a rule for, a syscall wrapper flagged it. The autodidactic loop proposes a new ACL2 boundary to replace the kernel's protection.
• If a domain cluster shows high LLM utilization, the autodidactic loop asks the LLM to label it, registers it in the procedure registry with zero verified procedures, and starts tracking it as a distinct domain.

The hardening queue is processed periodically. A conjecture is drafted for ACL2. The Prover runs it. If the proof passes, the new boundary function is compiled and added to the procedure registry. If the proof fails, the conjecture is refined or abandoned. The action stays under LLM authority.

How domains emerge:

The user writes notes in Org. The symbolic index extracts entities and relationships. Screamer's constraint network connects them. Over time, clusters form — entities that mention each other frequently and mention outside entities rarely. The Gate notices clusters where LLM utilization is high. It asks the LLM to label them: "This cluster deals with financial records. Shall I create a domain called accounting?" If the user confirms, the procedure registry gets a new tag. New actions matching the cluster get the tag. Verified procedures can now be registered under it.

New domains start empty — no verified boundaries. The LLM has full provisional authority within the generic outer fence. As mistakes accumulate, ACL2 boundaries are written under the domain tag.

How the social protocol connects instances:

Every instance has a DID — a cryptographic identity it controls. Messages between instances are DIDComm: end-to-end encrypted, signed, tracked in a content-addressed DAG. The relay network delivers messages between instances that don't know each other's network addresses. The PDS stores the instance's identity documents, messages, and shared data.

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

The compute marketplace extends this: instances can offer or purchase verified compute. A smart contract on the social protocol matches buyers to sellers, verifies execution against the buyer's Gate rules, and settles payment in protocol-native tokens.

Liquid democracy extends it further: governance decisions are made by delegate-weighted voting, where any instance can delegate its vote to another instance, forming a delegation graph. The Gate enforces each instance's voting policy.

How the four commons map to the four subsystems:

• Common Lisp — the Environment subsystem. The address space contract, the evaluator, the Gate in the loop.
• Common Law — the Social Protocol. Liquid democracy, delegable voting, governance.
• Common Wealth — the Social Protocol. Compute marketplace, resource accounting, token settlement.
• Common Sense — the Knowledge subsystem + the Gate. Propositions proposed by LLM, verified by Gate, stored in Org, indexed symbolically.

The autodidactic loop in full:

The autodidactic loop is the mechanism by which the system improves itself without human intervention. It runs continuously, at a configurable cadence:

1. Read the decision log since the last run.
2. Identify high-frequency patterns where the LLM was invoked.
3. Propose Screamer constraints for the top patterns.
4. Check the hardening queue for new ACL2 conjectures ready to prove.
5. Check the adversarial probe results — did any probe reveal an unprotected boundary?
6. Check the syscall wrapper logs — did the kernel deny anything the Gate missed?
7. Propose new domain clusters if LLM utilization in a cluster exceeds a threshold.
8. Run the Prover on pending conjectures.
9. If proofs pass, compile and deploy new boundary functions.
10. Log the cycle results.