amr/hermes-brain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Restructure three-pronged → knowledge-layers: collapse 11 files to 3, integrate into main architecture

Browse Source 
- Rename 'three-pronged' folder to 'knowledge-layers' — prong metaphor
  was misleading (implied parallel tines), replaced with epistemic layers
  (deductive base, empirical middle, probabilistic oracle — vertical stack)
- Collapse 11 overlapping files into 3 coherent documents:
  - knowledge-layers/_index.org: core framework (two engines + one store,
    World Model formula, 0-14 layer table, provenance store design,
    conflict resolution, cold-start, stage mapping)
  - knowledge-layers/practical-implications.org: design-world-aware-of-
    physics, 10 powers, Schafmeister existence proof, epistemic transparency
  - knowledge-layers/neurological-empirical.org: neural networks in
    provenance framework (kept intact)
- Relocate wolfram/mathematica and Schafmeister docs to ideas/viability/
- Integrate into main architecture _index.org:
  - Gate: expanded from two vectors (ACL2+LLM) to three (deductive,
    provenance/empirical, LLM oracle)
  - Autodidactic loop: split into Track 1 (deductive hardening, fast)
    and Track 2 (empirical validation, slow, experimental-feedback-driven)
  - See also: added Knowledge Layers cross-reference
- Add all-lisp geometry engine note (ideas/lisp-geometry-engine.org) as
  concrete illustration of the empirical layer's effect on design work
- Rebuild site: 148 files, 0 errors
This commit is contained in:
Hermes
2026-06-04 19:09:44 +00:00
parent 2e8cf19f9e
commit 6e992cc0c5
92 changed files with 921 additions and 2628 deletions
Download Patch File Download Diff File Expand all files Collapse all files

188
projects/passepartout/architecture/_index.org
View File

@@ -1,51 +1,165 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 5e7f1d2a-3b4c-5d6e-7f8a-9b0c1d2e3f4a
:ID: 1c3ec48b-446c-50d2-b53e-126a81f5143f
:END:
#+title: Architecture
#+filetags: :passepartout:index:
#+filetags: :passepartout:architecture:
Architecture overview — narrative introduction, staged build-out, systemic effects, and the analytical frames that justify the design.
**The four subsystems, one address space.**
[[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the narrative introduction to the project.
Passepartout is one system built from four subsystems that share one evaluation semantics, one memory graph, and one proof chain:
**Staged roadmap:**
- **Environment** — the personal computing environment
- **Knowledge** — the unified memex
- **Verification** — the gate
- **Social Protocol** — provable communication between instances
| Stage | Delivers | Key cost | Timeline |
|-------+----------+----------+----------|
|| [[id:4a1f23b0-abc1-4def-9876-543210abcdef][0 — Now]] | Baseline: conventional computing | Patching treadmill, no deductive guarantees | Today |
|| [[id:4a1f23b0-abc2-4def-9876-543210abcdef][1 — Social Protocol]] | Communication integrity, provable DAG + **Truth Layer (contradiction detection, verification economy)** | Crypto overhead, DAG storage growth, stake model attack surface | Today |
|| [[id:4a1f23b0-abc3-4def-9876-543210abcdef][2 — Verification]] | Verified gate, capability auth + **Symbolic Reasoner (CL HOL engine, knowledge-dependent auth)** | Reasoner dev cost, policy formalization burden | Today (limited) |
|| [[id:4a1f23b0-abc4-4def-9876-543210abcdef][3 — Lisp Machine]] | Lisp image, Merkle memory, no kernel | Lisp tax, no backward compat, single address space | 2-5yr (soft) / 5-10yr (ASIC) |
|| [[id:4a1f23b0-abc5-4def-9876-543210abcdef][4 — Inference]] | In-process LLM, token interception | ~10x compute/RAM/storage | Server now; consumer 3-5yr |
|| [[id:4a1f23b0-abc6-4def-9876-543210abcdef][5 — Weights]] | Plist-native weights, weight-level provenance | ~100x GPU / ~2-5x ASIC | GPU hybrid now; ASIC 5-10yr |
|| [[id:4a1f23b0-abc7-4def-9876-543210abcdef][6 — Training]] | Verified fine-tuning, neural world model | ~100x fine-tuning only | 3-5yr fine-tuning |
|| [[id:4a1f23b0-abc8-4def-9876-543210abcdef][7 — Remaining]] | Physical threats, oracles, speculation, bootstrap axiom | Mitigations are non-computational | Forever |
Each is described below.
**Systemic analysis:**
**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 is built on [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][Org-mode]] — one format for human and machine, with sparse tree retrieval keeping context lean (2,000-4,000 tokens). The Org file IS the data, not a representation of it. See [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][design-decisions.org]] for the full analysis.
**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. Like the two indices, it is a derived view rebuilt from Org, not a separate canonical copy. When the system learns something new, 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 same format. See [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][design-decisions.org]] for the full argument.
**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 has three decision vectors:
1. **ACL2-verified 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.) This is the deductive layer.
2. **Provenance- and validity-envelope checks for scientific and engineering integrity** — does the empirical model apply in the current context? Are the parameters within their validated range? Is the input within the model's training distribution? These are predicates over the provenance store, not formal proofs. The gate queries the store and blocks or flags computations that fall outside validated bounds. This is the empirical layer — see [[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] for the full framework.
3. **An LLM for natural-language reasoning** — parsing the user's intent, evaluating whether an action falls within policy boundaries that require human judgment, interpreting gate flags and failure diagnostics. This is the probabilistic oracle — it proposes, never executes.
The ACL2 layer (vector 1) is deductive and authoritative where it applies — the LLM cannot overrule a verified denial. The provenance layer (vector 2) is authoritative over model validity — the LLM cannot override a validity envelope violation (though it may recommend a different model). The LLM layer (vector 3) is probabilistic and bounded by both lower layers.
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 three 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.
**Gate decision flow (Stage 2):** An action arrives carrying a domain tag. First, the gate checks the deductive layer — does this domain have registered ACL2-verified boundary procedures? If any denies, reject instantly. The LLM cannot overrule. If no verified procedure denies, the gate checks with Screamer — a constraint network built from rules extracted by the LLM and corrected by humans. Screamer resolves domain-specific constraints, rights, and prohibitions. If Screamer finds a resolution, apply it. If not, the gate asks the LLM. The LLM proposes permit or deny, and the gate re-checks against the deductive boundaries (defense in depth). Every decision is logged to the decision log.
**How domains emerge:** Domain tags are not assigned upfront. 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 domains start empty — no verified boundaries — and fill as mistakes accumulate.
**The autodidactic loop runs in two parallel tracks.**
**Track 1 — deductive hardening:** formal proof generation and gate rule improvement, fast loop, runs autonomously at LLM speed:
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.
**Track 2 — empirical validation:** provenance store improvement and parameter refinement, slow loop, requires experimental feedback:
1. Review computations since the last run where predictions were compared to experimental results.
2. For each comparison, compute the prediction error. If error exceeds the model's stated confidence interval, flag the parameter for review.
3. Parameter review: is the error systematic (model needs recalibration) or random (noise within expected range)?
4. For systematic errors: propose updated parameters (LLM), validate against held-out benchmarks (symbolic engine), update provenance store.
5. Envelope expansion: if a model was used in conditions outside its original validity envelope and the predictions matched experimental data, expand the envelope to include those conditions.
6. Bias profile update: incorporate the new comparison into the model's running bias profile.
7. Community sharing: publish validated parameter updates and envelope expansions through the social protocol.
Track 1 runs every cycle (minutes to hours). Track 2 runs when experimental data arrives (hours to months). Both are essential — the fast loop makes the system more secure; the slow loop makes it more useful for real-world science and engineering. See [[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] for the epistemic framework that motivates this split.
**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.
**Self-developing hardware (Stage 3+):** The hardware side of the Lisp Machine self-improves by synthesizing its own microcode. A Tenstorrent P150 (~72 RISC-V Tensix cores) runs Lisp microcode with one core dedicated to ACL2, one to Screamer, and the rest to gate verification and fact store operations. The system profiles its own gate verification latency, proposes a new microcoded instruction for the hot path, compiles RISC-V assembly from ACL2-verified specifications, loads it via PCIe DMA from within SBCL, benchmarks it — and rolls back if slower. The self-driving threshold: every subdomain involved (RISC-V ISA, SBCL internals, ACL2 metafunctions, compiler optimization) is software — the most codifiable domain — and can flip to symbolic sufficiency within days of ingestion.
**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.
See also:
- [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][Lisp Foundation]] — why Lisp, the prover bootstrapping path, and the ecosystem gap
- [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][Design Decisions]] — the rationale behind the architecture choices
- [[id:d5c6e7f8-9a0b-1c2d-3e4f-5a6b7c8d9e0f][Distinguishing Features]] — the 13-point checklist of what sets this apart
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects over time]] — how verification cascades across society, economics, and geopolitics
**Key analytical frames:**
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis — the unified view]]
- [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Why Lisp is economically viable now — zero marginal cost]]
- [[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] — the epistemic architecture: deductive proofs, provenance-tracked empirical models, and probabilistic oracle
- [[id:efc76898-03f7-57ba-923d-35d65da88bb7][The per-domain sufficiency flip]]
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development velocity and timeline estimates]]
- [[id:aa6d062e-a520-5d14-8773-00687ed9c689][Competitive barriers — moats and infrastructure lock-in]]
**Revenue streams:**
Total addressable market: ~$960B/year across cloud, AI, OS, social media, payments, productivity, and compliance. The business model is the AWS of provable computing: AGPL infrastructure is free, revenue comes from verification appliances, gate rules, certification, namespace registry, hosted PDS, and a [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]].
Short to long term:
- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] — certified Lisp Machine at scale
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain gate packages]] — compliance encoded as gate rules
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Evaluation harness / certification monopoly]] — UL for AI
- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] — hosted personal data stores
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] — verified compute cycles
**Strategy and IP:**
- [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][IP strategy — licensing + patents]]
- [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][Impact on the AI/GPU industry]]
- [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][Upgrade and distribution lifecycle]]
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain gate packages — encoding and products]]
- [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology as proof of the Lisp model]]
- [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][Comparison with Symbolics Genera]]

130
projects/passepartout/architecture/architecture.org
View File

@@ -1,130 +0,0 @@
: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.

2
projects/passepartout/architecture/biomimicry.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-06-01 Mon]
:ID: f6a7b8c9-0d1e-2f3a-4b5c-6d7e8f90abcd
:END:
#+title: Biomimicry in Passepartout — Architecture and Roadmap
#+title: Biomimicry in Passepartout
#+filetags: :passepartout:architecture:neurosymbolic:biomimicry:p150:
**Biomimicry in Passepartout**

100
projects/passepartout/architecture/concept.org
View File

@@ -1,100 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-31 Sun]
:ID: f0e1d2c3-b4a5-6c7d-8e9f-0a1b2c3d4e5f
:END:
#+title: Conceptua
#+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.

100
projects/passepartout/architecture/concept.org~
View File

@@ -1,100 +0,0 @@
: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.

1104
projects/passepartout/architecture/design-decisions.org~
View File

File diff suppressed because it is too large Load Diff

22
projects/passepartout/architecture/distinguishing-features.org
View File

@@ -10,31 +10,31 @@ This is a working list of what distinguishes Passepartout's architecture from al
**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.
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. See [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture.org]] and [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][design-decisions.org]] for the full architecture and design reasoning.
**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.
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. See [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture.org]] for the gate design.
**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.
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. See [[id:design-org-unified-ast][design-decisions.org]] for the full analysis.
**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.
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. See [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][design-decisions.org]] for details on the Wikipedia knowledge seed strategy.
**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.
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. See [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture.org]] for the full address space argument, and [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][design-decisions.org]] for the homoiconicity foundation.
**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.
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. See [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture.org]].
**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.
No central server, no platform dependency. Identity is cryptographic, not account-based. Payment and contracts are native to the protocol, not bolt-ons. See the [[id:4a1f23b0-abc2-4def-9876-543210abcdef][social protocol stage]] for the protocol architecture.
**8. Unified social primer: the Note**
@@ -42,19 +42,19 @@ A single primitive — the Note — serves as message, document, contract, vote,
**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.
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. See [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture.org]] and [[id:5e7f1d2a-3b4c-5d6e-7f8a-9b0c1d2e3f4a][_index.org]] for the full roadmap.
**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.
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. See [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture.org]] for the 10-step loop process.
**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.
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. See [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][design-decisions.org]] for the token economics analysis.
**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.
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. See [[id:5e7f1d2a-3b4c-5d6e-7f8a-9b0c1d2e3f4a][_index.org]] for the full TAM analysis.
**13. Dual growth strategies: social + institutional**

2
projects/passepartout/architecture/faster-theorem-proving.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-06-03 Tue]
:ID: 3129eae6-f9f2-40fe-a419-8c1af728c86d
:END:
#+title: Faster Theorem Proving — Engineering Approaches
#+title: Faster Theorem Proving
#+filetags: :theorem-proving:engineering:performance:ACL2:HOL:search:verification:
* Architecture

163
projects/passepartout/architecture/knowledge-layers/_index.org Normal file
View File

@@ -0,0 +1,163 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 329bd4fb-702a-4a2b-9c63-69281aacb83a
:END:
#+title: Knowledge Layers
#+filetags: :architecture:knowledge-layers:verification:epistemology:
Passepartout's architecture for how the system knows what it knows: deductive proofs (mathematical certainty), provenance-tracked empirical models (statistical validity), and probabilistic oracle (LLM-aided guidance) — all governed by the gate.
These three epistemic layers form a vertical stack: the deductive base provides formal guarantees, the empirical middle bridges mathematics to physical reality through curated data, and the probabilistic oracle generates hypotheses and interprets results within the boundaries set by the lower layers.
---
* Two Engines, One Store
The three layers are not three parallel engines. They are two reasoning engines and one curated data store:
- **The symbolic engine** handles everything that can be formalized: deductive proofs, empirical equations, validity predicates, pipeline composition, uncertainty propagation. This is one engine — it reasons about symbols using rules that are either proven (ACL2) or well-defined (force field equations). It is authoritative where it applies.
- **The probabilistic oracle** (the LLM) handles everything that cannot be formalized: parameter selection, model choice, interpretation of results in natural language, failure diagnosis, creative hypothesis generation. It proposes; the symbolic engine checks. It is bounded — it cannot execute actions, only recommend them.
- **The provenance store** is not an engine. It is a structured database that stores empirical parameter sets, validity envelopes, experimental benchmarks, and comparison histories. Neither engine reasons about it as a whole. The symbolic engine queries it for parameters and validity predicates. The LLM queries it for context and updates it with new data.
The gate is the integration point. Every action is checked against three vectors:
1. **Security policy** — is this action safe? (ACL2-verified gate rules)
2. **Scientific validity** — is this model valid in this context? (provenance store query + validity envelope check)
3. **Consistency** — do the symbolic check and the oracle's assessment agree? If the LLM's recommendation violates a validity envelope, the gate rejects.
* The Knowledge Tree
The layers of human knowledge, from formal foundations to empirical design, mapped to their epistemic status:
| Layer | Domain | Formal status | Verification model |
|---|---|---|---|
| 0. Logic / Foundations | Proof theory, set theory, type theory | Deductive | Complete — provable from axioms |
| 1. Algebra | Groups, rings, fields, vector spaces | Deductive | Complete |
| 2. Analysis | Calculus, limits, real numbers, measure theory | Deductive | Complete (in principle; deep results are hard) |
| 3. Geometry / Topology | Manifolds, differential forms, curvature | Deductive | Complete |
| 4. Classical Mechanics | Lagrangian/Hamiltonian mechanics | Deductive | Complete |
| 5. Quantum Mechanics | Hilbert spaces, operators, Schrödinger equation | Deductive | Complete |
| 6. Statistical Mechanics | Ensembles, partition functions, entropy | Deductive | Complete |
| 7. Electrodynamics | Maxwell's equations, potentials, radiation | Deductive | Complete |
| 8. Quantum Chemistry | Born-Oppenheimer, DFT, coupled cluster | Partially deductive — equations formal, approximations necessary | The implementation is verifiable; the model choice is not |
| 9. Molecular Mechanics | Force fields, potential functions | Empirical parameterization | Simulation is deterministic; parameters fitted to experiment |
| 10. Molecular Dynamics | Integration schemes, thermostats | Deductive mechanics + empirical inputs | Integrator provable; force field parameters are not |
| 11. Chemical Thermodynamics | Binding constants, free energy surfaces | Mixed — statistical mechanics deductive, solvation models empirical | Provenance tracked for empirical components |
| 12. Structural Biochemistry | Protein folding, docking, enzyme kinetics | Largely empirical | Validation against experiment, not deductive proof |
| 13. Organic Chemistry | Reaction mechanisms, functional group transformations | Empirical with formal structure | Mechanism hypotheses falsified by experiment, not proved |
| 14. Molecular Design | Shape-programmable molecules, therapeutic targeting | Empirical design space | Design rules validated by experiment, not derived from QM |
The critical transition is between layers 7 and 8. Everything below is fully formalizable — ACL2 can verify correctness against first principles. Layer 8 introduces the first irreducible approximation (Born-Oppenheimer, DFT exchange-correlation functionals). From layer 9 onward, models are empirical through and through: mathematically rigorous in their execution, but their parameters are fitted to experiment and their validity is provisional.
Passepartout can verify the *computation* at every layer — that the Schrödinger equation is correctly solved, that the MD integrator preserves phase space, that the docking algorithm correctly explores conformational space. It cannot verify that the *model* matches reality. That is the domain of the empirical layer.
* World Model = Verified Equations ⊗ Parameters ⊗ Validity Envelope
Every computation that bridges formal mathematics and physical reality decomposes into a world model triple:
**World Model = Verified Equations ⊗ Provenance-Tracked Parameters ⊗ Validity Envelope**
| Component | What it is | Who handles it |
|---|---|---|
| Verified Equations | The formal skeleton: differential equations, integration schemes, force field functional forms | Symbolic engine — ACL2 verifies the implementation against the mathematical theory |
| Provenance-Tracked Parameters | The numbers that make the model match reality: force constants, partial charges, solvation parameters, scoring weights | Provenance store — each carries a source (paper, dataset, calculation), confidence interval, validity regime (temperature, molecular class, solvent), and last-validation date |
| Validity Envelope | The region of input space where the model has been experimentally validated | Gate — checked as a predicate before execution: is the current input within the model's validated range? |
A force field, for example, is:
- Bond stretching follows Hooke's law (verified equation — proven by the symbolic engine)
- The specific spring constant for a C-C bond is 600 kcal/mol/Ų (provenance-tracked parameter — from Cornell et al. 1995, validated against 50+ small molecules)
- The model is valid for proteins and nucleic acids in aqueous solution at 273-373K (validity envelope — checked by the gate before each simulation)
The three components are inseparable. Without verified equations, the computation is untrustworthy. Without provenance-tracked parameters, the numbers are arbitrary. Without a validity envelope, the user cannot know whether the model applies to their problem.
* The Provenance Store
The provenance store is the infrastructure that makes the empirical layer operational. It is not a single database — it is a structured knowledge base that holds:
**For traditional empirical models** (force fields, solvation equations, scoring functions):
- The functional form of the model (e.g., AMBER ff14SB: harmonic bond + harmonic angle + Fourier torsion + LJ + Coulomb)
- Every parameter with its source (paper, dataset, QM calculation), confidence interval, and validity regime
- Validation history: which experimental measurements have been compared to this model, with what outcome
- Revision history: when parameters were updated, by whom, and what changed
**For neural network models** (ANI-2x, AlphaFold, learned potentials):
- Architecture description and training hyperparameters
- Training dataset provenance (level of theory, molecule coverage, element coverage)
- Validation benchmarks with per-benchmark error metrics
- Distribution summary statistics (needed for the distribution match check)
- Domain of applicability (elements, charge ranges, molecule classes)
**The gate checks:**
For traditional models:
1. Does the model support the elements/atom types in the current input? (parameter availability check)
2. Are the conditions (temperature, pressure, solvent) within the model's validated range? (validity envelope check)
3. Is the input within the model's training distribution? (distribution match check — primarily for neural network models)
For neural network models, check 3 requires new machinery: a distribution match function that computes how similar the current input is to the model's training distribution in latent space. This is a standard technique in reliable ML (distance to training data, density estimation, conformal prediction). It integrates into the gate as a predicate: input within distribution = pass; outside distribution = flag with confidence reduction.
Every check outputs pass, flag with reduced confidence, or block. The gate never silently permits a computation outside a model's validated range.
* Conflict Resolution
The three layers can disagree. The arbitration rules:
1. **Deductive overrides both.** If the symbolic engine (ACL2) proves that a computation is formally incorrect, it is blocked regardless of what the LLM recommends or what the provenance store reports. Formal correctness is the non-negotiable base layer.
2. **Empirical overrides probabilistic.** If the provenance store reports that a model's validity envelope excludes the current conditions, the LLM cannot override that judgment. The LLM may recommend a different model, or the gate may flag for human review — but it cannot proceed with the invalid model.
3. **Probabilistic proposes, never executes.** The LLM recommends model selections, parameter choices, and design alternatives. Every proposal is checked against the deductive layer (formal correctness) and the empirical layer (validity envelope) before execution. The LLM cannot write a file, run a command, or send a message — it can only propose.
4. **Human override is always recorded.** A user can override any layer's judgment. The override is logged to the provenance chain with the user's signature and reason. The result of an overridden computation is tagged as "human override — bypassed [layer] check" with reduced default confidence.
5. **Uncertainty propagates upward.** If two empirical models disagree, the system reports both results with their respective confidence intervals and a flag: "Models disagree by 2.3 kcal/mol. Model A's uncertainty: ±0.8 kcal/mol. Model B's uncertainty: ±1.1 kcal/mol. Recommend experimental validation." The gate does not force agreement; it reports the conflict transparently.
* Cold Start
The provenance store must be populated with validated data before it can enforce validity envelopes. The bootstrap sequence:
1. **Seed from curated sources.** Initial parameter sets from established force fields (AMBER, CHARMM, OPLS), benchmark datasets (PDBbind, COMP6), and published experimental reference data are loaded with explicit provenance tagging. Each entry is marked "unverified by this instance" but carries its original source citation.
2. **LLM provides provisional parameters.** For domains where no curated data exists, the LLM proposes parameter values based on training data knowledge. These are tagged as "unvalidated — LLM-sourced" with reduced confidence and clearly marked validity envelopes.
3. **Validation through use.** Every time the system runs a computation and receives experimental feedback (or the user provides a measurement), the comparison is recorded. Disagreements between prediction and measurement trigger parameter updates. Over hundreds of comparisons, the provenance store's confidence intervals tighten.
4. **Community amplification (Stage 1+).** Through the social protocol, instances share validated parameter sets with provenance chains. A force field validated by one instance for ethanol and another for DMSO accumulates a broader validity envelope than either alone. The network effect compounds the cold-start investment.
The cold start never reaches the same confidence as a mature instance with years of experimental feedback. But even a seeded provenance store with provisional parameters is strictly better than a system with no provenance — because the provisional parameters are explicitly tagged as provisional, and the user can see the confidence for every result rather than trusting a single unmarked number.
* Mapping to Stages
The knowledge-layers infrastructure is staged, not all-at-once:
- **Stage 0 (current).** The probabilistic oracle exists (the LLM). The provenance store does not. The deductive engine partially exists through Hermes skills (symbolic gate rules as Python, not ACL2). The empirical layer is invisible — the LLM reasons about chemistry, biology, and engineering using training data alone, without systematic provenance.
- **Stage 1 (social protocol).** The provenance store prototype can be introduced as a side effect of signed messages and data exchange. When instances share a validated parameter set, the message carries a signature and source. The receiving instance stores it with provenance. Natural crawl before full infrastructure.
- **Stage 2 (gate as software).** The provenance store becomes operational infrastructure. The gate checks scientific validity alongside security policy. The provenance store integrates with the Knowledge subsystem as a structured data store — the symbolic index holds formal facts; the provenance store holds empirical parameters. Same storage mechanism, different data type.
- **Stage 3 (Lisp machine).** The symbolic engine is native in one address space. ACL2 runs at hardware level. The provenance store becomes a native Lisp hash table with persistence. The gate checks validity predicates in the evaluation loop itself. The LLM proposes model selections; every proposal is verified against the provenance store before execution. All three layers in one address space.
- **Stage 4+ (in-process inference).** The LLM moves in-process. All three components share one address space. No IPC between them. The query cycle is: LLM proposes → symbolic engine checks against provenance store → if valid, execute → if invalid, return to LLM with diagnostic. This loop runs at native speed.
* What This Changes in the Architecture
The knowledge-layers model adds a dimension to the existing architecture that was only implicit before:
1. **The gate gets a third vector.** Previously the gate checked security (is this action safe?) and, through its ACL2 verification, mathematical correctness. Now it also checks scientific validity (is this model valid in this context?). The mechanism is the same — a policy evaluated before the computation proceeds — but the policy now includes predicates over empirical model applicability, not just safety and formal correctness.
2. **The autodidactic loop gets two speeds.** The fast loop (deductive — generate code, prove it, hot-reload) runs autonomously at LLM speed. The slow loop (empirical — make prediction, get experimental data, update parameters) requires real-world feedback and cannot run without it. Both are essential. The fast loop makes the system mathematically powerful; the slow loop makes it useful for real-world science and engineering.
3. **The provenance store is a new data type in the Knowledge subsystem.** It is neither the symbolic index (formal facts) nor the neural index (embedding vectors). It is a third index: parametric, uncertain, provisional — but no less essential for its lack of deductive certainty.
4. **The gate becomes a configurable integrity layer.** Security, scientific validity, ethical constraints, legal constraints, economic constraints — all expressed as predicates over the computation's inputs, models, and parameters. Users, institutions, or jurisdictions can configure different policies without changing anything else in the system. Compliance becomes configuration.
---
See also:
- [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][Lisp Foundation]] — the prover bootstrapping path that enables the deductive layer
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the gate, subsystems, and staged progression
- [[id:4b5c6d7e-8f9a-0b1c-2d3e-4f5a6b7c8d9e][Neural Networks in the Empirical Layer]] — how trained models fit into the provenance framework
- knowledge-layers/practical-implications.org — concrete consequences for design, safety, regulation, and trust
- [[id:f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f][Schafmeister and Clasp]] — existence proof: Lisp in computational nanotechnology

4
projects/passepartout/architecture/three-pronged/neurological-software-empirical-middle.org → projects/passepartout/architecture/knowledge-layers/neurological-empirical.org
View File

@@ -7,7 +7,7 @@
The empirical middle of the knowledge tree (layers 8-14) is increasingly dominated by neural networks trained on data — not symbolic equations with fitted parameters. ANI, MACE, SchNet for molecular energies and forces. AlphaFold for protein structure prediction. Neural docking scores, learned solvation models, QSAR neural nets, RL-based molecular design agents. These are not traditional empirical models with interpretable parameters. They are learned function approximators with millions of inscrutable weights.
The three-pronged architecture must accommodate them. This note analyzes how.
The knowledge-layers architecture must accommodate them. This note analyzes how.
**What changes when the model is a neural network.**
@@ -118,7 +118,7 @@ All three are handled by the same provenance store, the same gate predicates, an
**The summary.**
Neural network models trained on empirical data are not a problem for the three-pronged architecture. They fit into the existing framework:
Neural network models trained on empirical data are not a problem for the knowledge-layers architecture. They fit into the existing framework:
- **The provenance store** tracks training data sources, validation benchmarks, and distribution statistics — instead of parameter sources and confidence intervals.
- **The gate** checks domain match and training distribution coverage — instead of validity envelopes and parameter regimes.

101
projects/passepartout/architecture/knowledge-layers/practical-implications.org Normal file
View File

@@ -0,0 +1,101 @@
:PROPERTIES:
:CREATED: [2026-06-04 Tue]
:ID: 5c6d7e8f-9a0b-1c2d-3e4f-5a6b7c8d9e0f
:END:
#+title: Practical Implications of the Knowledge-Layers Architecture
#+filetags: :architecture:knowledge-layers:implications:design:
What the knowledge-layers model — deductive proofs, provenance-tracked empirical models, and probabilistic oracle — means for design, engineering, science, software, and trust. These are concrete consequences, not abstract possibilities.
---
* Design World Aware of Its Physics
The most vivid implication: a design environment where the constraint solver IS the physics engine, and every parameter carries its epistemic status.
Currently, design software pretends material properties are true numbers. You pick "steel" from a dropdown, the system shows Young's modulus = 200 GPa, and you design to that single value. But that value is an average across 50 samples from different suppliers. The actual value for your specific part is between 190 and 210 GPa, and the software never tells you.
With provenance-tracked empirical models, every parameter in the constraint network carries its source, confidence interval, and validity envelope. The constraint solver propagates uncertainty automatically. The designer sees distributions, not single numbers:
- The assembled clearance at a joint: 0.03-0.08mm, not 0.05mm flat
- The confidence this design meets specification under rated load: 95%, with a breakdown (material uncertainty 3%, manufacturing tolerance 1.5%, load model 0.5%)
- Material selection as a query with confidence thresholds: "yield strength > 250 MPa, validated at 400°C, at least 3 independent measurements from peer-reviewed sources"
- Tolerance stack-up as an automatic consequence of provenance — the ISO tolerance grades of each component propagate through the constraint network
The gate constrains what the designer can even specify. Design a seal for 500°C continuous operation. The provenance store reports: "This material's empirical model is validated to 300°C. Above that, the only data is a single 1973 paper with a 2x extrapolation factor and no confidence interval." The gate flags it. The designer must explicitly accept the risk (logged to the provenance chain) or select a material with better empirical coverage.
Manufacturing feedback closes the loop: as-manufactured dimensions and measured friction coefficients write back to the provenance store. The next design iteration has tighter confidence intervals. Datasheet revisions propagate retroactively: a bearing manufacturer's 2025 revision shows a lower load rating than the 2022 datasheet; the gate re-checks all designs using that bearing and flags any that now fall below required safety margins.
This is what "design world aware of its physics" means in architectural terms: the constraint solver enforces geometric consistency (deductive layer), the provenance store enforces parametric validity (empirical layer), and the gate enforces that neither can be violated without explicit override.
[[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] — the three-layer architecture that makes this possible
* Ten Practical Powers
What the system can do with all three layers operating together that a conventional system cannot:
**1. It can tell you how wrong every result might be.**
Every output carries an uncertainty budget: binding affinity -9.2 ± 1.4 kcal/mol, broken down by source (force field ±0.8, solvation ±0.5, sampling ±0.3, scoring ±0.6). No computational chemistry package does this today — every one outputs a precise-looking number and leaves uncertainty to the scientist's judgment.
**2. It can prevent you from using a model outside its valid range.**
A force field parameterized for soluble proteins at room temperature gives plausible-looking numbers for a membrane protein at body temperature. The gate catches this: "This force field was validated for aqueous solutions of soluble proteins at 273-373K. Your simulation involves a lipid bilayer. Three parameters are outside their validated range. Confidence reduction: 40% if you proceed."
**3. It can detect when a model is getting worse.**
Every model version is tracked. When a superseded force field is used, the gate flags: "AMBER ff99 was superseded by ff14SB in 2014 and ff19SB in 2019. The newer parameter sets improve backbone dihedral prediction by 30%. Migrate?"
**4. It can compare predictions to experiments automatically.**
Every computational prediction matched to an experimental measurement builds a systematic bias profile: "This force field consistently underestimates binding affinity for charged ligands by 0.5-1.0 kcal/mol." These profiles accumulate across all computations, making future predictions more interpretable.
**5. It can red-team its own reasoning.**
The LLM proposes a conclusion. ACL2 checks the formal steps. The provenance store checks model validity. If all three agree, the result is as reliable as the system can make it. If they disagree: "The mathematics checks out, but the models supporting it are outside their validated range. Your conclusion may be mathematically correct but physically unsupported."
**6. It can build a community knowledge graph of what works.**
Through the social protocol, instances share validated parameter sets. A force field validated by one instance for ethanol and another for DMSO accumulates a validity envelope broader than either alone. The network effect compounds.
**7. It can generate a defensible record for regulatory submission.**
Every simulation carries a full provenance chain: model version and source, parameter validation, solver settings, gate checks passed, uncertainty budget. For FDA/EMA-regulated industries, this is the difference between a simulation used for guidance and one accepted as evidence.
**8. It can be wrong honestly.**
Every result carries its epistemic label: "deductively proven (ACL2-verified)," "empirically validated within validity envelope," or "extrapolation outside validated range — low confidence, for hypothesis generation only." The system does not ask the user to trust it. It shows what it knows and how it knows it.
**9. It can refuse an unsound instruction.**
"I will not run this simulation. The requested temperature (500K) exceeds the force field's validated range (273-373K). The solvent (hexane) has no validated parameters. The simulation will produce numerically precise but physically meaningless results." The override exists but is recorded, and the result is tagged with its true confidence.
**10. It can connect mathematics to reality without faking it.**
A finite element analysis of a bridge: "The equations are verified against classical mechanics (layer 4). The material parameters come from ASTM standard tests (layers 8-9, validity envelope: -20°C to 60°C, validated by 200+ measurements). The load calculations carry ±3% uncertainty." The bridge is not proven safe — no software can prove a physical structure is safe — but the chain from mathematical foundation to empirical measurement is fully transparent.
* Schafmeister and Clasp: Existence Proof
Christian Schafmeister's work at Temple University is the strongest existence proof for the knowledge-layers architecture. He created [[https://github.com/clasp-developers/clasp][Clasp]], a Common Lisp implementation that interoperates with C++ libraries via LLVM compilation, specifically to design spiroligomers — shape-programmable molecules that bind proteins as therapeutics.
Why this proves the architecture:
1. **Lisp is already used for molecular design.** Schafmeister's team runs computational chemistry pipelines from within a Lisp environment, funded by the NIH and NSF. The interactivity and homoiconicity that the knowledge-layers architecture relies on are the same properties that make this work possible.
2. **The single-address-space model is not a retro fantasy.** Clasp proves you can run C++ libraries inside a Lisp image, not alongside it. The Lisp machine is a practical architecture being used today for computationally demanding scientific work.
3. **Schafmeister's pipeline spans the entire knowledge tree.** QM calculations (layer 8) feed force field parameterization (layer 9), which feeds MD simulations (layer 10), which feed binding free energy predictions (layer 11), which feed docking studies (layer 12), which guide experimental design (layer 14). Every layer's output is an input to the layer above, and every layer has a different epistemic status — from provable QM through empirically parameterized force fields through heuristic design rules.
The main difference in direction: Schafmeister brought C++ into Lisp to access the scientific computing ecosystem. The knowledge-layers architecture replaces C++ libraries with verified Lisp-native alternatives. The principle — one representation, one address space, no translation boundaries — is the same.
* Truth as an Epistemic Property, Not a Brand
The deepest shift the knowledge-layers model enables: computation becomes epistemically transparent.
Currently, computational results are trusted based on popularity. "Everyone uses this software" is the epistemic warrant. The knowledge-layers model replaces this with an explicit chain: this equation was verified against classical mechanics, these parameters come from a specific experimental paper, this validity envelope covers the conditions you specified. Trust moves from "the tool is popular" to "the chain is traceable."
This changes the economics of computational trust. A result that is deductively proven can be used as a building block for further proofs — its truth is inherited by any derivation. A result that is empirically validated is useful for design decisions with known risk. A result that is an LLM extrapolation is useful only for hypothesis generation. Computational results become differentiated products, not interchangeable commodities. Provenance quality is the differentiator.
For reproducibility: the provenance chain is a complete specification. Every computation is fully described by its model, its parameters, its validity envelope, and its gate checks. Reproducing the computation is loading the same chain and running it. No more "we used the AMBER force field" without version, parameter set, cutoff scheme, or solvation model.
For regulatory science: a regulator can read the output and see exactly what was computed, with what models, under what conditions, with what uncertainty. Review shifts from auditing the company's process to auditing the computation's chain.
For education: students develop epistemic hygiene as a side effect of using the system. Every computation they run shows them whether the result is proven, validated, or generated — making visible the distinction that current software hides behind uniformly precise-looking numbers.
---
See also:
- [[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] — the architecture that makes these powers possible
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the gate, subsystems, and stage plan
- [[id:f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f][Schafmeister and Clasp]] — Lisp in computational nanotechnology
- ideas/lisp-geometry-engine — the geometry engine as concrete illustration of design-world-aware-of-physics

208
projects/passepartout/architecture/lisp-foundation.org Normal file
View File

@@ -0,0 +1,208 @@
:PROPERTIES:
:CREATED: [2026-06-03 Tue]
:ID: 971cd9e7-2cc5-4743-8042-2469dbe4078f
:END:
#+title: Lisp Foundation
#+filetags: :passepartout:architecture:common-lisp:prover:ACL2:HOL:
#+STATUS: active
Passepartout's architecture — verified gate, single address space, self-modifying agent — depends on running on a Lisp that can be proved correct. This document explains why Lisp is the right foundation, what gaps remain in the current ecosystem, and how the prover bootstraps from ACL2 to a verified HOL kernel to a self-verifying stack. It is the "Lisp layer" of the architecture, alongside the four-subsystem description in [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture.org]] and the design rationale in [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][design-decisions.org]].
* What It Is and Why
Common Lisp is a language from the 1990s with a 1950s syntax, a 1970s package manager, and a 2000s type system — yet it has never been beaten on its core bet: unmatched macro facility, interactive development, image-based workflow, and the most powerful bottom-up programming model ever designed. The Lisp foundation work within Passepartout is a systematic effort to bring the Lisp ecosystem forward by 25 years without sacrificing the language's defining character.
This is not a language fork. It is an ecosystem upgrade that preserves the 1994 ANSI standard while adding modern conventions (lockfiles, LSP, standard library, static binaries) and a verified prover (a HOL kernel verified by ACL2) that makes Lisp the safest language to write self-modifying code in — which is exactly what Passepartout is.
**Why Now — The Economic Flip**
The 1980s trade-off was: C is cheap enough for the market. Correctness is a luxury the market cannot afford. The 2020s trade-off: C is expensive for the market. Incorrectness has become the dominant cost of software, and Lisp's verification infrastructure is now the cheaper option.
Four transformations flipped the economics:
1. **Memory is free.** 40MB runtime is noise on a $20 Raspberry Pi with 8GB RAM. In 1980, DRAM was ~$5,000/MB.
2. **Transistors are free.** Billions of gates on a modern ARM core — GC and type dispatch cost nothing because the transistors are there whether used or not.
3. **Complexity saturates human verification.** Systems are tens of millions of lines. Testing is necessary but insufficient — zero-day vulnerabilities prove bugs survive all testing. Formal verification is the only known path to guaranteed correctness.
4. **Cost of failure exceeds cost of verification.** A single breach costs millions. Regulation mandates provable compliance. Proving correctness is cheaper than not proving it.
The [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] costs $5,000/year and replaces $500,000/year in compliance audits, breach litigation, and regulatory fines. This cost structure — zero marginal cost per additional user — is what makes Lisp economically viable at scale.
* Why Lisp Is a Uniquely Good Candidate
Every language has a different starting position for bootstrapping an AI agent that improves its own compiler and toolchain while running on itself. Lisp's is the strongest. Here is why:
**1. Homoiconicity — the prover works on the same artifact the programmer does.**
The AST of a Lisp program is an S-expression — the same data structure the language uses for everything else. A prover in Lisp reads code as nested lists, transforms it, annotates it, and outputs modified code without a parse/unparse cycle. In Rust or Python, the prover would need a full parser, a serializer, and to handle every AST change as a diff against the source text — introducing a translation gap where the prover's internal representation and the programmer's source can drift apart. In Lisp, the internal representation /is/ the source. This is the difference between a prover that can be built in 800 lines (HOL Light kernel) and one that requires 20,000 lines of parser, pretty-printer, and AST library.
**2. ACL2 — a verified Lisp prover already exists.**
ACL2 is a first-order theorem prover written in and for a subset of Common Lisp. It is meta-circularly verified — its kernel is proved correct in ACL2. This means there is a verified prover /already running in Lisp/ that can verify a higher-order kernel (HOL Light's ~400 lines). ACL2 does the first verification for free:
#+BEGIN_EXAMPLE
SBCL runtime → ACL2 (verified by its own meta-circular proof)
→ HOL kernel (verified by ACL2)
→ any HOL theorem (proved by HOL kernel)
#+END_EXAMPLE
No other language has an existing verified prover that runs in the same runtime as the programs it verifies. Rust has none. Python has none. Lean has a verified kernel but the prover language is separate from the target language, creating a semantic gap.
**3. Code density 3-5×.**
Lisp's code density is 3-5× higher than C, Rust, or Go for the same semantic work. This is a maintenance claim, not a performance claim: fewer lines have fewer bugs, fewer attack surfaces, fewer compliance gaps. When the prover can verify those lines, the remaining surface shrinks further.
**4. The type system is additive, not prescriptive — Coalton proves it.**
Coalton embeds sound Hindley-Milner typing inside Common Lisp, preserving homoiconicity. You opt in per-file. This is the opposite of Rust, where type soundness is mandatory across the entire program. For a self-improving agent, the additive model is strictly better — it lets the agent work in a fluid, untyped style for exploration and lock down types for verification.
**5. Everything else is ecosystem, not language.**
Unicode handling, pattern matching, async I/O, immutable data structures, module systems, error messages — every one of these is a library or convention, not a language feature gap. Clojure proved this on the JVM: twenty years of CL ecosystem neglect can be fixed with sufficient automation. The gap is not in Lisp's capacity — it is in the community's labor supply, and an AI agent working at 10× human velocity changes that equation.
* The Gap: What Needs Fixing
**What cannot be fixed** without changing what Lisp is:
- GC pauses — everything is a tagged pointer on the heap; mitigatable (generational, concurrent collectors) but not eliminatable on commodity hardware
- No memory model / no Send/Sync — threads share everything by default; concurrency correctness is a discipline, not a compiler guarantee
These are genuine costs, but they are contingent on hardware, not laws of nature. Symbolics' Genera OS ran on the Ivory processor with hardware tag checking and single-cycle CONS allocation — Lisp was a systems language when the chip was designed for it. A [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][RISC-V Lisp extension with ~50K gates]] eliminates the hardware mismatch. Without dedicated silicon, modern concurrent generational GCs (single-digit millisecond pauses) are acceptable for everything Passepartout does.
**What can be fixed — the performance gap** (10-20% on hot numerical code):
| Investment | Effort | The problem |
|------------|--------|-------------|
| Alias analysis pass for SBCL's IR | ~1-2 person-years | Rust's borrow checker gives LLVM perfect aliasing at function scope; SBCL conservatively assumes anything could alias anything |
| LLVM backend (Clasp maturity) | ~5-10 person-years | Clasp's hybrid fast-path/slow-path is the right design; needs engineering to match SBCL's general performance |
| PGO feedback loop | ~1 person-year | SBCL has profiling (sb-sprof) but no mechanism to reweight branches or layout hot/cold blocks |
| Portable SIMD abstraction | ~2-3 person-years | Every ISA extension needs its own VOP set; no equivalent of xmmintrin.h |
| Post-link optimization | Research problem | SBCL's trampoline-heavy code layout chokes tools like BOLT |
**What can be fixed — the ecosystem gap:**
| Feature | Rust | Common Lisp |
|------------------|------------------------------------|------------------------------------|
| Package manager | Cargo (lockfile, binary cache, workspace) | Quicklisp (no lockfile, source-only) |
| LSP | rust-analyzer | No universal LSP |
| Formatter | rustfmt (universal) | cl-form (not universal) |
| Linter | Clippy (>700 rules) | No equivalent |
| Documentation | rustdoc (integrated) | Conventions only |
| Cross-compilation| --target flag | Manual, source-based |
| Test framework | Built-in with benchmarks | Various (FiveAM, Prove) |
| Sanitizers | ASan, TSan, MSan, UBSan | None |
| Library count | ~180k | ~2k |
| WASM target | First-class | Modest |
| Mobile targets | First-class | None native |
The largest gaps are the package manager (the single highest-leverage investment — ~2-3 person-years) and the library count (~100× fewer). The library count follows from the lack of a modern build tool, not from a lack of demand.
**Common misconceptions:**
- Unpredictable performance is not a language defect — write in a disciplined subset with type declarations and SBCL compiles to within 2x of C on hot paths
- Macros do not cause unpredictability; they enable styles that confuse the optimizer. The choice is the programmer's.
- The numeric tower is a genuine trade-off: mathematically correct, but blocks SIMD and the overflow assumptions that make Rust's arithmetic fast. Choose based on domain.
* The Prover Architecture
An autonomous prover closes the gap between Lisp's flexibility and Rust's guarantees without making Lisp rigid. The prover sits between the programmer and the compiler:
#+BEGIN_EXAMPLE
[Lisp code] → [Passepartout prover] → [SBCL compiler] → [binary]
↑
[Verified: race-free, type-safe, bounded memory, constant-factor performance]
#+END_EXAMPLE
The prover proves memory safety without a borrow checker (by analyzing call graphs and data flow), performance predictability (by unfolding macros and constructing SSA form), and type soundness across untyped CL code (by inferring types and flagging contradictions). The language stays fluid — the prover is an external constraint, not a compiler-enforced limitation. The programmer can always bypass it for fast prototyping.
**ACL2 is the right foundation but not the complete solution.** It is first-order, interactive, restricted to a pure subset of CL, and does not scale to everyday production code without massive human effort. But ACL2 proves the architecture is viable: a Lisp-based prover verifying Lisp programs is natural, not forced.
**Bootstrapping a HOL prover via ACL2 + Screamer** — the HOL kernel (HOL Light: ~400 lines of OCaml, 10 primitive inference rules) is a well-known artifact, an engineering task rather than a research problem:
1. Transcribe the HOL kernel into pure CL (~500-800 lines)
2. ACL2 verifies the kernel implements the inference rules correctly
3. Screamer provides the proof search engine (backtracking maps to proof tree exploration)
4. HOL proves meta-level properties: macro soundness, evaluator equivalence, compositionality of skills, safety of self-modification
5. HOL theorems are reflected back as ACL2 rewrite rules — automation compounds
The HOL kernel is an ideal LLM task — small, fully specified, stateless, with unambiguous correctness criteria. ACL2 filters hallucinations. Iteration converges in 2-3 attempts.
**The self-writing machine** does not prove itself from the void. It proves each next step using everything proven before. The writer (LLM) is allowed to be heuristic. The prover only needs to be conservative and accurate. Every time a human signs off on a proof, it becomes future automation.
* Why Passepartout Changes the Equation
The standard model for closing the library gap is: *more users → more libraries → more users.* Passepartout's model is: *agent synthesizes libraries on demand → fewer blockers → more users.*
**Knowledge-capture replaces community-coordination.** The rate-limiter shifts from "people who can write Lisp libraries" to "people who can explain their domain well." A 3-hour conversation with a domain expert captures the specifications, invariants, and correctness criteria. The agent synthesizes the library, verifies it via the prover, and hot-reloads it.
**The same compression applies to social infrastructure.** The Passepartout architecture compresses the social ecosystem the same way it compresses the software ecosystem — replacing multiplicative duplication with additive specification. Twitter (~10M lines), Facebook (~60M), Reddit (~5M), Discord (~8M), Signal (~3M) — each independently implementing identity, messaging, groups, moderation, federation, access control — collapses to one verified spec stack (~5,000 lines) with per-community gate policies (~100 lines each). This is the same principle as the library gap: multiplicative maintenance burden collapses to additive specification complexity, amplified by Lisp's density and the prover's correctness guarantees.
**Passepartout's position to direct Lisp development:**
1. **Instrumentation advantage.** It runs in Lisp, can profile its own execution in Lisp terms, identify SBCL's compiler bottlenecks, and generate patches — all in a closed feedback loop that C compilers lack.
2. **Coordination advantage by adoption.** If Passepartout becomes the standard Lisp agent framework, its tooling choices become de facto standards: ocicl with lockfiles becomes the package manager, cl-lsp gets maintenance, the PGO pipeline gets built.
3. **Automated contribution pipeline.** Profile → identify hot path → generate candidate VOP or optimization pass → run test suite (verified by ACL2) → submit patch. Cycle time drops from years to days.
4. **The prover multiplier.** The agent can generate thousands of variants, verify correctness, benchmark, and keep the Pareto-optimal set — coverage a human cannot match.
**Timeline compression.** The gap-closing problem goes from "we need enough talented volunteers" to "we need enough compute" — and compute grows on a known exponential, while talent doesn't:
| Gap | Human-only | AI-assisted | Passepartout loop |
|------------------------|-----------|-------------|------------------|
| SBCL alias analysis | 18 mo | 10 mo | 3-4 mo |
| PGO pipeline | 12 mo | 6 mo | 2-3 mo |
| Cargo-equivalent | 24 mo | 8 mo | 4-6 mo |
| LSP server | 18 mo | 6 mo | 3-4 mo |
| RISC-V Lisp extension | 24 mo | 12 mo | 6-8 mo |
| Library coverage (100 APIs) | 3-5 yrs | 12 mo | 3-4 mo (synthesis) |
| Clasp maturity | 5-10 yrs | 3-5 yrs | 1-2 yrs |
* Landscape Impact
**Rust has the most to lose.** Its entire value proposition is compile-time safety. An AI prover that verifies the same properties about Lisp code makes the borrow checker a solved problem. Rust keeps its advantage only as long as the prover is slower and more expensive than a type system that runs in milliseconds. Once the prover matches or exceeds Rust's guarantees — memory safety, race freedom, constant-factor performance — the choice between Lisp and Rust becomes about workflow preference, not safety.
**Python and JavaScript have the most surface to gain.** Statically proving correctness of dynamically-typed programs becomes tractable through a verified Lisp intermediate (several transpilers exist). Python and JS gain type soundness, no null pointers, and thread safety without changing the language.
**Lean is not a competitor.** Lean is for interactive theorem proving in mathematics — mathlib4 has over 100,000 theorems, a dedicated community, and an elaborator built from decades of type theory research. Passepartout's prover verifies *running code*, not abstract mathematics. Its design optimizes for program properties (memory safety, race freedom, macro soundness), not mathematical expressiveness.
* Hardware Endpoint
A Lisp ASIC (Symbolics Ivory, CADR, or a modern tagged RISC-V variant) raises the floor more than the ceiling:
- Tag checking on every memory access — types, GC bits, forwarding pointers in parallel with ALU
- Hardware CONS — single-cycle allocation with automatic write barriers
- Hardware GC support — generational barriers at cache level
- Hardware generic function dispatch — type-code lookup in CAM instead of method cache
- Hardware stack groups and shallow binding — zero-cost special variable rebinding
The worst case becomes much faster — naive code and optimized code are closer together. The ASIC shifts the optimizer's job from "avoid Lisp overhead" to "use special instructions effectively." The gap between C and Lisp on hot numerical loops narrows from ~20% to maybe 5%.
**RISC-V Lisp extension (near-term, ~50K gates):** ~5 new instructions (CONS with write barrier, tag dispatch, read barrier, tag extract, GC check). Implementable as an FPGA soft-core. Makes Lisp viable where C is currently mandatory — real-time control, sensor nodes, IoT — by eliminating allocation cost and GC pause unpredictability. The gap goes from 10-100× to ~2-5×.
Strategic play: Define the extension, open-source an FPGA implementation, get it ratified as a standard RISC-V extension. Then any chip vendor can add it.
* The Plan
The prover must come first. An unverified base cannot bootstrap a verified upper layer. The order flips from /easiest first/ to /most foundational first/:
| Phase | What | Timeline | Key risk |
|-------|------|----------|----------|
| 0 | **Verified HOL kernel** (~500-800 lines of CL). Transcribe HOL Light's 10 primitive inference rules, verify with ACL2. | 2-4 months | ACL2 iteration time |
| 1 | **Minimal verified build system.** Deterministic lockfiles, enough to compile the prover, LSP, and itself. Only deps and compilation need proving; IO layer stays trusted. | 4-6 months | IO verification boundary |
| 2 | **Verified LSP server.** Bridges SBCL's compiler to the LSP protocol — online mode (connected image) and offline mode (static analysis). | 6-8 months | SBCL's type inference was designed for compile-time warnings, not a responsive protocol |
| 3 | **Coalton + verified standard library.** Hash sets, priority queues, JSON, HTTP, async, immutable data structures — all proved correct. Largest phase by volume. | 12-18 months | Proof costs at scale; assumes agent compounds its own proving capability |
| 4 | **Self-hosting, self-verifying CL stack.** The toolchain compiles itself. The compiler is verified. Passepartout proves its own transformation rules correct. | 6-12 months | Self-verification bootstrapping is the hardest problem in proving |
| | **Total** | **~2-5 years** | |
What accelerates this: an existing CL community contributing modules to verify; leveraging proofs from Coq, Lean, and Isabelle rather than proving from scratch; an LLM that compounds its own capability in the domain.
* Expected Impact
**On Lisp development:** macro soundness guaranteed by the prover rather than programmer discipline; concurrency bugs caught at compile time; type inference across untyped code via the LSP; library import as a one-line =cl add= with deterministic lockfiles; deployment as =cl build --release= producing a static binary.
**On Passepartout itself:** a verified Lisp stack means every self-modification is proved safe before it applies. No LLM hallucination propagates into the running system. The machine is no longer gambling on correctness.
**On specification-level verification:** a shift from /testing as correctness/ to /proof as correctness/. Testing becomes a fallback for properties the prover cannot yet establish, rather than the primary correctness mechanism. The attack surface for implementation bugs drops to near zero for any program the prover can analyze.
See also:
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the four-subsystem description that this Lisp foundation enables
- [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][Design Decisions]] — the rationale for the architecture choices detailed here
- [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology parallels]] — why Lisp architecture is a natural outcome of complexity pressure
- [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][Comparison with Symbolics Genera]] — historical precedent for Lisp as a systems language

2
projects/passepartout/architecture/neuro-neuromorphic-symbolic-comparison.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-06-01 Mon]
:ID: a7b8c9d0-1e2f-3a4b-5c6d-7e8f90abcdef
:END:
#+title: ANN vs Neuromorphic vs Symbolic — When Each Mathematics Fits
#+title: ANN vs Neuromorphic vs Symbolic
#+filetags: :passepartout:architecture:neurosymbolic:math:
**ANN vs Neuromorphic vs Symbolic**

2
projects/passepartout/architecture/security.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-05-24 Sun]
:ID: 1c95ce7d-a2db-506a-9608-df68f9ae211b
:END:
#+title: Lisp Machine Security — Unified Memory Threat Model
#+title: Lisp Machine Security
#+filetags: :passepartout:security:lisp-machine:pmp:isolation:
On a bare metal [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Lisp Machine]] with a unified Lisp image, the defense-in-depth provided by the OS kernel disappears. The gate stack and the code it protects share a single address space. An attacker who exploits a memory corruption in the browser renderer can modify the gate stack's permission tables, the policy engine's state, or the ACL2 prover's decision output. There is no kernel underneath to catch them.

16
projects/passepartout/architecture/self-developing.org
View File

@@ -1,16 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70
:END:
#+title: The Self-Driving Lisp Machine
#+filetags: :passepartout:lisp-machine:hardware:riscv:tenstorrent:
A Tenstorrent P150 (~72 RISC-V Tensix cores) running Passepartout: 72 RISC-V cores running Lisp microcode, one core dedicated to ACL2, one to Screamer, the rest to gate verification and fact store operations.
The self-driving threshold: the system can synthesize and load its own FPGA microcode or Tensix dispatch programs from within the running Lisp image. The system profiles its own gate verification latency, proposes a new microcoded instruction for the hot path, compiles RISC-V assembly from ACL2-verified specifications, loads it via PCIe DMA from within SBCL, benchmarks it — and rolls back if slower.
Every subdomain involved is software — the most codifiable domain. RISC-V ISA, SBCL internals, ACL2 metafunctions, CIC type theory, compiler optimization — all can [[id:efc76898-03f7-57ba-923d-35d65da88bb7][flip to symbolic sufficiency]] within days to weeks of ingestion.
**Timeline:** ~6,000 lines of new code (microcode, PCIe DMA, Tensix management, benchmark harness). ~60 cycles at current velocity. 2-4 weeks. Total from today: 6-10 weeks. See [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]] for the velocity model behind these numbers.
The Tenstorrent approach is dramatically simpler than FPGA because the microcode is RISC-V assembly (software), not FPGA bitstream (hardware with minutes-per-iteration synthesis). The [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine security model]] — unified memory, tagged architecture, no MMU — applies directly because the Tensix cores share the same address space. [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] economics apply: a certified Lisp Machine at scale replaces compliance hardware. See [[id:9af13fff-9725-542b-93b1-a555bc74ad72][why Lisp is economically viable now]] and [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][upgrade lifecycle]] for the economic and deployment foundations.

2
projects/passepartout/architecture/stages/stage-0-now.org
View File

@@ -1,5 +1,5 @@
---
title: Stage 0 — Now (Conventional Computing)
title: Stage 0
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24

2
projects/passepartout/architecture/stages/stage-1-dependency-map.org
View File

@@ -1,5 +1,5 @@
---
title: Stage 1 — Full Library Dependency Map
title: Stage 1
type: reference
tags: :passepartout:architecture:social-protocol:dependencies:
created: 2026-05-28

2
projects/passepartout/architecture/stages/stage-2-acl2-integration.org
View File

@@ -1,5 +1,5 @@
---
title: Stage 2 Architecture — ACL2 Integration and Risk Profile
title: Stage 2 Architecture
type: reference
tags: :passepartout:architecture:gate:acl2:
created: 2026-05-28

2
projects/passepartout/architecture/stages/stage-2-verification.org
View File

@@ -1,5 +1,5 @@
---
title: Stage 2 — Verification Subsystem
title: Stage 2
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24

2
projects/passepartout/architecture/stages/stage-3-lisp-machine.org
View File

@@ -1,5 +1,5 @@
---
title: Stage 3 — Lisp Machine
title: Stage 3
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24

2
projects/passepartout/architecture/stages/stage-4-inference.org
View File

@@ -1,5 +1,5 @@
---
title: Stage 4 — Inference (In-Process LLM)
title: Stage 4
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24

2
projects/passepartout/architecture/stages/stage-5-weights.org
View File

@@ -1,5 +1,5 @@
---
title: Stage 5 — Weights (Plist-Native)
title: Stage 5
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24

2
projects/passepartout/architecture/stages/stage-6-training.org
View File

@@ -1,5 +1,5 @@
---
title: Stage 6 — Training (Verified Fine-Tuning + World Model)
title: Stage 6
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24

2
projects/passepartout/architecture/stages/stage-7-remaining.org
View File

@@ -1,5 +1,5 @@
---
title: Stage 7 — What Remains
title: Stage 7
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24

2
projects/passepartout/architecture/systemic-effects.org
View File

@@ -2,7 +2,7 @@
:ID: b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba
:CREATED: [2026-05-23 Sat]
:END:
#+title: Passepartout — Systemic Effects Over Time
#+title: Passepartout
#+filetags: :passepartout:strategy:effects:geopolitics:society:
Passepartout is not a product in an existing category. Verified infrastructure is a new category, and every existing category — cloud, AI, OS, social, payments, compliance, governance — eventually migrates into it because the alternative becomes indefensible.

20
projects/passepartout/architecture/three-pronged/_index.org
View File

@@ -1,20 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 329bd4fb-702a-4a2b-9c63-69281aacb83a
:END:
#+title: Three-Pronged Architecture
#+filetags: :architecture:three-pronged:knowledge:verification:
The three-pronged model describes Passepartout's approach to knowledge and verification: deductive proofs (mathematical certainty), provenance-tracked empirical models (statistical validity), and probabilistic oracle (LLM-aided guidance), all governed by the gate. These notes trace the architectural implications across the system's subsystems and stages.
- [[id:f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f][Schafmeister and Clasp]] — Lisp in computational nanotechnology, existence proof for the architecture
- [[id:7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d][Open-source Wolfram Language in Lisp]] — viability of bootstrapping a Mathematica equivalent
- [[id:8b9c0d1e-2f3a-4b5c-6d7e-8f9a0b1c2d3e][Passepartout bootstrapping Mathematica]] — what the neurosymbolic engine could generate autonomously
- [[id:9c0d1e2f-3a4b-5c6d-7e8f-9a0b1c2d3e4f][Middle of the Knowledge Tree]] — the gap between logic and nanotechnology
- [[id:0d1e2f3a-4b5c-6d7e-8f9a-0b1c2d3e4f5a][The Middle Domain as World Models]] — mapping empirical science onto world model architecture
- [[id:1e2f3a4b-5c6d-7e8f-9a0b-1c2d3e4f5a6b][World Models — Plain Language]] — explanation without jargon
- [[id:2f3a4b5c-6d7e-8f9a-0b1c-2d3e4f5a6b7c][Practical Powers of the Three-Pronged System]] — 10 concrete capabilities
- [[id:3a4b5c6d-7e8f-9a0b-1c2d-3e4f5a6b7c8d][Architectural Integration]] — how the three prongs fit into Passepartout's subsystems and stages
- [[id:4b5c6d7e-8f9a-0b1c-2d3e-4f5a6b7c8d9e][Neurological Software in the Empirical Middle]] — neural networks in the provenance framework
- [[id:5c6d7e8f-9a0b-1c2d-3e4f-5a6b7c8d9e0f][Wider Implications]] — what the three-pronged system means for science, safety, regulation, and trust

106
projects/passepartout/architecture/three-pronged/architectural-integration-three-pronged.org
View File

@@ -1,106 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-25 Mon]
:ID: 3a4b5c6d-7e8f-9a0b-1c2d-3e4f5a6b7c8d
:END:
#+title: Architectural Integration of the Three-Pronged System
#+filetags: :ideas:passepartout:architecture:
An analysis of how the deductive / provenance-tracked empirical / probabilistic oracle model fits into Passepartout's architecture, at what stage it becomes operational, and what it means for the existing subsystems.
**The three prongs are not three engines.**
The initial framing (deductive + provenance + probabilistic) implies three parallel reasoning systems. It is more accurate to say: two reasoning engines and one data layer.
- **The symbolic engine** handles everything that can be formalized: deductive proofs, empirical equations, validity predicates, pipeline composition, uncertainty propagation. This is one engine — it reasons about symbols using rules that are either proven (ACL2) or well-defined (force field equations).
- **The probabilistic oracle** (LLM) handles everything that cannot be formalized: parameter selection, model choice, interpretation of results in natural language, failure diagnosis, creative hypothesis generation. It proposes; the symbolic engine checks.
- **The provenance store** is not an engine. It is a structured database that stores empirical parameter sets, validity envelopes, experimental benchmarks, and comparison histories. Neither engine reasons about it as a whole. The symbolic engine queries it for parameters and validity predicates. The LLM queries it for context and updates it with new data.
Two reasoning engines. One curated data layer. This is a cleaner architecture than three parallel systems.
**Where it lives in the existing subsystems.**
The current architecture has four subsystems: Environment, Knowledge, Verification, Social Protocol. The three-pronged model cross-cuts them:
| Subsystem | Deductive role | Empirical role | Oracle role |
|---|---|---|---|
| Environment | Hosts the symbolic engine, runs ACL2 | Hosts the provenance store | Runs the LLM |
| Knowledge | Stores formal theorems and proofs (symbolic index) | Stores empirical parameters and benchmarks (provenance store) | Neural index for semantic search |
| Verification | ACL2 proof checking, formal gate rules | Validity envelope checks, parameter provenance checks | Gate policy interpretation (LLM evaluates natural-language rules) |
| Social Protocol | Sharing verified proofs between instances | Sharing validation histories and benchmark results between instances | Sharing model selection strategies |
The verification subsystem (the gate) is the integration point. Every action that reaches the gate is checked against:
1. Security policy (is this action safe?)
2. Scientific validity (is this model valid in this context?)
3. Consistency (do the symbolic check and the oracle's assessment agree?)
These three checks run as separate gate vectors with the same architecture as every other gate check. No new mechanism needed — just new predicates with access to the provenance store.
**At what stage it becomes operational.**
The infrastructure is staged, not all-at-once:
- **Stage 0 (now)** — The probabilistic oracle exists (the LLM). The provenance store does not. The deductive engine partially exists through Hermes skills (symbolic gate rules as Python, not ACL2). The empirical layer is invisible — the LLM reasons about chemistry, biology, and engineering using training data alone, without systematic provenance.
- **Stage 1 (social protocol)** — The provenance store prototype can be introduced here as a side effect of signed messages and data exchange. When instances share a validated force field parameter, the message carries a signature and a source. The receiving instance stores it with provenance. This is a natural crawl before the full infrastructure.
- **Stage 2 (gate as software)** — The provenance store becomes operational infrastructure. The gate needs to check validity envelopes to do its job properly. This is the correct stage to introduce it because: (a) the gate is being built anyway, (b) validity checking is a gate predicate like any other, and (c) the provenance store is just a structured knowledge base — the Knowledge subsystem already has the machinery for storing and querying structured data. The symbolic index (formal facts) and the provenance store (empirical parameters) differ in what they store, not in how they store it.
- **Stage 3 (Lisp machine)** — The symbolic engine is native in one address space. ACL2 runs at hardware level. The provenance store becomes a native Lisp hash table with persistence. The empirical layer is fully integrated: the symbolic engine queries the provenance store directly, the gate checks validity predicates in the evaluation loop itself, and the LLM still proposes model selections but every proposal is verified against the provenance store before execution.
- **Stage 4+ (in-process inference)** — The LLM moves in-process. The three components (symbolic engine, provenance store, LLM oracle) share one address space. No IPC between them. The query cycle is: LLM proposes a model → symbolic engine checks it against the provenance store → if valid, execute → if invalid, return to LLM with diagnostic. This loop runs at native speed.
**The empirical middle is not a separate kind of reasoning.**
The deepest question in the set: does the middle empirical part have both neuro and symbolic aspects?
Yes, and the split is clean.
The equations that describe an empirical model — Hooke's law for bond stretching, the Lennard-Jones potential for van der Waals interactions, the Born equation for solvation — are formal symbolic expressions. They can be parsed, manipulated, differentiated, verified by ACL2, and composed into pipelines. This is symbolic engine territory.
The parameters in those equations — the spring constants, the well depths, the atomic radii — are derived from experimental data through optimization and fitting. They cannot be derived from the equations themselves. This is not reasoning; it is curation. The provenance store holds them with sources and confidence intervals.
The selection of which model to apply to a given problem requires judgment about the domain, the available data, and the intended use of the result. The LLM handles this: it knows that a protein-protein docking problem needs a different force field than a small-molecule conformational search.
The composition of models into a pipeline (compute this, pipe into that, plot the other) is a program. The symbolic engine runs the pipeline. The LLM may propose the pipeline structure, but the execution is deterministic.
The diagnosis of failure — "this prediction was wrong and here is why" — is the hardest part and requires the most integration. The symbolic engine detects the validity envelope violation and reports the specific parameter that caused it. The LLM interprets the failure in context: "the bond angle term for this functional group was parameterized against small molecules; your molecule has bulky substituents that change the preferred angle."
| Aspect of the empirical middle | Handled by | Why |
|---|---|---|
| The equations themselves | Symbolic engine | They are symbolic expressions — verifiable, differentiable, composable |
| The parameter values | Provenance store (data) | Fitted to data, not reasoned about |
| Model selection | LLM oracle | Requires contextual judgment |
| Pipeline composition | Symbolic engine (execute) + LLM (propose) | Execution is deterministic; design is creative |
| Validity envelope checking | Symbolic engine | A logical predicate over known state |
| Uncertainty propagation | Symbolic engine | A formula that composes component uncertainties |
| Interpretation of results | LLM oracle | Requires natural language |
| Failure diagnosis | Both: symbolic engine pinpoints the violation, LLM explains why | The factual cause is formal; the narrative cause is contextual |
| Creative design (new molecules, new experiments) | LLM oracle | Requires open-ended generation |
The empirical middle does not require a new kind of reasoning engine. It requires the two existing engines (symbolic and probabilistic) to cooperate on data (the provenance store) that is neither formal theorem nor raw text — it is curated empirical knowledge with structure, provenance, and uncertainty.
**Does it require "world models"?**
The word "world model" is not necessary for the architecture. What the architecture requires is:
1. A store of mathematical models (equations + parameters) with provenance
2. A mechanism for checking validity envelopes (predicates over conditions)
3. A mechanism for composing models into pipelines (the existing program execution)
4. A mechanism for propagating uncertainty (formulas + tracked parameters)
The provenance store, the validity predicates, the pipeline executor, and the uncertainty tracker do not need to be called "world model infrastructure." They are features of the existing subsystems:
- The provenance store extends the Knowledge subsystem (it is a structured database, not a new category).
- The validity predicates are gate rules (they check conditions before allowing computation).
- The pipeline executor is the existing neurosymbolic loop (LLM proposes, symbolic engine executes).
- The uncertainty tracker is a mathematical library (error propagation formulas, statistical calculations).
Calling them "world models" is conceptually clarifying but architecturally optional. The infrastructure is the same either way.
**The practical implementation takeaway.**
Stage 2 is the correct entry point. The provenance store is built as a structured data extension to the Knowledge subsystem. Validity predicates are added as gate vectors. No new subsystems are needed — just new data types in the knowledge store, new predicates in the gate, and new functions in the symbolic engine for uncertainty propagation.
The three-pronged model describes what the system does, not what it is built from. The system is still one machine, one address space, one gate, one memex. It just has a more sophisticated understanding of what it knows and how it knows it.

86
projects/passepartout/architecture/three-pronged/knowledge-tree-middle.org
View File

@@ -1,86 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 9c0d1e2f-3a4b-5c6d-7e8f-9a0b1c2d3e4f
:END:
#+title: The Middle of the Knowledge Tree — From Logic to Nanotechnology
#+filetags: :ideas:knowledge:passepartout:
In the tree of knowledge model, mathematical foundations and formal logic sit at the root. Schafmeister's molecular nanotechnology sits at a high branch — programmable molecules that bind proteins and catalyze reactions. The distance between them is bridged by a chain of formal and empirical domains. This note maps that chain.
**The full stack, root to branch.**
| Layer | What it formalizes | Formal status | Verification model |
|---|---|---|---|
| 0. Logic / Foundations | Proof theory, set theory, type theory, ACL2 axioms | Deductive | Complete — provable from axioms |
| 1. Algebra | Groups, rings, fields, vector spaces, modules | Deductive | Complete |
| 2. Analysis | Real numbers, limits, continuity, calculus, measure theory | Deductive | Complete (in principle; deep results are hard) |
| 3. Geometry / Topology | Manifolds, differential forms, curvature, homotopy | Deductive | Complete |
| 4. Classical Mechanics | Lagrangian/Hamiltonian mechanics, Newtonian dynamics | Deductive | Complete — follows from variational principles |
| 5. Quantum Mechanics | Hilbert spaces, operators, Schrödinger equation, symmetries | Deductive | Complete (the theory is fully formalizable) |
| 6. Statistical Mechanics | Ensembles, partition functions, Boltzmann distribution, entropy | Deductive | Complete (follows from QM + probability) |
| 7. Electrodynamics | Maxwell's equations, potentials, radiation | Deductive | Complete |
| 8. Quantum Chemistry | Born-Oppenheimer, Hartree-Fock, DFT, coupled cluster | Partially deductive | The equations are formal. The necessary approximations (Börn-Oppenheimer, exchange-correlation functional) are not. |
| 9. Molecular Mechanics | Force fields (AMBER, CHARMM, OPLS), potential functions, non-bonded interactions | Empirical parameterization | The simulation is deterministic. The parameters are fitted to experiment. |
| 10. Molecular Dynamics | Integration schemes, thermostats, barostats, periodic boundaries | Deductive mechanics + empirical inputs | The integrator is provable. The force field parameters are not. |
| 11. Chemical Thermodynamics | Binding constants, free energy surfaces, reaction equilibria, solvation | Mixed deductive/empirical | Statistical mechanics is deductive. Solvation models are not. |
| 12. Structural Biochemistry | Protein folding, protein-ligand binding, docking, enzyme kinetics | Largely empirical | Binding affinity prediction is not deductively solvable from first principles. |
| 13. Organic Chemistry | Reaction mechanisms, stereochemistry, functional group transformations | Empirical with formal structure | Reaction mechanisms are modeled, not derived. They are falsifiable hypotheses, not theorems. |
| 14. Molecular Design | Spiroligomer design, shape-programmable molecules, therapeutic targeting | Empirical design space | Design rules are heuristics validated by experiment, not derived from QM. |
**What changes at layer 8.**
The important transition happens between layers 7 and 8. Everything from logic through quantum mechanics and statistical mechanics is fully formalizable — you can write down the equations, derive the consequences, and verify the derivations. This is the domain where ACL2 can prove correctness against first principles.
Layer 8 (quantum chemistry) is where the first irreducible approximation appears. The Born-Oppenheimer approximation is not a theorem — it is an assumption that nuclei and electrons can be treated separately because nuclei are much heavier. This assumption is empirically excellent but not deductively guaranteed. The exchange-correlation functional in DFT is not derivable — it is a functional whose exact form is unknown and must be approximated.
From layer 9 onward, the models are empirical through and through. Force field parameters are fitted to experimental data. Solvation models are calibrated against known solubilities. Binding affinity predictions are validated by binding assays, not derived from Schrödinger's equation. The models are mathematically rigorous (the simulation correctly integrates Newton's equations), but the inputs to those models are not.
**What this means for Passepartout.**
Passepartout can verify the *computation* at every layer. It can prove that:
- The Schrödinger equation is correctly solved for a given Hamiltonian (layer 5/8).
- The molecular dynamics integrator preserves phase space volume (layer 10).
- The docking algorithm correctly explores the defined conformational space (layer 12).
But it cannot verify that the *model* matches reality. The Born-Oppenheimer approximation, the DFT functional, the force field parameters, the solvation model, the scoring function — these are commitments to empirical reality that no verification system can discharge. They are validated by experiment, not by proof.
This is the same structure as Stage 7 in Passepartout's own roadmap: after all computational threats are eliminated, oracular limits and physical reality remain. The verification subsystem can certify that a simulation is internally consistent. It cannot certify that the simulation's assumptions hold in the real world.
**What Passepartout would need in the middle.**
For each layer 1-7 (deductive), Passepartout already has or can generate the formal mathematics. These are theorems and algorithms that ACL2 can verify against axioms.
For each layer 8-14 (empirically parameterized), Passepartout needs:
1. **A formal model** of the equations (the DFT equations, the force field functional form, the MD integrator) — verified against the mathematical theory.
2. **A parameter database** with provenance (force field parameters, basis sets, solvation parameters, scoring function weights) — not proven but curated, versioned, and traceable to experimental sources.
3. **An empirical validation pipeline** that compares computed predictions against experimental measurements and updates the parameter confidence.
The parameter database with provenance is the crucial addition. For Schafmeister's work, this means:
| Empirical parameter set | Source | Passepartout role |
|---|---|---|
| DFT functional parameters | Fitted to known systems | Trace which functional was used for each calculation |
| Force field parameters (AMBER, CHARMM) | Fitted to QM + experiment | Trace parameter provenance; flag known failure regimes |
| Solvation free energies | Calibrated to measured solubilities | Track calibration data and confidence intervals |
| Binding affinity benchmarks | PDBbind, DUD-E, experimental IC50 | Track benchmark provenance; report uncertainty |
| Spiroligomer design rules | Schafmeister's own experimental data | Formalize as knowledge graph with experimental backing |
**The nature of the bridge.**
The middle of the knowledge tree is not a chain of theorems. It is a lattice of formal models scaffolded by empirical commitments. Each layer relies on the formal correctness of the layer below (the QM solver is correct), but also on approximations and parameters that are not deductively justified.
This is not a weakness of the architecture. It is a correct description of the relationship between mathematics and experiment. The bridge from logic to nanotechnology is built from:
- **Formal mathematics** for what can be proven (the core theories, the algorithms, the simulation correctness)
- **Models with provenance** for what cannot be proven but works (the approximations, the force fields, the scoring functions)
- **Empirical validation** for the claim that the models match reality (experimental data, benchmarks, error bars)
Passepartout's contribution is not to eliminate the empirical layers — that is impossible. Its contribution is to make explicit which parts are deductively verified, which are empirically fitted, and what the provenance trail is for every numerical value that enters a computation. The system cannot make chemistry deductive. It can make every computational output traceable to its assumptions.
---
- [[id:f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f][Schafmeister and Clasp]] — the nanotechnology branch
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — where verification lives
- [[id:9c0d1e2f-3a4b-5c6d-7e8f-9a0b1c2d3e4f][Stage 7 — What Remains]] — oracular, physical, and empirical limits

74
projects/passepartout/architecture/three-pronged/open-source-wolfram-lisp.org
View File

@@ -1,74 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
:END:
#+title: Viability of an Open-Source Wolfram Language / Mathematica in Common Lisp
#+filetags: :ideas:lisp:mathematics:open-source:
An assessment of what it would take to build a viable open-source equivalent of Wolfram Language and Mathematica in Common Lisp, based on the existing ecosystem and the fundamental architectural alignment between Lisp and symbolic computation.
**The alignment is natural, not forced.**
Wolfram Language is, at its core, a term-rewriting system with pattern matching, rule-based transformation, and a uniform symbolic representation for everything (expressions are trees of the form head[arg1, arg2, ...] — the Wolfram equivalent of cons cells). This is very close to what Lisp is natively. A Lisp implementation of the core evaluator — pattern matching, rule application, substitution, term rewriting — is not a foreign port. It is an exercise in expressing Wolfram's semantics in a language whose semantics were designed for the same problem domain.
Maxima proves this historically. It is a direct descendant of Macsyma, the MIT computer algebra system that inspired Mathematica. Macsyma was written in Lisp. Mathematica's core evaluation model inherits heavily from Macsyma. An open-source Common Lisp computer algebra system already exists, has existed for decades, and works. The question is not whether it can be done, but how much of the modern Mathematica ecosystem can be replicated and at what cost.
**What already exists.**
| Layer | Existing CL work | Status |
|---|---|---|
| Symbolic engine / term rewriting | Lisp readers, pattern matching libs (trivia, optima, fare-matcher), rule systems | Foundational primitives exist, no unified Wolfram-equivalent evaluator |
| Computer algebra system | Maxima, FriCAS (Axiom), reduce-algebra | Mature CASes — Maxima alone has differentiation, integration, ODEs, linear algebra, tensors, series, limits, Laplace transforms |
| Numerical computing | magicl, lla (Lisp Linear Algebra), CL-NUM, GSLL (GNU Scientific Library bindings) | Solid — covers BLAS, LAPACK, random numbers, special functions, optimization |
| Visualization | cl-cairo2, Vecto, CLG, CommonQt, cl-zxing | Exists but scattered — no unified plotting framework like Mathematica's |
| Notebook interface | cl-jupyter, common-lisp-jupyter, Lem | Jupyter kernel works. Lem is a native editor approaching notebook capability. No Mathematica-level notebook yet. |
| Rule-based programming | fare-matcher, optima, prolog implementations | Pattern matching is good. Full term-rewriting system needs assembly. |
| Knowledge graph | gbrain, various triplestore libs | Possible but would need Wolfram Alpha-level investment |
| Deployment | ASDF, Quicklisp, SBCL standalone executables | Better than Mathematica's deployment story — Lisp produces real executables |
**The hard parts.**
1. **The standard library is the product, not the engine.** Mathematica ships thousands of built-in functions — every mathematical special function, every statistical distribution, every graph algorithm, every image processing filter, every string operation, every data format parser. This is not a technical challenge; it is a sheer volume problem. The open-source answer is to wrap existing C/C++ libraries (GSL for special functions, OpenCV for image processing, igraph for graph algorithms, etc.) and expose them through a unified symbolic interface. This is the Clasp approach: interop with mature C++ libraries rather than rebuilding everything from scratch in Lisp. The Wolfram equivalent would be a CLOS-based symbolic dispatch layer that wraps these libraries and makes them accessible through a consistent term-rewriting evaluator.
2. **The notebook interface is a product in itself.** Mathematica's notebook is not a terminal with nice formatting. It is a computational notebook with inline typeset math, dynamic graphics, collapsible sections, live evaluation, and a rich document model. The Jupyter ecosystem solves half of this. A Lisp-native notebook would need a rendering engine for mathematical notation (LaTeX or MathJax integration), inline interactive graphics, and a document model compatible with literate computation. Lem is the most promising starting point — it already has Emacs-like extensibility, a GTK frontend, and a Lisp-native codebase. Extending Lem to support computational notebooks with inline graphics and typeset output is the shortest path.
3. **Performance for specialized domains.** Mathematica's kernel is highly optimized for symbolic operations — pattern matching over large expressions, automatic algorithm selection, memoization, and incremental compilation. A naive Lisp implementation would match Mathematica for small-to-medium expressions but would need significant optimization work for the heavy cases (symbolic integration of large expressions, graph operations on million-node graphs, image processing pipelines). The advantage is that Lisp's compiler infrastructure (SBCL's type inference, VOPs, inlining) gives a much better baseline than most languages. SBCL can generate code that approaches C speed for numerical kernels.
4. **The knowledge graph (Wolfram Alpha).** Mathematica's integration with Wolfram Alpha — querying computable data about chemistry, geography, finance, linguistics, etc. — is a separate product with a massive engineering investment in data curation. An open-source equivalent would not replicate this. It would either provide a local, user-curatable knowledge base (gbrain fits here) or integrate with existing open knowledge graphs (Wikidata, DBpedia). The gbrain connection is interesting: if Passepartout's knowledge store can answer factual queries with provenance, that becomes the Wolfram Alpha equivalent for the Lisp Mathematica.
5. **Package ecosystem and community.** Mathematica's advantage is not just its engine but its ecosystem — thousands of paclets, the Wolfram Function Repository, the community that shares notebooks. An open-source equivalent needs a package manager (Quicklisp solves this for Lisp libraries), a repository for symbolic packages (a Wolfram Function Repository equivalent), and a critical mass of users who both use and contribute. Maxima has users but not contributors. The gap is community formation, not technical capability.
**The viability assessment.**
| Domain | Viability | Timeline estimate | Risk |
|---|---|---|---|
| Core symbolic evaluator | High — Lisp was designed for this | 6-12 months for working prototype | Low — well-understood problem |
| Computer algebra | High — Maxima already exists | Integrate now; polish 1-2 years | Low — needs UI/UX investment |
| Numerical computing | High — wrappers exist | 3-6 months for unified interface | Low — wrapping problem |
| Visualization | Medium — scattered pieces | 1-2 years for unified framework | Medium — needs new work |
| Notebook interface | Medium — Lem as foundation | 1-2 years to Mathematica parity | Medium — significant UX engineering |
| Standard library breadth | Low — volume problem | 3-5 years with community | High — needs sustained contribution |
| Knowledge graph | Low — curation cost | 2-3 years for basic integration | High — different product category |
| Deployment | High — Lisp executables | Works now | None |
**The strategic question.**
The real question is not "can we replicate Mathematica in Lisp" but "should we?" — and if so, for whom.
Mathematica serves two distinct use cases:
- **Interactive exploration** — a researcher types an integral, gets a result, visualizes it, iterates. Lisp + Maxima + a good notebook interface already does this, and the experience is competitive for anyone comfortable with Lisp syntax.
- **Deployed computation** — a company builds a production pipeline around Mathematica kernels, deploying computation as a service. Lisp executables are dramatically better here — they are real compiled binaries, not managed by a proprietary kernel, deployable without license fees, embeddable anywhere.
For the second use case, the open-source Lisp alternative is already superior. The gap is the first use case: the interactive exploration experience, the breadth of built-in functions, and the cultural acceptance of Lisp syntax in communities that currently write Wolfram Language.
The most viable path is not to clone Mathematica but to integrate Maxima + numerical Lisp libraries under a unified symbolic interface, expose all of it through a Lem-based notebook, and make the Jupyter bridge the primary entry point for users who prefer Python notebooks. This gives you 80% of Mathematica's capability with a fraction of the development cost, and it connects to the existing scientific Python ecosystem rather than competing with it.
**The deeper point.**
Mathematica's architecture is Lisp-like because it was inspired by a Lisp system (Macsyma). An open-source Mathematica in Lisp is not a port. It is a return to the original architectural vision, implemented in the language that vision was originally expressed in. The question is whether the community investment materializes — and that depends on whether there is a use case that justifies it. Passepartout's verification infrastructure may be that use case: a verified symbolic computation engine that reasons about its own results is a Mathematica-like system by necessity, and building it in Lisp is the natural path.
---
- [[id:f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f][Schafmeister and Clasp]] — Lisp in computational nanotechnology, existence proof for Lisp viability in scientific computing
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — why Lisp and where the symbolic engine fits

92
projects/passepartout/architecture/three-pronged/passepartout-bootstrap-mathematica.org
View File

@@ -1,92 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 8b9c0d1e-2f3a-4b5c-6d7e-8f9a0b1c2d3e
:END:
#+title: Could Passepartout Bootstrap Mathematica or mathlib by Itself?
#+filetags: :ideas:lisp:passepartout:mathematics:
This extends the previous viability analysis with a specific scenario: assuming Passepartout exists at Stage 3+ (full Lisp machine with neurosymbolic engine, verification gate, and self-modification capability), how hard would it be for it to recreate Mathematica or mathlib in pure Common Lisp on its own?
**The bootstrap is architectural, not aspirational.**
The neurosymbolic engine is not just a faster way to write code. It is a closed loop: the LLM proposes implementations, the symbolic engine and ACL2 prover verify correctness, and the self-modification system hot-reloads the result into the running image. This loop runs autonomously, without human intervention. The system writes code, tests it formally, improves it, and keeps the result — permanently expanding its own capability.
This is fundamentally different from a human writing Mathematica. A human writes code, compiles, tests, debugs. Passepartout writes code, has it verified against a formal specification, and loads it into its own runtime. The iteration speed is not hours or days — it is seconds per function, limited only by the LLM's generation latency and the prover's checking time.
**What Passepartout already has.**
At Stage 3, the system ships with:
- A symbolic term-rewriting engine (the evaluator itself is one)
- Pattern matching and rule-based transformation (native to the gate architecture)
- ACL2 as a verification backend (can prove properties of generated code)
- An LLM oracle for proposing implementations (the probabilistic brain)
- A self-modification system (hot-reloads verified code into the running image)
- A knowledge store with persistent facts (gbrain-derived)
These are not general-purpose tools that happen to be useful for symbolic mathematics. They are the same tools that a computer algebra system needs, expressed in the same architecture. The evaluator that rewrites a gate policy is the same mechanism that rewrites a symbolic expression.
**What it needs to generate.**
| Component | Can Passepartout generate it? | How |
|---|---|---|
| Core symbolic evaluator | Yes, trivially — this is what Lisp *is* | The existing evaluator already does term rewriting. The neurosymbolic engine would create a higher-level pattern-matching layer over it. |
| Computer algebra (differentiation, integration, simplification) | Yes — known algorithms, formally specifiable | LLM proposes implementation of Risch algorithm, polynomial GCD, Gröbner bases. ACL2 verifies the specification. |
| Numerical libraries (BLAS, special functions, optimization) | Partial — better to wrap | ACL2 cannot verify floating-point numerics to the same standard. Passepartout would wrap existing C/C++ libraries via Clasp-style interop and verify the interface, not the numerics. |
| Visualization framework | Yes — UI code, not math | The environment subsystem (Nyxt/Lish) already has rendering primitives. The neurosymbolic engine generates plotting and graphics code against them. |
| The 5,000+ function standard library | Yes — volume, not novelty | This is the dominant cost. Each function is individually trivial (differentiate x^3 → 3x^2) but there are thousands. Passepartout generates them at LLM speed — roughly one function every 10-30 seconds including verification. |
| Formal proofs of mathematical theorems (mathlib) | Qualified yes — different logic | mathlib is in Lean's dependent type theory. Passepartout's ACL2 is first-order logic. The theorems can be re-proven in ACL2, but the proofs are not portable. The LLM proposes proof strategies, ACL2 checks them. |
**The rate limit is generation, not computation.**
If Passepartout generates one verified function every 20 seconds (conservative — LLM proposal time + ACL2 verification), that is 180 functions per hour, ~4,300 per day. Mathematica's standard library contains roughly 6,000 documented functions. At this rate, the standard library would take ~1.5 days of continuous generation — assuming the LLM has the domain knowledge to produce correct implementations and ACL2 can verify them.
This is the critical assumption. The LLM (at, say, GPT-4 or DeepSeek level) already knows what every Mathematica function does. It has seen them in training data. The question is whether it can generate a correct Lisp implementation with a formal specification that ACL2 can verify. For most elementary functions (differentiate, integrate polynomial, singular value decomposition, string split, image histogram), the answer is yes — these are well-understood algorithms with clear specifications.
For specialized domains (elliptic curve cryptography, tensor network contractions, symbolic regression of differential equations), the LLM may generate approximately correct implementations that need refinement. The neurosymbolic loop handles this: ACL2 catches the mismatch, feeds the error back, and the LLM regenerates.
**mathlib is a different problem.**
mathlib is not a library of algorithms but a library of formal proofs — mathematical theorems expressed in Lean's dependent type theory, structured as a hierarchy of definitions, lemmas, and tactics. It represents hundreds of person-years of community effort, formalizing undergraduate mathematics and beyond.
Passepartout's verification layer is ACL2, which operates in a different logical framework (first-order logic with induction for total functions, not dependent types). There is no porting mathlib — it would have to be re-proven in ACL2's logic.
The advantage is that the theorems are already known. mathlib tells you exactly what to prove. The LLM reads the Lean statement, translates it to an ACL2 theorem, proposes a proof strategy, and ACL2 attempts the proof. This is a well-structured task for the neurosymbolic loop: the LLM generates proof plans, ACL2 verifies them, and failed attempts feed back to refine the next plan.
The bootstrapping advantage: early proofs (basic arithmetic, set theory) strengthen the ACL2 reasoning library, which makes later proofs (real analysis, topology) faster. The system accelerates as it goes. mathlib's proof dependency graph is the natural generation order.
Estimated timeline for mathlib-equivalent in ACL2, with Passepartout generating autonomously:
| Milestone | Time estimate | Note |
|---|---|---|
| Basic arithmetic, algebra, number theory | Days — standard library material | Well-known proofs, simple structure |
| Real analysis, measure theory | Weeks — proof complexity increases | Non-trivial but well-studied |
| Abstract algebra (groups, rings, fields) | Weeks — structural, builds on itself | The neurosymbolic loop excels here |
| Topology, algebraic topology | Months — conceptual depth | Proofs are longer, more strategic |
| Category theory, homological algebra | Months — abstraction barrier | High-level abstraction, fewer verification primitives |
| Number theory deep results (FLT, modular forms) | Unknown — research frontier | Passepartout is not proving open problems. It formalizes known results. |
**The bootstrapping compound effect.**
The most interesting property is not that Passepartout can generate Mathematica's library. It is that each generated function becomes part of Passepartout's own capability. After generating the differentiation function, Passepartout uses it to generate the integration function. After generating linear algebra, it uses that to generate optimization algorithms. After generating formal proofs of real analysis, it uses those theorems to verify more complex deductions.
This is not a production pipeline. It is an autodidactic loop: the system generates math, then uses that math to generate more math. The acceleration is exponential in the early phases and linear in the later phases, limited by the rate at which the LLM can produce new correct specifications.
**The real barrier is not technical but oracular.**
At every step, Passepartout depends on the LLM's knowledge of existing mathematics. The LLM has seen most of human mathematical knowledge in its training data. It can propose correct implementations and proof strategies because it has seen them. But for genuinely new mathematics — theorems not present in the training data, algorithms that have not been discovered — the LLM has no signal. Passepartout would be limited by its oracle.
Stage 7 acknowledges this: oracular limits are fundamental. The verification subsystem can check correctness against a specification, but it cannot generate the specification itself. The LLM provides the what; ACL2 verifies the that. Neither provides the why that extends beyond existing knowledge.
**Conclusion.**
Recreating Mathematica's standard library: **days to weeks** of autonomous generation. The volume problem is solvable because the LLM already knows the answer space and ACL2 can verify each function. No human intervention required.
Recreating mathlib's formal proof corpus: **months** of continuous formalization. The neurosymbolic loop maps naturally onto the task of converting known theorems from one logical framework to another. The dependency graph of mathlib provides the optimal generation order.
Neither requires new research. Both are engineering throughput problems that Passepartout's architecture is designed to solve: generate, verify, reload, repeat. The only hard limit is the oracle — the system cannot generate mathematics that the LLM does not already know exists.
---
- [[id:7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d][Viability of open-source Wolfram/Mathematica in Lisp]] — the human-driven assessment
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — the verification and self-modification systems

88
projects/passepartout/architecture/three-pronged/practical-powers-three-pronged.org
View File

@@ -1,88 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 2f3a4b5c-6d7e-8f9a-0b1c-2d3e4f5a6b7c
:END:
#+title: Practical Powers of the Three-Pronged System
#+filetags: :ideas:passepartout:architecture:
What can Passepartout do with its three layers — deductive proofs, provenance-tracked empirical models, and probabilistic oracle — that a conventional system cannot? This note catalogs the practical powers that fall out of the architecture, not as abstract potential but as concrete capabilities.
**1. It can tell you how wrong every result might be.**
This is the single most important power. Computational science today produces precise-looking numbers with no error bars. A molecular dynamics simulation outputs "binding free energy: −9.2 kcal/mol" and the number looks definitive. It is not. It depends on a chain of models (force field, solvation, sampling, scoring) each with its own uncertainty.
Passepartout traces the chain automatically. It reports: "binding free energy: −9.2 kcal/mol ± 1.4 kcal/mol. Breakdown: force field uncertainty ±0.8 kcal/mol, solvation model ±0.5 kcal/mol, conformational sampling ±0.3 kcal/mol, scoring function ±0.6 kcal/mol. Model validity regime: proteins in water at 298K ± 25K. Your conditions fall within this regime."
No computational chemistry package does this today. Every one outputs a precise number and leaves the uncertainty to the scientist's judgment.
**2. It can prevent you from using a model outside its valid range.**
A force field parameterized for soluble proteins at room temperature gives plausible-looking numbers for a membrane protein at body temperature, but those numbers are not physically meaningful. The simulation runs, produces output, and a human who does not know the force field's history may trust the result.
Passepartout's gate catches this at the check level: "This force field was validated for aqueous solutions of soluble proteins at 273-373K. Your simulation involves a lipid bilayer environment at 310K. Three of the lipid-specific parameters are outside their validated range. Recommendation: use a membrane-specific force field (CHARMM36m) instead. Confidence reduction: 40% if you proceed with current selection."
This is a fundamentally new kind of safety. Not "is this action malicious?" but "is this computation sound?"
**3. It can detect when a model is getting worse.**
Empirical models degrade over time. A force field fitted to 1990s experimental data may be worse than a later version fitted to more data, but there is no automatic mechanism to detect this. A scientist who has been using the same force field for a decade may not realize it has been superseded.
Passepartout tracks every model version. When it processes a new publication with updated parameters, it can compare: "The AMBER ff99 parameters you are using were superseded by ff14SB in 2014 and ff19SB in 2019. The newer parameter sets improve backbone dihedral prediction by 30% for the protein class you are simulating. Migrate to ff19SB?" It does this because every parameter has a timestamp, a source, and a validation record.
**4. It can compare predictions to experiments automatically.**
Every time Passepartout makes a computational prediction and receives (or the user provides) an experimental measurement for the same system, it records the comparison. Over hundreds of comparisons, it builds a systematic bias profile for each model: "This force field consistently underestimates binding affinity for charged ligands by 0.5-1.0 kcal/mol. This solvation model overestimates solubility for aromatic compounds."
These bias profiles are not research papers. They are accumulated operational knowledge that makes future predictions more interpretable. No existing system does this because no existing system treats models as entities with provenance rather than as files on disk.
**5. It can red-team its own reasoning.**
The probabilistic oracle (LLM) proposes a conclusion. The deductive layer (ACL2) checks the formal steps. The provenance layer (empirical knowledge base) checks whether the models used are valid for the context. If all three agree, the conclusion is as reliable as the system can make it. If they disagree, the conflict itself is informative: "The formal mathematics checks out, but the models supporting it are outside their validated range. Your conclusion may be mathematically correct but physically unsupported."
This is a kind of epistemic hygiene that no single-layer system can achieve. A purely probabilistic system (LLM alone) can be confidently wrong. A purely deductive system (prover alone) can only reason within its formal domain. A purely empirical system (database alone) cannot synthesize across domains. The three layers cross-check each other.
**6. It can build a community knowledge graph of what works.**
When multiple Passepartout instances use the same model in different conditions and compare to experimental data, the combined record extends the model's validity envelope. One instance validates a force field for ethanol. Another validates it for DMSO. A third validates it for mixed solvents. The model's validity envelope grows across the network without any single instance having to run all the experiments.
The social protocol becomes the mechanism for this sharing: instances publish validation results as signed, provenance-tracked claims. The network aggregates them. A model that starts with a narrow validity envelope (water, 298K) gradually accumulates enough validation data to cover a wide range of conditions.
No existing scientific software network does this. Journals publish individual validation studies; nobody aggregates them into a living validity map for each model.
**7. It can generate a defensible record for regulatory submission.**
If a pharmaceutical company uses Passepartout in a drug discovery pipeline, every simulation result carries a full provenance chain: force field version and source, solvation model parameters and validation benchmark, conformational sampling algorithm and integrator settings, gate checks that passed, uncertainty budget per component.
This record is essentially a compliance document. It answers the question "how do I know this result is reliable?" with a traceable chain of evidence, not a scientist's assertion. For industries regulated by the FDA, EMA, or similar bodies, this is the difference between a simulation being used for guidance and a simulation being accepted as evidence.
**8. It can be wrong honestly.**
This sounds trivial but it is the hardest thing for software to do. Every scientific software package presents its outputs with equal authority. A result from a high-quality QM calculation and a rough empirical estimate look the same in the output file — just numbers.
Passepartout would output: "This result is deductively proven (ACL2-verified, level 0-7)." or "This result is computationally rigorous within an empirical model (provenance-tracked, level 8-14, validity envelope intact)." or "This result is an extrapolation outside the model's validated range. Confidence is low. Here is what would need to be measured to increase confidence."
Honesty about uncertainty is a power because it changes what you can do with the result. A deductively proven result can be used as a building block for further proofs. An empirical result within its validity envelope can be used for design decisions with known risk. An extrapolation should only be used for hypothesis generation. Passepartout would know which is which and tell you.
**9. It can refuse an unsound instruction.**
Today, if you ask a computational chemistry package to run a simulation, it runs the simulation. It does not check whether the settings are physically meaningful. The error is not caught until a human reviews the output — if they ever do.
Passepartout's gate can say: "I will not run this simulation. The requested temperature (500K) exceeds the force field's validated range (273-373K). The solvent (hexane) has no validated parameters in this force field version. The simulation will produce numerically precise but physically meaningless results. If you want to proceed, I will flag all output as extrapolation with a confidence score of 0.3 out of 1.0."
The power is not that Passepartout prevents the simulation. It is that Passepartout makes the choice explicit: the human can override, but the override is recorded, and the result is tagged with its true reliability rather than appearing to be definitive.
**10. It can connect mathematics to reality without faking it.**
This is the deepest power. A conventional system either stays in the pure formal domain (proof assistants, CAS) or stays in the empirical domain (simulation software, ML). Passepartout bridges them by making the boundary explicit.
A mathematician can prove a theorem (layers 0-3). An engineer can build a bridge using empirical models (layers 8-12). Passepartout can connect the two: "The finite element equations for this bridge are verified against classical mechanics (layer 4). The material parameters come from ASTM standard tests on this specific steel alloy (layer 8-9, validity envelope: −20°C to 60°C, validated by 200+ measurements). The load calculations carry ±3% uncertainty based on material parameter variance." The bridge is not proven safe — no software can prove a physical structure is safe — but the chain from mathematical foundation to empirical measurement is fully transparent.
**Summary: three kinds of power.**
| Layer | What it verifies | What it enables |
|---|---|---|
| Deductive proofs | Correctness against axioms | Autonomous generation of verified algorithms |
| Provenance-tracked models | Implementation fidelity + data source | Scientific integrity, uncertainty budgets, audit trails |
| Probabilistic oracle | N/A (generates hypotheses) | Synthesis, model selection, natural language interface |
Alone, each layer is a tool. Together, they form a system that can reason formally, model empirically, communicate naturally — and tell you which mode is in effect for every result it produces.

48
projects/passepartout/architecture/three-pronged/schafmeister-clasp-nanotechnology.org
View File

@@ -1,48 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f
:END:
#+title: Christian Schafmeister — Common Lisp in Computational Nanotechnology
#+filetags: :ideas:lisp:nanotechnology:
Christian Schafmeister is a chemistry professor at Temple University in Philadelphia. He created [[https://github.com/clasp-developers/clasp][Clasp]], a Common Lisp implementation that interoperates with C++ libraries using LLVM compilation, specifically to solve a problem most Lisp implementers never face: designing molecules at the nanoscale.
**The problem.**
Schafmeister's research focuses on spiroligomers — large, shape-programmable molecules built from synthetic monomers. These are programmable at the level of both shape and functional groups, meaning they can be designed to bind specific proteins as therapeutics or accelerate chemical reactions the way enzymes do. The goal is to create molecules that can do everything proteins do in nature, but that are designable and evolvable by human beings.
This is a computational problem of enormous complexity. Designing these molecules requires simulating their behavior, computing binding affinities, searching conformational space, and iterating designs rapidly based on experimental feedback. The compute pipelines involved typically live in the C++ ecosystem (a vast array of scientific computing libraries), but the workflow itself — rapid prototyping, interactive exploration, incremental development — demands the kind of environment that C++ alone cannot provide.
**Why Lisp won.**
Schafmeister's argument for Common Lisp in computational nanotechnology mirrors the same reasoning that drives Passepartout's architecture:
- **Interactivity.** Molecular design requires exploration. A researcher needs to load data, inspect it, try a transformation, undo it, try another — all within a live environment. Lisp's REPL-driven development provides this in a way that compile-link-run cycles cannot match.
- **Incremental development.** The design space for spiroligomers is too large to simulate exhaustively. You need to build up models piece by piece, testing each step. Lisp's incremental compilation and hot-reloading make this natural.
- **Unified representation.** In Lisp, the code that describes a molecule and the code that simulates it share the same structure. There is no translation barrier between the design language and the simulation language.
But the scientific computing ecosystem lives in C++. Schafmeister could not afford to rebuild every computational chemistry library from scratch. So he built Clasp: a Common Lisp implementation that compiles to native code via LLVM and interoperates seamlessly with C++. Clasp can call any C++ library natively, and C++ can call back into Lisp. The result is that the entire scientific computing ecosystem becomes available from within a Lisp environment — programmable, interactive, introspectable.
**The architecture.**
Clasp is not a wrapper or a bridge. It is a full Common Lisp implementation where the C++ interoperation is part of the language runtime itself. The clbind library provides declarative bindings — you describe how C++ classes and functions map to Lisp, and Clasp generates the glue code automatically. This is fundamentally different from CFFI-style foreign function interfaces, which require manual marshaling and are inherently fragile.
From the Lisp perspective, a C++ class appears as a CLOS class. You can subclass it, specialize methods on it, inspect its instances. The boundary between Lisp and C++ is transparent to the programmer.
**Funding and validation.**
Clasp has been funded by the Defense Threat Reduction Agency (DTRA), the National Institutes of Health (NIGMS), and the National Science Foundation. These are agencies that fund computational chemistry and materials design, not programming language research. They funded Clasp because it solved a real problem in molecular design that no other approach addressed: making C++-scale scientific computing work within an interactive Lisp environment.
**Relevance to Passepartout.**
Schafmeister's work is existence proof for two of Passepartout's core claims:
1. Lisp is not a niche language for academic AI research or Emacs configuration. It is being used today to design therapeutic molecules that bind proteins, in environments funded by the NIH and NSF. The interactivity and homoiconicity that Passepartout relies on are the same properties that make this work possible.
2. The single-address-space model is not a limitation but an enabling constraint. Clasp proves that you can run C++ libraries inside a Lisp image, not alongside it. The "Lisp machine" is not a retro fantasy — it is a practical architecture being used today for computationally demanding scientific work.
The main difference is direction: Schafmeister brought C++ into Lisp to access the scientific computing ecosystem. Passepartout replaces the C++ scientific computing ecosystem with verified Lisp-native alternatives. The architectural principle — one representation, one address space, no translation boundaries — is the same in both cases.
---
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — why Lisp is the choice for verified infrastructure

82
projects/passepartout/architecture/three-pronged/wider-implications-three-pronged.org
View File

@@ -1,82 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-25 Mon]
:ID: 5c6d7e8f-9a0b-1c2d-3e4f-5a6b7c8d9e0f
:END:
#+title: Wider Practical Implications of the Three-Pronged System
#+filetags: :ideas:passepartout:implications:
Beyond Passepartout itself, the three-pronged model — deductive proofs, provenance-tracked empirical models, and probabilistic oracle, all under one gate — has implications for how computation is trusted, regulated, and used across every domain that relies on simulation or AI.
**1. The end of the trust-the-tool default.**
Today, if you run a molecular dynamics simulation in AMBER or a finite element analysis in ANSYS, you trust the result because the tool is widely used. "Everyone uses this software" is the epistemic warrant. The three-pronged system replaces this with an explicit chain: this equation was verified against classical mechanics, these parameters come from a specific experimental paper, this validity envelope covers the conditions you specified. The trust moves from "the tool is popular" to "the chain is traceable."
The implication: a less popular tool with good provenance becomes more trustworthy than an industry-standard tool with none. This changes the competitive dynamics of scientific software — the lock-in shifts from ecosystem size to provenance quality.
**2. AI safety as an architectural constraint, not a training target.**
Current AI safety is probabilistic. We train models not to lie, not to harm, not to be biased. The training is never perfect, the guardrails can be jailbroken, and every new model generation requires retraining the safety layer.
The three-pronged system offers a structural alternative: the LLM can propose anything, but the gate enforces what is actually executed. The LLM cannot write a file, send a message, or run a command — it can only propose. The gate decides. The safety is in the gate's predicates, not in the LLM's training.
The implication: safety becomes provable. You can verify that a gate predicate is correct (it blocks rm -rf / for all inputs). You cannot verify that a trained model is honest. This is the difference between "we hope the AI behaves well" and "the AI physically cannot execute a disallowed action."
**3. Regulatory science with defensible evidence chains.**
Pharmaceutical, aerospace, and medical device companies spend billions on computational simulations that regulators review. Currently, the review relies on the submitting company's assertion that the simulation was run correctly. The provenance chain is in lab notebooks and internal documents, not in the output itself.
A three-pronged system produces outputs with built-in defensibility: every parameter has a source, every approximation is tagged, every gate check is recorded, every uncertainty is budgeted. A regulator can read the output and see: "the force field was parameterized against these 50 experimental measurements, the DFT calculation used this functional and basis set, the validity envelope covers the conditions of interest, the total uncertainty is ±X."
The implication: regulatory review shifts from auditing the company's process to auditing the computation's chain. This is faster, more transparent, and less dependent on the reviewer's expertise in every specific tool.
**4. The reproducibility crisis has a technical solution.**
A major cause of the reproducibility crisis in computational science is incomplete specification of methods. "We used the AMBER force field" is not enough — which version? which parameter set? which cutoff scheme? which solvation model? Which experimental validation was it based on?
The three-pronged system's provenance chain is a complete specification by construction. Every computation is fully described by its model, its parameters, its validity envelope, and its gate checks. Reproducing the computation is a matter of loading the same provenance chain and running it.
The implication: computational reproducibility shifts from a social norm ("please share your code and parameters") to an automated property of the output. If the output does not carry a full provenance chain, it is not fully specified.
**5. Engineering safety margins become explicit.**
Every engineered structure — bridge, aircraft, medical implant — is designed using simulation. The safety margins are specified in standards (factor of 2, factor of 5, etc.) but the actual uncertainty in the simulation is rarely quantified. A civil engineer running a finite element analysis of a bridge does not know the combined uncertainty of the material model, the mesh resolution, the boundary conditions, and the load assumptions.
The three-pronged system would propagate uncertainty through the entire design chain. The output would include: "the failure probability under maximum load is 0.03%, with the following breakdown: material parameter uncertainty contributes 0.02%, mesh discretization contributes 0.005%, load modeling contributes 0.005%."
The implication: safety margins in standards can be replaced or supplemented by model-specific uncertainty budgets. A design with low uncertainty can use a smaller safety factor; a design with high uncertainty must use a larger one. This saves material and weight where the simulation is reliable, and forces conservatism where it is not — the opposite of today's one-size-fits-all approach.
**6. Education in how knowledge works.**
Current STEM education teaches equations and methods. Students learn to compute binding affinities, solve differential equations, run simulations. What they do not systematically learn is the difference between a proven result, a validated model prediction, and a reasonable guess.
A three-pronged system, used in education, would make this distinction visible for every computation. A student simulating a chemical reaction would see: "this reaction barrier was computed at the CCSD(T) level of theory with a complete basis set extrapolation — this is the gold standard in quantum chemistry and is well within the formal domain. The solvation correction uses an implicit solvent model validated against 200 experimental free energies of solvation for neutral organic molecules — this is an empirical model with known accuracy of ±0.5 kcal/mol. The conformational search used a genetic algorithm that may not have found the global minimum — this is a heuristic with no guaranteed completeness."
The implication: students develop epistemic hygiene as a side effect of using the system, not as a graduate-level skill acquired through years of trial and error.
**7. The economics of computational trust.**
Not all computations are equally valuable. A result that is deductively proven can be used as a building block for further proofs — its truth is inherited by any derivation that uses it. A result that is empirically validated is useful for decisions with known risk, but cannot be used as a deductive foundation. A result that is an LLM extrapolation is useful only for hypothesis generation.
The three-pronged system makes this distinction explicit, which has economic implications. A pharmaceutical company might pay more for a binding affinity prediction that carries a full provenance chain and uncertainty budget than for one that is just a number. A patent application based on a proven result is stronger than one based on a simulated one.
The implication: computational results become differentiated products, not interchangeable commodities. The provenance quality is the differentiator.
**8. The social protocol as a scientific knowledge commons.**
When multiple Passepartout instances share validated model parameters through the social protocol, the network accumulates a collective knowledge base that no single instance could build alone. A force field validated by one group for water, another for ethanol, another for DMSO — all shared with full provenance — becomes a model whose validity envelope has been extended across many conditions by distributed effort.
The implication: the social protocol is not just a communication mechanism. It is an infrastructure for distributed scientific knowledge curation. The network effect is not just more users; it is more validated knowledge.
**9. The gate as a universal integrity layer.**
The gate currently checks security and scientific validity. There is no reason it could not check other dimensions of integrity: ethical constraints (do not simulate chemical warfare agents), legal constraints (do not export restricted technology), economic constraints (do not run a compute job that exceeds the user's budget), or institutional constraints (only use models approved by the lab's review board).
The implication: the gate becomes a **configurable integrity layer** that enforces any policy that can be expressed as a predicate over the computation's inputs, models, and parameters. Different users, institutions, or jurisdictions can configure different gate policies without changing anything else in the system. Compliance becomes configuration.
**10. The shift from "what does the software do?" to "how does the system know what it knows?"**
This is the deepest implication. Most software today answers "what does this program output?" The three-pronged system answers "how does the system know that this output is reliable?" — by checking which domain it was produced in, tracing the provenance chain, and reporting the uncertainty budget.
This changes the fundamental question users ask of software. Instead of "is this tool well-regarded?" they ask "is this result proven, validated, or generated?" — and get a different answer for every specific result, not a blanket trust judgment about the tool.
The implication: computation becomes epistemically transparent. The system does not ask the user to trust it. It shows the user what it knows and how it knows it, and lets the user decide what to do with that information.

116
projects/passepartout/architecture/three-pronged/world-models-middle-domain.org
View File

@@ -1,116 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 0d1e2f3a-4b5c-6d7e-8f9a-0b1c2d3e4f5a
:END:
#+title: The Middle Domain as World Models
#+filetags: :ideas:passepartout:world-models:
The middle of the knowledge tree — layers 8 through 14, from quantum chemistry approximations to molecular design heuristics — corresponds almost exactly to what the AI and robotics communities call world models. Recognizing this connection reveals a structural requirement for Passepartout that the current architecture does not explicitly address.
**What a world model is.**
In the AI sense, a world model is a predictive representation that an agent uses to anticipate the consequences of actions. It answers the question: if I do X, what happens next? The classic formulation decomposes this into:
1. A sensory encoder that compresses observations into a latent state
2. A dynamics predictor that predicts the next latent state given an action
3. A reward or value predictor that evaluates states
Every layer of the knowledge tree from 8 upward fits this description — it predicts how some aspect of reality evolves given initial conditions, parameters, and boundary conditions.
**The deductive world models (layers 0-7).**
Logic, algebra, analysis, classical mechanics, quantum mechanics, statistical mechanics, electrodynamics — these are world models where the dynamics are deductively complete. Given the state (a wavefunction, a phase space point, a metric tensor) and the equations of motion (Schrödinger equation, Hamilton's equations, Maxwell's equations), the time evolution is determined. No parameters to fit. No learning required. The model is provably correct against its axioms.
These are the world models that ACL2 can verify. The prover can confirm that the Schrödinger solver correctly implements the Schrödinger equation for any input. The correctness is total — not statistical, not empirical.
**The empirical world models (layers 8-14).**
Quantum chemistry approximations, molecular mechanics, molecular dynamics, solvation models, docking scoring functions, reaction mechanism models, molecular design heuristics — these are world models where the dynamics are known in form but empirically parameterized. The functional form of the force field (bond stretching + angle bending + torsions + non-bonded) is a modeling choice. The parameters (force constants, equilibrium lengths, partial charges) are fitted to data. The solvation model has a mathematical structure, but its parameters are calibrated against measured solubilities.
These world models cannot be verified against axioms. They can only be validated against experiment. The validation is always provisional — valid for the molecules and conditions tested, uncertain outside that domain.
**The composition is layered world models, not a single one.**
The critical structural insight: the world models are not independent. They form a dependency hierarchy.
A docking prediction (layer 12) depends on:
- A solvation model (layer 11) with its own parameters and validity domain
- A molecular dynamics simulation (layer 10) that samples conformational space
- A force field (layer 9) that predicts energies and forces
- Quantum chemistry calculations (layer 8) that parameterize the force field
- Statistical mechanics (layer 6) that relates ensemble averages to binding free energies
- Classical mechanics (layer 4) that governs the MD integration
Each layer's uncertainty propagates upward. The docking prediction's error is not the scoring function's error in isolation — it is the compound uncertainty of the force field, the solvation model, the conformational sampling, the MD integrator, and the scoring function, all composed.
**The Passepartout world model formula.**
A world model in Passepartout's architecture is a triple:
**World Model = Verified Equations ⊗ Provenance-Tracked Parameters ⊗ Validity Envelope**
- **Verified Equations** — the formal skeleton: the differential equations, the integration scheme, the force field functional form. Verified by the ACL2 prover against the deductive layer below. This is what the gate can definitively check.
- **Provenance-Tracked Parameters** — the numbers that make the model match reality: force constants, partial charges, solvation parameters, scoring weights. Each carries a source (experimental paper, QM calculation, benchmark dataset), a confidence interval, a validity regime (temperature range, molecular class, solvent type), and a last-validation date.
- **Validity Envelope** — the region of input space where the model has been experimentally validated. A force field parameterized for soluble proteins at 298K in water is valid there; applying it to a membrane protein at 350K in ethanol may produce plausible numbers with no physical meaning. The validity envelope is a learned or specified boundary that the gate checks.
**The neurosymbolic engine's role in world models.**
The neurosymbolic split maps onto world model construction and use as follows:
- The **ACL2 prover** verifies the equations — the form of the model, the correctness of the implementation, the composition of multiple world models into a pipeline. This is deductive assurance.
- The **LLM oracle** handles synthesis — selecting which world model to apply to a given problem, interpreting the model's output in natural language, generating hypotheses about why a prediction failed, proposing new parameterizations or model forms when the existing ones are insufficient.
- A **new provenance layer** (described below) handles the third component — tracking parameters, maintaining validity envelopes, propagating uncertainty, and validating predictions against experiment.
**What this changes in the architecture.**
The architecture describes verification (the gate) and knowledge (the memex). World models require a third subsystem: the **empirical knowledge base** — a structured store of fitted parameters, experimental benchmarks, and validity regimes, with full provenance.
The empirical knowledge base would:
1. Store every parameter used by every world model (force field parameters, DFT functional constants, solvation model coefficients, docking scoring weights).
2. Attach provenance to each parameter: the paper, dataset, or calculation it came from, the confidence interval, the validity domain.
3. Track validation history: which experimental measurements have been compared to this model's predictions, with what outcome, and whether the parameters were updated as a result.
4. Enforce validity regimes at the gate level: if a computation applies a model outside its validity envelope, the gate either blocks it (safe default) or flags it with a reduced confidence score.
This is not the same as the symbolic index (which stores formal facts) or the neural index (which stores embedding vectors). It is a third index over empirical knowledge — parameteric, uncertain, and provisional, but no less essential for its lack of deductive certainty.
**The connection to self-improvement.**
The neurosymbolic engine's self-modification capability applies differently to each part of the world model triple:
- **Verifying new equations** (updating the deductive core): the system generates a new algorithm, ACL2 proves it correct against the specification, it is hot-reloaded. This is the Mathematica-bootstrapping scenario — the system improves its own deductive world models autonomously.
- **Updating parameters** (improving the empirical core): the system compares predictions to experimental measurements, detects systematic bias in a force field, and proposes updated parameters. The update is validated by checking whether the new parameters improve predictions on a held-out benchmark. No proof, just statistical improvement. The provenance trail records the change.
- **Expanding the validity envelope** (learning where models work): the system accumulates computational predictions and experimental results, and learns the boundaries where each model is reliable. This is a continuous process, not a one-time formalization.
The self-improvement loop for empirical world models is slower and more uncertain than for deductive ones — it requires experimental feedback, not just formal verification. But it is equally essential for any system that needs to operate in the real physical world rather than inside a closed formal system.
**The test case.**
Schafmeister's spiroligomer pipeline is the test case for all three components:
- The **equations** — QM calculations (layer 8), force field predictions (layer 9), MD integration (layer 10), thermodynamic integration (layer 11), docking (layer 12), design rules (layer 14) — all need verified implementations.
- The **parameters** — force field parameters for novel monomer types, solvation parameters for non-standard solvents, scoring function weights for spiroligomer-protein binding — need provenance and validity envelopes.
- The **validation** — experimental binding assays, catalytic rate measurements, structural characterization (NMR, crystallography) provide the feedback that updates parameter confidence and expands validity regimes.
If Passepartout can handle this pipeline correctly — distinguishing what is verified from what is empirically parameterized, tracking provenance through the composition of multiple world models, and propagating uncertainty from the bottom of the hierarchy to the top — then the architecture is complete. If it cannot, then the architecture only works for pure mathematics.
**Summary.**
| Layer | Type of world model | Verification mode | Key data |
|---|---|---|---|
| 0-7 | Deductive | ACL2 proof against axioms | Theorems, equations, algorithms |
| 8-14 | Empirical | Validation against experiment | Parameters, benchmarks, validity envelopes |
| All | Composed | Provenance + correctness | Traceability through pipeline |
The middle domain is world models. The architecture needs to be built to reflect that.
---
- [[id:9c0d1e2f-3a4b-5c6d-7e8f-9a0b1c2d3e4f][The Middle of the Knowledge Tree]] — the layers from logic to nanotechnology
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — current architecture

88
projects/passepartout/architecture/three-pronged/world-models-plain-language.org
View File

@@ -1,88 +0,0 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 1e2f3a4b-5c6d-7e8f-9a0b-1c2d3e4f5a6b
:END:
#+title: What the World Model Idea Means — Plain Language
#+filetags: :ideas:explanation:
An explanation of the world model idea and its implications, written for someone who does not want to parse architectural jargon.
**The basic idea in one sentence.**
Some things you can prove are true (like 2+2=4), and some things you can only model approximately because you have to fit the numbers to real-world measurements (like how strongly a particular molecule bends or twists). Most practically useful knowledge is the second kind.
**The deductive vs. empirical split.**
There is a floor in the building of human knowledge. Below the floor, everything is provable from first principles. This includes:
- Logic (if A implies B and A is true, then B is true)
- Mathematics (calculus, linear algebra, number theory)
- Fundamental physics (Newton's laws, the Schrödinger equation, Maxwell's equations)
In theory, a computer with enough power can prove things at this level. Given the right axioms and enough time, it can derive any true statement. This is what ACL2 does — it proves that a piece of code is correct for all possible inputs.
Above the floor, things change. The equations have a known form (bonds stretch like springs, molecules attract each other at long range and repel at short range), but the precise numbers in those equations have to be fitted to experimental measurements. There is no way to derive a spring constant from first principles — you have to measure it.
This includes:
- Chemistry (how strongly does this bond bend? how fast does this reaction happen?)
- Biology (how tightly does this drug bind to this protein? how fast does this enzyme work?)
- Engineering (how much weight can this beam hold before it cracks?)
- Medicine (does this drug work? what dose is safe?)
- Materials science (how strong is this alloy at high temperature?)
- Climate science, geology, pharmacology, and almost every other applied science
**The critical observation.**
Most of what humans actually care about lives above the floor. Pure mathematics is beautiful and foundational, but nobody builds a bridge, cures a disease, or designs a drug using only proofs from first principles. Every practical domain works with approximate models that are useful but not deductively certain.
Passepartout's verification engine can handle the stuff below the floor. It can prove that a numerical integration routine is correct, that a sorting algorithm works, that an algebraic simplification is valid. But above the floor, "verification" means something different — not "proven correct from axioms" but "the implementation correctly executes the model, and the model's parameters are traceable to experimental data."
**The three parts of a useful computation.**
In the deductive zone (below the floor), every computation has two parts:
1. The algorithm (how you compute it)
2. The verification (the proof that the algorithm is correct)
In the empirical zone (above the floor), every useful computation has three parts:
1. The equations (the known mathematical form of the model)
2. The parameters (the numbers fitted to experimental data)
3. The validity envelope (the range of conditions where the model is reliable)
The equations can be verified — ACL2 can prove that your force field code correctly implements Hooke's law. The parameters cannot be verified; they can only be validated against experimental data. The validity envelope cannot be proven either — it is a learned or declared boundary that says "we checked this model works for these kinds of molecules at these temperatures; outside that range, we don't know."
**What this means for Passepartout.**
**First, the architecture needs three subsystems, not two.**
The neurosymbolic split (probabilistic brain + deterministic prover) only covers the deductive zone. The empirical zone needs a third subsystem — a provenance tracker that stores where every parameter came from, what its confidence interval is, and what range of conditions it has been validated for.
This subsystem does not prove anything. It curates. It ensures that when Passepartout simulates a molecule, every force constant, every partial charge, every solvation parameter has a source that can be checked. If the same parameter was determined by two different experiments with different results, the system can report both and flag the uncertainty.
**Second, the gate gets a new job.**
The gate currently asks "is this action safe?" — should this shell command run, should this file be written, should this network message be sent. With the world model insight, the gate also asks "is this model valid for the context?" — this force field was parameterized for soluble proteins; you are applying it to a membrane protein. The answer may be "block" or "allow with reduced confidence" or "flag for human review."
This is not a security check. It is a scientific integrity check. But it uses the same mechanism — a policy evaluated before the computation proceeds.
**Third, self-improvement splits into two speeds.**
- **Fast loop** (below the floor): Passepartout generates a new algorithm, verifies it with ACL2, and hot-reloads it. This is what the Mathematica-bootstrapping scenario describes — days to generate thousands of provably correct functions. This loop runs autonomously.
- **Slow loop** (above the floor): Passepartout makes a prediction using an empirical model, gets experimental data back (either by performing an experiment or reading a paper), and updates the model's parameters or validity envelope. This loop requires real-world feedback. It cannot run autonomously — it needs data from the physical world.
Both loops matter. The fast loop makes Passepartout mathematically powerful. The slow loop makes it useful for real-world science and engineering.
**What this does not mean.**
This does not mean Passepartout cannot handle empirical science. It means Passepartout handles it differently — with explicit uncertainty, provenance tracking, and validity boundaries, instead of pretending the model is deductively certain.
This is actually a design advantage. Most scientific software treats its parameters as if they were provably correct. Force field databases ship as flat files with no provenance. Passepartout would be the first system that can say: "I am running the AMBER force field. The bond-stretching parameters come from a 1995 paper by Cornell et al., validated against 50 small molecules. The partial charges come from the RESP fitting procedure, applied to HF/6-31G* calculations. The validity envelope covers proteins and nucleic acids in aqueous solution at 273-373K. Your simulation involves a lipid membrane at 350K, which is outside the validated range. The results may be qualitatively correct but the quantitative predictions should be treated with caution."
No existing chemistry software does this. A system that can is more useful than one that cannot, even if the underlying simulation is the same.
**The broader implication.**
The deductive/empirical floor is not a weakness in Passepartout's design. It is a correct description of how knowledge actually works in the physical world. Most systems pretend everything is deductively certain and hide their assumptions. Passepartout would make the assumptions explicit, trace every number to its source, and report uncertainty alongside every result.
This is what it means to build a system that does not lie to you.

2
projects/passepartout/common-logic-iso-24707.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-05-24 Sun]
:ID: 04c2f221-c54f-51e5-b40a-48822cd16d45
:END:
#+title: Common Logic (ISO 24707) — Relevance to Passepartout
#+title: Common Logic (ISO 24707)
#+filetags: :passepartout:knowledge:logic:standards:iso:
Common Logic (ISO/IEC 24707) is a framework for first-order logic languages designed for knowledge exchange. It defines an abstract syntax and model-theoretic semantics. Any concrete syntax (dialect) that maps to the abstract syntax inherits the semantics — and all CL dialects are automatically interoperable.

2
projects/passepartout/hardware/server-build-bom.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-06-01 Mon]
:ID: e5f6a7b8-9c0d-1e2f-3a4b-5c6d7e8f90ab
:END:
#+title: Passepartout Server — Build BOM and Phased Plan
#+title: Passepartout Server
#+filetags: :passepartout:hardware:homelab:build:
**Passepartout Server — Build BOM & Phased Plan**

2
projects/passepartout/hardware/server-rack-build.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-05-31 Sun]
:ID: a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d
:END:
#+title: Server Rack Build — Working Note
#+title: Server Rack Build
#+filetags: :infrastructure:rack:build:
#+STATUS: draft

2
projects/passepartout/social-protocol/requirements-00-readme.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol: Decentralized Social Network
#+title: Social Protocol
#+AUTHOR: Amr
#+CREATED: [2026-03-17 Tue]
#+BEGIN_COMMENT

2
projects/passepartout/social-protocol/requirements-01-overview.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 01: Protocol Overview and Foundational Principles
#+title: Social Protocol Requirements - 01
#+author: Amero Garcia
#+created: [2026-03-19 Thu 21:07]
#+DATE: 2026-03-20

2
projects/passepartout/social-protocol/requirements-02-identity.org
View File

@@ -1,4 +1,4 @@
#+title: Identity: The Genesis of Your Digital Being
#+title: Identity
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 6fe67db6-25bd-4d11-bd1d-b44ec809e858

2
projects/passepartout/social-protocol/requirements-03-infrastructure.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 03: Infrastructure
#+title: Social Protocol Requirements - 03
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-14

2
projects/passepartout/social-protocol/requirements-04-the-primitive.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 04: The Primitive
#+title: Social Protocol Requirements - 04
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-15

2
projects/passepartout/social-protocol/requirements-05-social.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 05: Social Space
#+title: Social Protocol Requirements - 05
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-15

2
projects/passepartout/social-protocol/requirements-06-exchange-and-contracts.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 06: Exchange
#+title: Social Protocol Requirements - 06
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-15

2
projects/passepartout/social-protocol/requirements-07-advanced-integration.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 07: Advanced Integration
#+title: Social Protocol Requirements - 07
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-15

2
projects/passepartout/social-protocol/requirements-08-library.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 08: Library
#+title: Social Protocol Requirements - 08
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-14

2
projects/passepartout/social-protocol/requirements-09-implementation.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 09: Implementation
#+title: Social Protocol Requirements - 09
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-14

2
projects/passepartout/social-protocol/requirements-10-governance-and-assets.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 10: Governance and Physical Assets
#+title: Social Protocol Requirements - 10
#+author: Amero Garcia
#+created: [2026-03-22 Sun]
#+ID: agora-requirements-10-governance

2
projects/passepartout/social-protocol/requirements-10-user-journey.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements: User Journey & Product Experience
#+title: Social Protocol Requirements
#+AUTHOR: Passepartout Social Protocol
#+DATE: 2026-03-26

2
projects/passepartout/social-protocol/requirements-11-assessment.org
View File

@@ -1,4 +1,4 @@
#+title: Social Protocol Requirements - 11: Realistic Assessment
#+title: Social Protocol Requirements - 11
#+author: Amero Garcia
#+created: [2026-03-16 Mon 14:28]
#+DATE: 2026-03-22

2
projects/passepartout/strategy/competitors/ai-agents-scoping/aider.org
View File

@@ -2,7 +2,7 @@
:ID: c3aab2e8-7e43-4abc-93f0-741675cfd78c
:CREATED: [2026-05-22 Thu]
:END:
#+title: Aider — AI Coding Agent
#+title: Aider
#+filetags: :passepartout:strategy:competitive:aider:
Language: Python. ~6.8M pip installs. ~40K lines. MIT license. The oldest and most mature open-source coding agent.

2
projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org
View File

@@ -2,7 +2,7 @@
:ID: 512dd121-2292-4f3d-ac53-31bf3d12a60f
:CREATED: [2026-05-22 Thu]
:END:
#+title: Claude Code — Anthropic AI Coding Agent
#+title: Claude Code
#+filetags: :passepartout:strategy:competitive:claude-code:
Anthropic's proprietary coding agent. TypeScript/Bun, ~512K lines (leaked source analysis). Not open source.

2
projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org
View File

@@ -2,7 +2,7 @@
:ID: e929ff32-28d8-4a29-bf74-d55babc040d1
:CREATED: [2026-05-22 Thu]
:END:
#+title: Codex CLI — OpenAI AI Coding Agent
#+title: Codex CLI
#+filetags: :passepartout:strategy:competitive:codex:
OpenAI's open-source coding agent. Rust, ~950K lines, sandboxed.

2
projects/passepartout/strategy/competitors/ai-agents-scoping/continue.org
View File

@@ -2,7 +2,7 @@
:ID: 22d0a159-68a2-4587-9375-5046beddc20c
:CREATED: [2026-05-22 Thu]
:END:
#+title: Continue — CI/Check System
#+title: Continue
#+filetags: :passepartout:strategy:competitive:continue:
TypeScript, ~328K lines, Apache 2.0. Source-controlled AI checks for CI/CD. Markdown-as-gate-policy.

2
projects/passepartout/strategy/competitors/ai-agents-scoping/gemini-cli.org
View File

@@ -2,7 +2,7 @@
:ID: 8d73ccb9-34e4-4899-b0c3-605998e9bebc
:CREATED: [2026-05-22 Thu]
:END:
#+title: Gemini CLI — Google AI Coding Agent
#+title: Gemini CLI
#+filetags: :passepartout:strategy:competitive:gemini:
Google's open-source coding agent. TypeScript, ~525K lines, Apache 2.0. Node.js 20+, Ink/React TUI.

2
projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org
View File

@@ -2,7 +2,7 @@
:ID: c652688a-1ea0-487c-9222-00e954efe8a1
:CREATED: [2026-05-22 Thu]
:END:
#+title: Hermes Agent — Personal AI Assistant
#+title: Hermes Agent
#+filetags: :passepartout:strategy:competitive:hermes:
The agent running this conversation. Python, ~17K core lines, MIT.

2
projects/passepartout/strategy/competitors/ai-agents-scoping/openclaw.org
View File

@@ -2,7 +2,7 @@
:ID: 85ca69dd-d085-4a55-ad11-021910b1f82e
:CREATED: [2026-05-22 Thu]
:END:
#+title: OpenClaw — Personal AI Assistant
#+title: OpenClaw
#+filetags: :passepartout:strategy:competitive:openclaw:
TypeScript/Node.js, ~3.5M lines. The largest codebase analyzed. Personal AI assistant with 25+ messaging channel support.

2
projects/passepartout/strategy/competitors/ai-agents-scoping/opencode.org
View File

@@ -2,7 +2,7 @@
:ID: 7a060b36-36db-4eb7-b8cc-844bd6ac9d36
:CREATED: [2026-05-22 Thu]
:END:
#+title: OpenCode — AI Coding Agent
#+title: OpenCode
#+filetags: :passepartout:strategy:competitive:opencode:
TypeScript/Bun. anomalyco/opencode, 163K★. The dominant open-source coding agent by adoption. Bun runtime, Effect-TS functional core, Solid.js TUI, Turborepo monorepo.

2
projects/passepartout/strategy/competitors/ai-agents-scoping/thoth.org
View File

@@ -2,7 +2,7 @@
:ID: 416bab7c-4300-4d50-838a-5c7a8ad45d96
:CREATED: [2026-05-22 Thu]
:END:
#+title: Thoth — Personal AI Sovereignty
#+title: Thoth
#+filetags: :passepartout:strategy:competitive:thoth:
https://github.com/siddsachar/Thoth — Python, ~151K lines, Apache 2.0. Local-first desktop AI assistant with knowledge graph, tools, voice, vision, shell, browser automation, workflow engine, and messaging channels.

2
projects/passepartout/strategy/competitors/competitive-analysis.org
View File

@@ -2,7 +2,7 @@
:ID: 3aa22300-2f25-57b0-8787-9f199cc978b1
:CREATED: [2026-05-22 Thu]
:END:
#+title: Competitive Analysis — AI Agent Landscape
#+title: Competitive Analysis
#+filetags: :passepartout:strategy:competitive:
* Overview

2
projects/passepartout/strategy/competitors/rainbird-ai-case-study.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-05-31 Sun]
:ID: a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d
:END:
#+title: Rainbird AI — Comprehensive Case Study
#+title: Rainbird AI
#+filetags: :passepartout:strategy:competitors:rainbird:
#+STATUS: draft

2
projects/passepartout/strategy/compliance/compliance-regimes/appi.org
View File

@@ -3,7 +3,7 @@
:ID: auto-appi
:CREATED: [2026-05-23 Sat]
:END:
#+title: APPI (Act on the Protection of Personal Information — Japan)
#+title: APPI
#+filetags: :passepartout:compliance:framework:appi:

2
projects/passepartout/strategy/compliance/compliance-regimes/apra-cps-234.org
View File

@@ -3,7 +3,7 @@
:ID: auto-apra-cps-234
:CREATED: [2026-05-23 Sat]
:END:
#+title: APRA CPS 234 (Prudential Standard — Information Security)
#+title: APRA CPS 234
#+filetags: :passepartout:compliance:framework:apra:
** APRA CPS 234 (Prudential Standard — Information Security)

2
projects/passepartout/strategy/compliance/compliance-regimes/basel-iii.org
View File

@@ -3,7 +3,7 @@
:ID: auto-basel-iii
:CREATED: [2026-05-23 Sat]
:END:
#+title: Basel III (Bank for International Settlements — Basel Committee)
#+title: Basel III
#+filetags: :passepartout:compliance:framework:basel:
** Basel III (Bank for International Settlements — Basel Committee)

2
projects/passepartout/strategy/compliance/compliance-regimes/dpdp-act.org
View File

@@ -3,7 +3,7 @@
:ID: auto-dpdp-act
:CREATED: [2026-05-23 Sat]
:END:
#+title: DPDP Act (Digital Personal Data Protection Act — India)
#+title: DPDP Act
#+filetags: :passepartout:compliance:framework:dpdp:

2
projects/passepartout/strategy/compliance/compliance-regimes/irap.org
View File

@@ -3,7 +3,7 @@
:ID: auto-irap
:CREATED: [2026-05-23 Sat]
:END:
#+title: IRAP (Infosec Registered Assessors Program — Australia)
#+title: IRAP
#+filetags: :passepartout:compliance:framework:irap:

2
projects/passepartout/strategy/compliance/compliance-regimes/ismap.org
View File

@@ -3,7 +3,7 @@
:ID: auto-ismap
:CREATED: [2026-05-23 Sat]
:END:
#+title: ISMAP (Government Security Framework — Japan)
#+title: ISMAP
#+filetags: :passepartout:compliance:framework:ismap:
is moderate — few non-Japanese vendors target [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] specifically, and the 2022

2
projects/passepartout/strategy/compliance/compliance-regimes/lfp-dppp.org
View File

@@ -3,7 +3,7 @@
:ID: auto-lfp-dppp
:CREATED: [2026-05-23 Sat]
:END:
#+title: LFPDPPP (Ley Federal de Protección de Datos Personales — Mexico)
#+title: LFPDPPP
#+filetags: :passepartout:compliance:framework:lfp:

2
projects/passepartout/strategy/compliance/compliance-regimes/lgpd.org
View File

@@ -3,7 +3,7 @@
:ID: auto-lgpd
:CREATED: [2026-05-23 Sat]
:END:
#+title: LGPD (Lei Geral de Proteção de Dados — Brazil)
#+title: LGPD
#+filetags: :passepartout:compliance:framework:lgpd:

2
projects/passepartout/strategy/compliance/compliance-regimes/pipa.org
View File

@@ -3,7 +3,7 @@
:ID: auto-pipa
:CREATED: [2026-05-23 Sat]
:END:
#+title: PIPA (Personal Information Protection Act — South Korea)
#+title: PIPA
#+filetags: :passepartout:compliance:framework:pipa:

2
projects/passepartout/strategy/domain-sequencing.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-05-29 Fri]
:ID: c7d3f1a2-8b4e-5d6f-9a1c-3b2d4e5f6a7b
:END:
#+title: Domain Sequencing — What Gets Built When and Why
#+title: Domain Sequencing
#+filetags: :passepartout:strategy:domains:sufficiency:
The sufficiency flip is per-domain, and domains must be sequenced by strategic value, not intellectual interest. Building general knowledge first is the Cyc trap. Building the verification economy first is the way out.

2
projects/passepartout/strategy/hosting-economics.org
View File

@@ -2,7 +2,7 @@
:CREATED: [2026-05-31 Sun]
:ID: b2c3d4e5-f6a7-8b9c-0d1e-2f3a4b5c6d7e
:END:
#+title: Pass as a Service — Hosting Economics
#+title: Pass as a Service
#+filetags: :passepartout:strategy:hosting:economics:
#+STATUS: draft

2
projects/passepartout/strategy/impact/phase-0-impact.org
View File

@@ -2,7 +2,7 @@
:ID: a0b1c2d3-e4f5-6789-0abc-def012345678
:CREATED: [2026-05-25 Mon]
:END:
#+title: Phase 0 — Impact
#+title: Phase 0
#+filetags: :passepartout:strategy:adoption:impact:
Phase 0 spans 10 to 10² users. The system is live but barely visible.

2
projects/passepartout/strategy/impact/phase-1-impact.org
View File

@@ -2,7 +2,7 @@
:ID: b1c2d3e4-f5a6-7890-1bcd-ef0123456789
:CREATED: [2026-05-25 Mon]
:END:
#+title: Phase 1 — Impact
#+title: Phase 1
#+filetags: :passepartout:strategy:adoption:impact:
Phase 1 spans 10² to 10⁴ users. The protocol's existence becomes

2
projects/passepartout/strategy/impact/phase-2-impact.org
View File

@@ -2,7 +2,7 @@
:ID: c2d3e4f5-a6b7-8901-2cde-f01234567890
:CREATED: [2026-05-25 Mon]
:END:
#+title: Phase 2 — Impact
#+title: Phase 2
#+filetags: :passepartout:strategy:adoption:impact:
Phase 2 spans 10⁴ to 10⁶ users. The protocol's economic weight becomes

2
projects/passepartout/strategy/impact/phase-3-impact.org
View File

@@ -2,7 +2,7 @@
:ID: d3e4f5a6-b7c8-9012-3def-012345678901
:CREATED: [2026-05-25 Mon]
:END:
#+title: Phase 3 — Impact
#+title: Phase 3
#+filetags: :passepartout:strategy:adoption:impact:
Phase 3 spans 10⁶ to 10⁸ users. Both the verification and social

2
projects/passepartout/strategy/impact/phase-4-impact.org
View File

@@ -2,7 +2,7 @@
:ID: e4f5a6b7-c8d9-0123-4ef0-123456789012
:CREATED: [2026-05-25 Mon]
:END:
#+title: Phase 4 — Impact
#+title: Phase 4
#+filetags: :passepartout:strategy:adoption:impact:
Phase 4 spans 10⁸ to 10⁹ users. Two-tier computing is the stable