gbrain: sync converted org-mode brain files

projects/passepartout/architecture/architecture.org

@@ -62,6 +62,34 @@ The LLM layer is probabilistic. The ACL2 layer is deductive. The gate architectu
 
 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:

projects/passepartout/architecture/conceptual-walkthrough.org

@@ -0,0 +1,100 @@
+:PROPERTIES:
+:CREATED:  [2026-05-31 Sun]
+:ID:       f0e1d2c3-b4a5-6c7d-8e9f-0a1b2c3d4e5f
+:END:
+#+title: A Conceptual Walkthrough of Passepartout
+#+filetags: :passepartout:architecture:overview:
+#+STATUS: draft
+
+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.

projects/passepartout/architecture/distinguishing-features.org

@@ -0,0 +1,61 @@
+:PROPERTIES:
+:CREATED:  [2026-05-31 Sun]
+:ID:       d5c6e7f8-9a0b-1c2d-3e4f-5a6b7c8d9e0f
+:END:
+#+title: Distinguishing Features of the Passepartout Architecture
+#+filetags: :passepartout:architecture:
+#+STATUS: draft
+
+This is a working list of what distinguishes Passepartout's architecture from alternatives. Not final — still being refined.
+
+**1. Neurosymbolic (vs pure neural)**
+
+Not an LLM bolted onto a database. The system fundamentally bridges neural and symbolic representations, not as an integration layer but as a unified semantics.
+
+**2. Symbolic above neuro (vs other neurosymbolic architectures)**
+
+The Gate is the mechanism: an ACL2-verified deductive layer that is authoritative over the LLM. The LLM proposes actions, facts, and interpretations. The Gate decides. The LLM cannot overrule a verified denial. Most neurosymbolic systems are neural-dominated with symbolic afterthoughts; this inverts that hierarchy.
+
+**3. Org-mode data store + neural index + symbolic index**
+
+One file format for human and machine. The Org file is not a representation of the data — it IS the data. Both indices (neural embeddings for semantic search, symbolic assertions for formal reasoning) are derived views that can be rebuilt from the Org source. No translation layer, no schema migration, no vendor lock-in.
+
+**4. Wikipedia bootstraps general knowledge, LLM bootstraps specialized domains**
+
+General world knowledge seeds from structured sources (Wikidata, Wikipedia infoboxes) at minimal cost. Specialized domains (regulatory compliance, physics, medicine) are extracted by LLM from prose, then verified by the Gate. The bootstrapping is cheap and incremental, not a 24.5M-assertion Manhattan project.
+
+**5. Lisp and homoiconicity — one address space**
+
+Editor, shell, browser, and agent run in the same Lisp image. The Gate is in the evaluation loop itself, not interposed as an OS layer. There is no MMU boundary between components because there are no separate processes. No IPC, no kernel boundary to attack. The system verifies code at the level where code and data share representation.
+
+**6. Social protocol**
+
+Communication between instances is provable, not just encrypted. Every message is signed by a self-sovereign DID, tracked in a content-addressed DAG, optionally notarized.
+
+**7. Social network relies on: decentralization, cryptographic ID, payment layer, contracts**
+
+No central server, no platform dependency. Identity is cryptographic, not account-based. Payment and contracts are native to the protocol, not bolt-ons.
+
+**8. Unified social primer: the Note**
+
+A single primitive — the Note — serves as message, document, contract, vote, and identity claim. The social graph is built from Notes referencing Notes. No separate types for posts, transactions, or agreements.
+
+**9. Staged progression 0→7**
+
+Each stage is independently useful and fully functional. Stage 0 (current) runs conventional Linux with Hermes and gbrain. Stage 7 is custom silicon with the full verified stack. The migration is progressive component swap, not a cut-over. No stage requires the next stage to exist.
+
+**10. Self-modification / hot-reload (the autodidactic loop)**
+
+Because code and data share the same representation in a Lisp address space, the system can modify itself without restarting. The Gate monitors its own performance, proposes improvements, and applies them with verification. The system learns to be more secure, not just patched to fix CVEs.
+
+**11. Cost inversion (80% symbolic at near-zero marginal cost)**
+
+Symbolic reasoning is typically expensive (knowledge engineering, ontology maintenance). Passepartout inverts this: the LLM generates symbolic assertions cheaply, the Gate verifies them deductively, and the Org source stores them as a human-readable byproduct. The expensive part becomes the verification, which compounds with every use.
+
+**12. Potential revenue streams from Stage 1**
+
+The social protocol (Stage 1) enables paid services before the full stack is built — DID registration, relay node operation, PDS hosting, compute marketplace fees. Revenue starts flowing before the Gate exists as a software layer.
+
+**13. Dual growth strategies: social + institutional**
+
+Social growth: DID identity propagates through existing social graphs, messaging as the substrate, PDS self-hosted by friends. Institutional growth: compliance appliances sold to regulated industries, verification as a service, enterprise gate configurations. Neither is sufficient alone; both compound each other.