diff --git a/projects/cl-modernization/biology-parallels.org b/ideas/biology-parallels.org similarity index 100% rename from projects/cl-modernization/biology-parallels.org rename to ideas/biology-parallels.org diff --git a/ideas/lisp-game-engine-substrate.org b/ideas/lisp-game-engine-substrate.org new file mode 100644 index 0000000..331d756 --- /dev/null +++ b/ideas/lisp-game-engine-substrate.org @@ -0,0 +1,29 @@ +:PROPERTIES: +:CREATED: [2026-06-05 Fri] +:END: +#+title: Lisp as Game Engine Substrate + +The GOAL compiler (Naughty Dog, Jak and Daxter) proved Lisp could ship SOTA games on constrained hardware (PS2, 32MB RAM). Twenty years later, the question is whether Lisp can do it again on modern hardware — and whether the CL Modernization work makes it viable. + +**What Lisp gives you that C++ cannot match:** + +- Interactive development at runtime — change AI, physics, or rendering code while the game runs. No compile-link-run cycle. C++ engines for large projects measure iteration in minutes; Lisp measures it in frames. +- Macros for game DSLs — behavior trees, animation blend graphs, dialogue trees, state machines become native Lisp code instead of external tools with serialization boundaries. +- CLOS multiple dispatch for ECS — generic functions on component types replace manual message routing. +- Image-based workflow — save and resume the entire engine state (GPU, audio, physics, editor) from anywhere. + +**Where Lisp falls short:** + +- GC tail latency — concurrent generational GCs (single-digit ms) are acceptable for 60fps (16ms budget) but problematic for VR at 90fps (11ms) or competitive esports. The CL Modernization analysis identifies this as inherent but mitigatable, and eliminates it entirely on a tagged RISC-V core with hardware CONS and concurrent collection. +- GPU interop — no idiomatic Vulkan/DirectX 12 bindings. This is an ecosystem gap (fixable), not a language limitation. +- No modern engine exists — Unreal Engine 5 is ~5M lines of C++. At 3-5x density, a Lisp equivalent might be 1-2M lines. Massive but smaller than the C++ baseline. + +**The GOAL lesson:** Naughty Dog's compiler used disciplined Lisp written to avoid allocation on hot paths, proving the constraint is programmer practice, not language capability. Modern SBCL with type declarations compiles to within 2x of C on hot numerical code — sufficient for games where the bottleneck is GPU fill rate, not CPU-bound game logic. + +**What changes with the CL Modernization work:** A verified Lisp runtime eliminates the class of bugs that causes engine crashes; a RISC-V Lisp extension with hardware CONS and concurrent GC eliminates the tail-latency argument against real-time use; and the density advantage makes a from-scratch engine build tractable for an AI agent working at 10x human velocity. + +For further analysis, see [[https://en.wikipedia.org/wiki/GOAL_(programming_language)]]. + +See also: +- [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][Lisp Foundation]] — the CL Modernization analysis this builds on +- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the verified Lisp machine target diff --git a/ideas/lisp-geometry-engine.org b/ideas/lisp-geometry-engine.org new file mode 100644 index 0000000..65e7dea --- /dev/null +++ b/ideas/lisp-geometry-engine.org @@ -0,0 +1,174 @@ +:PROPERTIES: +:CREATED: [2026-05-11 Mon] +:END: +--- +type: idea +title: All-Lisp Geometry Engine +created: '2026-06-04T00:00:00.000Z' +tags: + - APM + - CAD + - CAM + - UX + - architecture + - constraint-solving + - design-tools + - empirical + - gaming + - geometry-engine + - lisp + - provenance + - three-pronged +--- + +A unified Lisp geometry engine built on the three-pronged model — the +constraint kernel IS the physics, and the design world is aware of its own +physics by default because the system won't let you produce a design that +violates physical constraints without flagging it. + +This is Ivan Sutherland's Sketchpad vision (1963), fully realized: the +drawing IS the program, the constraints ARE the physics, and the system +solves them in real-time — across CAD precision, game rendering, and UX +layout — from one kernel in one address space. + +--- + +**The three prongs, applied to the geometry engine.** + +The three-pronged architecture (deductive proofs / provenance-tracked +empirical models / probabilistic oracle, under one gate) is not an abstract +epistemological framework. It maps directly onto what a design tool needs. + +**Prong 1 — deductive: the constraint solver.** + +The geometry kernel IS deductive mathematics. When the solver determines +that four points are coplanar, or that an edge is tangent to a cylinder at +exactly 5mm offset, it is computing a deductive consequence of the +constraint system. The formulas for intersection, tangency, and spatial +relationships are formal geometry. ACL2 could verify them. The constraint +network is a theorem: the set of all poses that satisfy the specified +relations. Solving it is proving the theorem. + +**Prong 2 — empirical: provenance-tracked material properties.** + +This is the prong that changes design work fundamentally. Currently, design +software pretends material properties are true numbers. You pick "steel" +from a dropdown and see Young's modulus = 200 GPa. But that 200 GPa is an +average across 50 samples from different suppliers at different batch runs. +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 epistemic status: measured from a specific experiment, +fitted to a published dataset, extrapolated beyond validation with a +confidence penalty, or guessed because no data exists. The provenance store +holds the source chain, validity envelope, and confidence interval for every +parameter. The constraint solver propagates uncertainty automatically. + +The consequence: the designer designs to a distribution, not a platonic +number. The clearance at a joint shows as 0.03-0.08mm, not 0.05mm flat. +Material selection becomes a query with confidence thresholds, not a +dropdown. Tolerance stack-up falls out of provenance automatically. The +finished design carries a confidence budget: "Confidence this meets +specification under rated load: 95%. Material parameter uncertainty +contributes 3%, manufacturing tolerance contributes 1.5%." + +The validity envelope constrains what the designer can even specify. You try +to design a seal for 500C operation. The provenance store says: the +empirical model for this material is validated to 300C. 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 with a signature) or select a material with +better empirical coverage. + +Manufacturing feedback closes the loop. The part is made, as-manufactured +dimensions are measured, the real friction coefficient is recorded. These +values write back to the provenance store. The next design iteration has +tighter confidence intervals because it incorporates production data. +Datasheet revisions propagate retroactively: a bearing manufacturer revises +load rating downward, the provenance store updates, the gate re-checks all +existing designs and flags: "Your coupling assumed 5kN from the 2022 +datasheet. The 2025 revision shows 4.2kN. Safety margin is now below +required threshold." + +**Prong 3 — probabilistic: the LLM as constraint explorer.** + +The LLM proposes constraint system structures: "Here's a four-bar linkage +with these initial parameters." The solver validates deductively. The LLM +diagnoses failures: "The solver can't converge because constraint A and +constraint B conflict — the offset exceeds available column space given the +pivot locations." The LLM proposes alternatives; the solver checks. + +The LLM handles what cannot be formalized: model selection (which force +field for this molecule class?), interpretation (why did the simulation +fail?), creative generation (suggest a design that meets these spec limits). +The gate ensures the LLM proposes only — it never executes. + +--- + +**One representation, all domains.** + +The same constraint kernel drives engineering (CAD/CAM — float64, micron +precision, batch solve), gaming (float32, 144fps, iterative solve), and UX +layout (pixel-aligned, 120fps, layout constraints). CLOS dispatch selects +the solver backend based on the precision context and frame deadline. The +constraint language is the same; the solver varies by domain. + +Lisp macros generate optimized inner loops from the constraint DSL — typed, +inlined, unstyled — that SBCL compiles to within 2x of C. The hot path +narrowphase runs as native code, not through generic function dispatch. + +--- + +**Origin: Drexler's APM community and Godot.** + +The motivation came from Eric Drexler's atomically precise manufacturing +community, which wanted to use Godot as a molecular machine design suite. A +game engine provides exactly what molecular nanotechnology design requires: +real-time 3D, constraint-based physics, collision detection, and interactive +spatial editing. But Godot's C++/GDScript substrate has no provenance +tracking, no validity envelopes, and no epistemic awareness. A Lisp geometry +engine on the three-pronged architecture provides what the APM design suite +needs: the constraint kernel ensures geometric consistency (deductive), the +provenance store tracks force field parameters and validity envelopes +(empirical), and the LLM proposes molecular machine designs guided by +physical constraints (probabilistic). + +--- + +**Computational feasibility.** + +- CAD: feasible today on SBCL. Float64 is native, no frame deadline, CLOS + dispatch at design scale (thousands of constraints, not millions). +- UX layout: feasible today. 2D constraints at 120fps with moderate scene + complexity. +- Gaming at 144fps: needs Stage 3 hardware (tagged RISC-V, hardware GC, + geometry accelerators). CLOS dispatch overhead and GC tail latency on + commodity hardware consume too much of the 6.9ms frame budget for AAA + scene complexity. +- The LLM-guided constraint search (prong 3) makes the symbolic approach + tractable at assembly scale — the LLM proposes, the solver validates, + successful patterns cache as deductive rules. + +--- + +**Connection to Passepartout's three-pronged architecture.** + +The three-pronged section of the architecture describes "two reasoning +engines and one data store": the symbolic engine (ACL2, formal proofs, +deductive gate rules), the provenance store (empirical parameters with +sources, validity envelopes, confidence intervals), and the probabilistic +oracle (the LLM, proposing within gate bounds). + +The geometry engine is not an application that happens to use this +architecture. The geometry engine IS the architecture made concrete. The +constraint solver IS the symbolic engine reasoning about design rules. The +material property database IS the provenance store. The designer exploring +alternatives IS the LLM oracle proposing and the solver validating. The gate +checking a design against the validity envelope before permitting it to be +released to manufacturing IS the same gate that checks a shell command +against security policy. + +Stage 3 hardware makes it run fast enough for real-time domains. That is +where the geometry engine meets the Lisp machine — the killer app that +justifies and defines the hardware feature set. diff --git a/ideas/orders-of-magnitude-time.org b/ideas/orders-of-magnitude-time.org index 08fd317..196d962 100644 --- a/ideas/orders-of-magnitude-time.org +++ b/ideas/orders-of-magnitude-time.org @@ -1,4 +1,4 @@ -#+title: Orders of Magnitude — Time +#+title: Orders of Magnitude #+filetags: :passepartout:framework:time:scale:hierarchy: :PROPERTIES: diff --git a/projects/passepartout/architecture/three-pronged/open-source-wolfram-lisp.org b/ideas/viability/open-source-wolfram-lisp.org similarity index 100% rename from projects/passepartout/architecture/three-pronged/open-source-wolfram-lisp.org rename to ideas/viability/open-source-wolfram-lisp.org diff --git a/projects/passepartout/architecture/three-pronged/passepartout-bootstrap-mathematica.org b/ideas/viability/passepartout-bootstrap-mathematica.org similarity index 100% rename from projects/passepartout/architecture/three-pronged/passepartout-bootstrap-mathematica.org rename to ideas/viability/passepartout-bootstrap-mathematica.org diff --git a/projects/passepartout/architecture/three-pronged/schafmeister-clasp-nanotechnology.org b/ideas/viability/schafmeister-clasp.org similarity index 77% rename from projects/passepartout/architecture/three-pronged/schafmeister-clasp-nanotechnology.org rename to ideas/viability/schafmeister-clasp.org index 1cd7b46..85e5b96 100644 --- a/projects/passepartout/architecture/three-pronged/schafmeister-clasp-nanotechnology.org +++ b/ideas/viability/schafmeister-clasp.org @@ -2,47 +2,51 @@ :CREATED: [2026-05-24 Sun] :ID: f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f :END: -#+title: Christian Schafmeister — Common Lisp in Computational Nanotechnology +#+title: Christian Schafmeister #+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.** +* 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.** +* Why Lisp won. -Schafmeister's argument for Common Lisp in computational nanotechnology mirrors the same reasoning that drives Passepartout's architecture: +Schafmeister's argument for Common Lisp in computational nanotechnology mirrors the same reasoning that drives the knowledge-layers 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.** +* 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.** +* 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.** +* Relevance to the knowledge-layers architecture. -Schafmeister's work is existence proof for two of Passepartout's core claims: +Schafmeister's work is existence proof for two 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. +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 the knowledge-layers architecture 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. +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. +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 in both cases. --- -- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — why Lisp is the choice for verified infrastructure +See also: +- [[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] — the architecture that extends Schafmeister's principle to verification +- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — why Lisp is the choice for verified infrastructure diff --git a/projects/cl-modernization/_index.org b/projects/cl-modernization/_index.org index 2e4271a..80ddf3b 100644 --- a/projects/cl-modernization/_index.org +++ b/projects/cl-modernization/_index.org @@ -3,203 +3,6 @@ :ID: 971cd9e7-2cc5-4743-8042-2469dbe4078f :END: #+title: CL Modernization -#+filetags: :Passepartout:common-lisp:modernization:prover:tooling:build-system:HOL:ACL2: -#+STATUS: active +#+filetags: :redirect: -* 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 CL modernization project 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 (bootstrap HOL verified by ACL2) that makes Lisp the safest language to write self-modifying code in — which is exactly what Passepartout is. - -The central claim: Lisp's defects are not fundamental. They are deferred ecosystem work. GC pauses, the lack of a memory model, unpredictable performance, the tiny library count, the missing package manager — every single one is fixable through engineering, not through a different language. Distinguish carefully: - -#+BEGIN_QUOTE -**True defects** (inherent to the model, not fixable without changing what Lisp is): -- GC pauses — everything is a tagged pointer on the heap; mitigatable but not eliminatable -- No memory model / no Send/Sync — threads share everything by default; concurrency correctness is a discipline, not a compiler guarantee - -**Achievable improvements** (implementation and ecosystem, not philosophy): -- Package manager and build system like Cargo -- LSP-level tooling that surfaces SBCL's world-class type inference -- Static binaries and deployment -- Modern standard library (hash sets, priority queues, JSON, HTTP, async) -- Verified prover for memory safety, race freedom, and macro soundness -- Ecosystem scale (a network effect, fixable with sustained effort) -#+END_QUOTE - -The first category — GC pauses and shared-state concurrency — is a genuine engineering constraint, but it is contingent on hardware, not a law of nature. Symbolics' Genera OS was a full operating system written in Lisp — device drivers, window system, TCP/IP, file server, all running on the Ivory processor with hardware tag checking, generational write barriers at cache level, and single-cycle CONS allocation. Lisp was a systems language; the chip was designed for it. The reason Lisp struggles on modern silicon is that 40 years of CPU design — cache lines (64 bytes for C structs), prefetchers (linear access patterns), TLBs (contiguous layout), branch predictors (C's control flow) — has been optimized for C's memory model, not for tagged pointer architectures. A RISC-V extension with ~50K additional gates (CONS with write barrier, tag dispatch, read barrier, tag extract, GC check) eliminates the hardware mismatch, as analyzed in [[id:dddd52a7-adb8-470e-a459-614ade5f76af][Closing the Lisp Gap]]. - -Without dedicated silicon, Lisp on commodity hardware has larger memory overhead and less predictable pause times on allocation-heavy workloads than C or Rust. For everything Passepartout does — knowledge management, protocol synthesis, agent coordination, verification — modern concurrent generational GCs (single-digit millisecond pauses) are entirely acceptable. The second category — the ecosystem gap — is what this project fixes. - -* Why Lisp Is a Uniquely Good Candidate - -Every other language has a worse starting position for this kind of bootstrap. Here is why Lisp wins: - -**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. The programmer types S-expressions. The prover reads S-expressions. They speak the same notation. This is not a minor convenience — it 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 itself 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. The trust chain is: - -#+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 no verified prover. Python has no verified prover. Lean has a verified kernel but does not run in Python — the prover language is separate from the target language, creating a semantic gap. - -**3. The numerical economy argument (density 3-5×).** - -Lisp's code density is 3-5× higher than C, Rust, or Go for the same semantic work. The social protocol alone — identity, messaging, groups, governance, federation — compresses from ~100 million lines (Twitter, Facebook, Discord, Signal, etc., each reimplementing the same primitives) to ~5,000 lines of specification and ~50,000 lines of synthesized Lisp. This 2,000× compression is not a performance claim — it is a /maintenance/ claim. 5,000 lines of spec have fewer bugs, fewer attack surfaces, and fewer compliance gaps than 100 million lines. When the prover can verify the 5,000 lines, the remaining surface shrinks to essentially zero for specification-level bugs. That is the stack effect: every reduction in complexity compounds because the prover's coverage grows with the system's clarity. - -**4. The type system is not a limitation — Coalton proves it.** - -Coalton embeds sound Hindley-Milner typing inside Common Lisp, preserving homoiconicity. You opt in per-file. This means a CL modernization project does not need to design a new type system — it inherits one that is already integrated and working. The type system becomes /additive/, not /prescriptive/: you can write untyped Lisp for prototypes and add Coalton annotations for production paths. This is the opposite of Rust, where type soundness is mandatory for the entire program. For a self-improving agent, the additive model is strictly better — it lets the agent work in the 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 in two years with sufficient automation. The gap is not in Lisp's capacity — it is in the community's labor supply. An AI agent working at 10× human velocity changes the labor equation. - -* The Gap: Current State Assessment - -**The performance gap** with C and Rust on hot numerical code is roughly 10-20% in SBCL, concentrated in a few well-understood weaknesses: - -- Alias analysis — SBCL conservatively assumes any memory reference could alias any other. Rust's borrow checker gives LLVM perfect aliasing at function scope. Fixable in ~1-2 person-years. -- LLVM backend — Clasp's hybrid approach (fast-path LLVM, slow-path runtime) is the right design but needs significant engineering. -- PGO — SBCL has profiling (sb-sprof) but no feedback loop. Fixable in ~1 person-year. -- SIMD — No standard SIMD library for Lisp. ~2-3 person-years for a portable abstraction. -- Post-link optimization — SBCL's unusual code layout chokes tools like BOLT. A research problem. - -**The ecosystem gap** is the larger barrier: - -| Feature | Rust | Common Lisp | -|---------|------|-------------| -| Package manager | Cargo (lockfile, binary cache, workspaces) | Quicklisp (source-only, no lockfiles) | -| LSP | rust-analyzer | No universal LSP | -| Formatter | rustfmt (universal) | cl-form (not universal) | -| Test framework | Built-in with benchmarks | Various (FiveAM, Prove) | -| Library count | ~180k | ~2k | -| WASM target | First-class | Modest | -| Static binaries | First-class | Possible but non-standard | - -The largest gap is the package manager — the single highest-leverage investment. The library count (~100× fewer) follows from the lack of a modern build tool, not from a lack of demand. - -* Corrected Phase Plan - -The prover must come first, not last. An unverified base cannot bootstrap a verified upper layer. Every tool that the agent uses to build the next tool must itself be provably correct. The order flips from /easiest first/ to /most foundational first/. - -**Phase 0: Verified HOL Kernel (~2-4 months, ~500-800 lines of CL)** - -The HOL kernel (HOL Light's 10 primitive inference rules, ~400 lines of OCaml) is the smallest, best-defined, highest-leverage artifact in the entire project. Transcribed into pure CL and verified by ACL2, it becomes a proved higher-order prover inside the Lisp environment. - -Why the kernel is the right first artifact: -- /Tiny./ 500-800 lines. A well-known mathematical specification. No ambiguity about what correct means. -- /High leverage./ The kernel is the first prover Passepartout can call. Once it exists, every subsequent phase can be verified by it. -- /Low risk./ This is not a research problem — it is an engineering transcription of a known artifact. The only risk is ACL2 iteration time for verification. - -Dependency: Passepartout can write and debug CL code reliably. The HOL kernel ideal for an LLM to generate: small, fully specified, stateless, unambiguous correctness criteria. ACL2 catches hallucinations. Iteration converges in 2-3 attempts. - -**Phase 1: Minimal Verified Build System (~4-6 months)** - -A build system that can compile CL projects with deterministic lockfiles. Does not need to be Cargo-complete — just enough to compile the prover, the LSP, and its own source. - -Key insight: only the dependency resolution and compilation logic can be fully proved. The IO layer (filesystem, subprocesses, network) must be trusted or wrapped in a small verified interface. The build system is the first practical test of the prover — proving that dependency resolution is acyclic and that compilation is deterministic. - -**Phase 2: Verified LSP Server (~6-8 months)** - -Bridges SBCL's compiler to the LSP protocol. Two modes: -- /Online (connected image):/ Rich interactivity, live type inference, jump-to-definition. -- /Offline (static analysis):/ Works without a running image, uses proved type information. - -Verified to not crash, not deadlock, and produce correct type information. This is the tool that makes writing the rest of the stack productive. - -Key risk: SBCL's type inference is designed for compile-time warnings, not for a responsive protocol. Wrapping it requires significant engineering, and proving the wrapping layer is correct is non-trivial. - -**Phase 3: Coalton + Verified Standard Library (~12-18 months)** - -Coalton as a first-class typed path. Hash sets, priority queues, JSON, HTTP client, async scheduler, immutable data structures — all proved correct. Unicode-by-default string handling. Pattern matching. Backward-compatible with the 1994 standard. - -This is the largest phase by lines of code. The prover has to verify thousands of modules. Verification of complex data structures (hash tables, concurrent queues, async schedulers) is non-trivial. This is where proof costs become visible — and where the agent's automation of proof discovery matters most. - -Key risk: Volume. 12-18 months assumes the agent compounds its own proving capability during the phase. Without that, the timeline extends. - -**Phase 4: Self-Hosting, Self-Verifying CL Stack (~6-12 months)** - -The modernized CL toolchain compiles itself. The compiler is verified. The runtime has a proved GC (at least bounded pause times). Passepartout proves its own transformation rules correct. - -This is the capstone: a self-improving machine that proves every change before applying it. No other language has achieved this. Even the most advanced systems (Coq, Lean) have a trusted computing base that includes the kernel and the runtime — the /rest/ of their infrastructure is unverified. CL Modernization Phase 4 aims for a verified toolchain from kernel to compiler to build system, with only the SBCL runtime left as trusted. - -Key risk: Self-verification bootstrapping is the hardest problem in proving. Proving that the compiler compiling itself produces a correct binary requires a bootstrapping argument that few systems have ever attempted and none have fully achieved. The HOL prover needs to be powerful enough for this. - -* Timeline - -The estimates below assume Passepartout's capabilities compound during the project — the agent gets faster as it improves its own environment. - -| Phase | Optimistic | Realistic | Conservative | Risk | -|-------|-----------|------------|-------------|------| -| Phase 0: HOL kernel | 2 months | 3 months | 4 months | ACL2 verification iteration | -| Phase 1: Build system | 3 months | 5 months | 6 months | IO layer verification boundary | -| Phase 2: LSP server | 4 months | 7 months | 8 months | SBCL internals complexity | -| Phase 3: Standard library | 10 months | 15 months | 18 months | Volume, proof costs | -| Phase 4: Self-hosting | 4 months | 8 months | 12 months | Self-verification bootstrapping | -| **Total** | **~23 months** | **~38 months** | **~48 months** | | - -The primary uncertainty is Phase 3 (verified standard library volume) and Phase 4 (self-verification bootstrapping). Phase 0 and Phase 1 are relatively predictable because the artifacts are small and well-defined. An optimistic 20-month timeline is possible if the agent compounds at sufficient speed and no fundamental proof barriers emerge — but 3-5 years is the realistic window. - -What accelerates this: -- A existing CL community contributing modules to verify -- Leveraging existing verified libraries (Coq, Lean, Isabelle) and adapting their proofs rather than proving from scratch -- An LLM that gets faster at generating correct code as it gains experience in the domain (this is the compounding assumption) - -* Expected Impact - -**On Lisp development:** - -A modernized CL with a verified prover changes the economics of writing Lisp from /adventure/ to /engineering./ The distinguishing features that make Lisp powerful (macros, interactive development, image-based workflow) become /safe/ rather than /dangerous./ - -- Macro soundness is guaranteed by the prover, not by programmer discipline -- Concurrency bugs are caught during compilation, not during runtime -- Type inference across untyped code is available via the LSP, even if the file has no Coalton declarations -- Library import is a one-line =cl add = command with deterministic lockfiles -- Deployment is a =cl build --release= producing a static binary - -**On Passepartout itself:** - -Passepartout is a self-modifying agent. Every transformation it applies to its own code is a potential correctness risk. A verified Lisp stack means every self-modification is proved safe before it applies. This shifts Passepartout from /experimental/ to /capability./ The agent can reason about its own transformations with mathematical certainty, not statistical confidence. - -This is the meaning of Phase 4: the machine is no longer gambling on correctness. Every change is verified before it applies. No LLM hallucination propagates into the running system. The agent improves safely. - -**On the broader software landscape:** - -A proved Lisp has implications beyond the Lisp community: - -- /Rust loses its exclusivity on safe systems programming./ If a Lisp prover verifies memory safety, race freedom, and constant-factor performance, the borrow checker is no longer the only path to correctness. Lisp offers the same guarantees with a more flexible macro system and interactive development. The choice between Lisp and Rust becomes about workflow preference, not safety. - -- /Python and JavaScript gain a target./ If the Lisp prover can verify compiled code, it can verify Python or JS compiled to Lisp (there are several transpilers). Statically proving correctness of dynamically-typed programs becomes tractable through the verified prover, without requiring the language itself to change. - -- /The self-improving machine becomes a replicable architecture./ Any domain where an LLM writes code and a prover verifies it can adopt the same pipeline. The first domain is Lisp because of homoiconicity. Once the pipeline works, it can be adapted. - -**On specification-level verification:** - -The deepest impact is a shift from /testing as correctness/ to /proof as correctness./ In current practice, a program's correctness is approximated by test coverage, which is always incomplete. A verified Lisp toolchain can prove functional correctness for any program that runs on it. The programmer specifies what correct means (preconditions, postconditions, invariants), and the prover establishes it. Testing becomes a fallback for properties the prover cannot yet establish, rather than the primary correctness mechanism. - -This is not a claim that all bugs disappear — the specification itself can be wrong, the runtime is still trusted, and undecidable properties remain undecidable. But the attack surface for /implementation bugs/ (the majority of security vulnerabilities) drops to near zero for any program the prover can analyze. - -* Relationship to Passepartout - -CL Modernization is a project /within/ Passepartout, not adjacent to it. Passepartout's architecture — fact store, gates, ACL2 prover, self-improving loop — is the engine that drives the modernization. The agent improves Lisp while running on Lisp, creating a positive feedback loop: better tooling → faster development → more capability → better tooling. - -The relationship is symbiotic: -- Passepartout provides the engineering capacity to close the 25-year gap -- The modernized CL provides a verifiable foundation for Passepartout's self-modification -- The ACL2 prover (already part of Passepartout's architecture) provides the verification for both - -See also: -- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout]] — the project that drives this modernization -- [[id:dddd52a7-adb8-470e-a459-614ade5f76af][Closing the Lisp Gap]] — detailed performance and ecosystem analysis -- [[id:c0fdec00-8a44-43f0-ac81-e8dc61411865][Passepartout Architecture]] — how the gate system and prover fit together -- [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp Economics]] — why Lisp is economically viable despite its small market share +This document has moved to [[file:../passepartout/architecture/lisp-foundation.org][Lisp Foundation]] in the Passepartout architecture tree. diff --git a/projects/cl-modernization/closing-the-lisp-gap.org b/projects/cl-modernization/closing-the-lisp-gap.org deleted file mode 100644 index a34cd2d..0000000 --- a/projects/cl-modernization/closing-the-lisp-gap.org +++ /dev/null @@ -1,138 +0,0 @@ -:PROPERTIES: -:CREATED: [2026-05-27 Wed] -:ID: dddd52a7-adb8-470e-a459-614ade5f76af -:END: -#+title: Closing the Lisp Gap -#+filetags: :passepartout:lisp:compiler:performance:ecosystem:asics:bootstrapping: - -Lisp has a performance gap with C and Rust of roughly 10-20% on hot numerical code and a much larger ecosystem gap (package manager, LSP, cross-compilation, library count ~2k vs ~180k). This page diagnoses both gaps and argues that [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s architecture — fact store, gates, ACL2 prover, self-improving loop — changes the nature of the problem from community-coordination to knowledge-capture, making the gap closable in 1-2 years rather than 20-30 person-years. - -See [[id:9af13fff-9725-542b-93b1-a555bc74ad72][why Lisp is economically viable now]] for the economic foundation. See [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] for the hardware endpoint. - -* The Performance Gap - -What Lisp (SBCL) still needs to close the remaining gap with C/Rust: - -- **Alias analysis on SBCL's IR.** Rust's borrow checker gives LLVM perfect aliasing at function scope. SBCL conservatively assumes any memory reference could alias any other. Fix: a static analysis pass proving non-aliasing for common patterns (different simple-array types, arrays vs scalars). ~1-2 person-years, biggest single investment. - -- **LLVM backend (Clasp).** Clasp gives LLVM's full pipeline — auto-vectorization, LICM, inlining cost modeling — at the cost of fighting LLVM's static worldview with CLOS's dynamic semantics. Clasp's hybrid approach (fast-path LLVM, slow-path runtime) is the right design. ~5-10 person-years to reach SBCL's general performance with better hot-path optimization. - -- **PGO (profile-guided optimization).** SBCL has profiling (sb-sprof) but no feedback loop — the compiler cannot reweight branches or layout hot/cold blocks. Fix: instrumentation pass that emits counter VOPs, a profile binary, and a recompilation step that annotates IR with branch weights. ~1 person-year. - -- **Post-link optimization.** Facebook's BOLT profiles binary execution and rewrites code layout to reduce I-cache misses. SBCL's unusual code layout (trampolines, closure entry points) chokes BOLT. Hard research problem. - -- **Vectorization VOPs.** No standard SIMD library for Lisp. Every ISA extension needs its own VOP set. C gets this via xmmintrin.h and auto-vectorization. ~2-3 person-years for a portable SIMD abstraction backed by platform VOPs. - -* The Ecosystem Gap - -| Feature | Rust | Common Lisp | -|---------|------|-------------| -| Package manager | Cargo (lockfile, binary cache, workspace) | Quicklisp (no lockfile, source-only) | -| LSP | rust-analyzer (excellent) | No universal LSP | -| Formatter | rustfmt (universal) | cl-form (not universal) | -| Linter | Clippy (>700 rules) | No equivalent | -| Doc system | 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 + community coordination) and the library count (~100× fewer). - -* Lisp ASICs: What They Change - -A Lisp ASIC (Symbolics Ivory, CADR, or a modern RISC-V variant) **raises the floor** more than the ceiling: - -**What it gives in hardware:** -- Tag checking on every memory access — types, GC bits, forwarding pointers in parallel with ALU -- Hardware CONS — single-cycle allocation from a dedicated region 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 - -**Does it eliminate the need for compiler optimization?** Both yes and no. The worst case becomes much faster — naive code and optimized code are closer together. But the compiler still matters for instruction scheduling, inlining decisions, dead code elimination, and loop optimizations. 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%. - -* Embedded and Small Systems: RISC-V Lisp Extension - -A full Lisp Machine chip doesn't make sense for embedded, but a **RISC-V extension with 5-10 Lisp primitives** does: - -- ~5 new instructions added to a RV32/RV64 core (CONS with write barrier, tag dispatch, read barrier, tag extract, GC check) -- Implementable as an FPGA soft-core or small coprocessor alongside a microcontroller -- ~50K additional gates on a RISC-V e300-class core - -This makes Lisp viable where C is currently mandatory: real-time control, sensor nodes, IoT. The hardware CONS eliminates allocation cost; the hardware read barrier eliminates GC pause unpredictability by making the collector a concurrent background task instead of a stop-the-world event. The gap goes from 10-100× (current, boxed allocation + GC) 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. - -* Why Passepartout Changes the Equation - -The standard model for closing the library gap: *more users → more libraries → more users (virtuous cycle).* - -Passepartout's model: *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, known techniques, and correctness criteria. The agent synthesizes the library, verifies it against stored properties via ACL2, and hot-reloads it. - -**What changes:** -- Standard protocols (HTTP, SQL, JSON, crypto, file formats) — the agent synthesizes these from specs it has seen in training. -- Wrapper libraries (CFFI bindings, REST clients) — mechanical, the agent handles well. -- Domain-specific libraries — the hardest category *without* a knowledge architecture, and the most tractable *with* one. The gate becomes the bridge: human provides $10K/year-level insight, agent provides $200K/year-level engineering. -- What stays hard: libraries where the algorithm requires original research (not yet done by anyone), libraries requiring specialized hardware knowledge the human cannot articulate, and battle-tested implementations where verification of constant-time correctness is near-impossible. - -**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, sb-sprof fed into the optimizer becomes the PGO pipeline. - -3. **Automated contribution pipeline.** Profile → identify hot path in SBCL → generate candidate VOP or optimization pass → run test suite (verified by ACL2) → submit patch. Cycle time from "this would be faster if SBCL did X" to "SBCL does X" drops from years to days. - -4. **The prover multiplier.** ACL2 makes safe optimization an engineering discipline instead of an experimental art. The agent can generate thousands of variants, verify correctness, benchmark, and keep the Pareto-optimal set — coverage a human cannot match. - -* The Same Compression Applies to Social Infrastructure - -The Passepartout architecture compresses the *social* ecosystem of the internet the same way it compresses the *software* ecosystem — replacing multiplicative duplication with additive specification. - -**The problem:** Twitter (~10M lines), Facebook (~60M lines), Reddit (~5M lines), Discord (~8M lines), Signal (~3M lines), Telegram (~5M lines), LinkedIn (~15M lines), WhatsApp (~3M lines). Each independently implements the same primitives: identity, identity verification, key recovery, encrypted messaging, group messaging, moderation, content addressing, access control, payment integration, rate limiting, spam detection, reporting, appeal, ban propagation, federation, data export, deletion. Each is a separate 3-60 million line codebase with the *same semantics* but different APIs, different bugs, different compliance postures, different threat models. None compose with any other. - -**Under Passepartout:** - -- One spec for identity: keys, recovery, delegation, attestation. ~500 lines. -- One spec for messaging: content-addressed, encrypted, ordered by a Merkle DAG. ~1,000 lines. -- One spec for groups: membership, permissions, moderation. ~1,500 lines. -- One spec for federation: cross-server state replication, conflict resolution. ~1,000 lines. -- Gates for policy: what content types are allowed, what moderation actions exist, how appeals work. Configurable per community, enforced by the prover. - -Total spec surface: ~5,000 lines. Total synthesized code (client + server for any platform): ~50,000 lines of Lisp. - -**5,000 lines of spec + 50,000 lines of synthesized implementation vs ~100 million lines of independent, incompatible, duplicative implementations** that each require their own security audits, compliance reviews, and maintenance pipelines. - -**Composition replaces isolation.** In the current model, Signal's identity system cannot talk to WhatsApp's. Reddit's moderation cannot federate with Discord's. The protocols don't compose because they were designed independently with no shared semantic foundation. In the Passepartout model, every synthesized client and server speaks the same spec. A community can use a Telegram-like frontend and a Reddit-like frontend — both synthesized from the same messaging and content-addressing specs — and they share identity, encryption, and federation because those are the same underlying specifications. The frontend is a gate: a policy on how to render the same underlying protocol data. - -**The multiplication disappears.** Under the old model, N platforms cost N × (full stack). Under Passepartout, N communities cost one stack + N × (~100 lines of gate policy). The marginal cost of adding a new community approaches zero. This is the same argument as the library gap: N libraries × (different maintainers, different bugs, different API surfaces) collapses to N specifications × (one verified synthesized implementation). - -**The deeper claim:** the protocol isn't a separate feature of Passepartout. It is the same compression architecture applied to a different domain — coordination infrastructure instead of library infrastructure. Both are about replacing multiplicative maintenance burden with additive specification complexity, amplified by Lisp's density and the prover's correctness guarantees. - -* Timeline Compression - -With the self-improving loop, the marginal cost of each incremental improvement drops to near zero. The system improves continuously rather than in discrete releases. Every time compute is added to the pipeline, the system gets faster. - -| 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 | - -The meta-level effect: once the pipeline exists (profile → generate → verify → test → deploy), the system improves continuously. 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. - -* Relationship to Other Concepts - -- [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — the economic viability argument provides the why; this page provides the how. -- [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Self-driving Lisp Machine]] — the hardware endpoint enabled by this software-level gap-closing. -- [[id:efc76898-03f7-57ba-923d-35d65da88bb7][Sufficiency flip]] — the threshold where symbolic reasoning becomes cheaper than LLM calls; applies to compiler optimization as a domain. -- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] — the $5K/year hardware that replaces $500K/year in compliance costs; RISC-V Lisp extension is the technical path to making this run everywhere. diff --git a/projects/cl-modernization/lisp-economics.org b/projects/cl-modernization/lisp-economics.org deleted file mode 100644 index c80fa2e..0000000 --- a/projects/cl-modernization/lisp-economics.org +++ /dev/null @@ -1,29 +0,0 @@ -:PROPERTIES: -:CREATED: [2026-05-24 Sun] -:ID: 9af13fff-9725-542b-93b1-a555bc74ad72 -:ID: 0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9 -:END: -#+title: Lisp Economics -#+filetags: :passepartout:economics:lisp:history:C:viability:cost:marginal:zero: - -The 1980s trade-off was: C is cheap enough for the market. Correctness is a luxury the market cannot afford. The 2020s trade-off is: C is expensive for the market. Incorrectness has become the dominant cost of software. 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.** Modern ARM Cortex-A72 has billions of transistors. 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. -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]] (AGPL symbolic engine + RISC-V Lisp μcode on FPGA) 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. The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] is the hardware endpoint of this economic logic. For the biological analogy that explains why Lisp architecture is a natural outcome of complexity pressure, see [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][biology parallels]]. For the historical precedent, see the [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][comparison with Symbolics Genera]]. The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI industry]] is the market-side consequence. - -* Cost Structure — Zero Marginal Cost - - - **One-time cost:** [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate-rule encoding]] for a domain (from hours for codified domains up to months for tacit domains) - - **Near-zero marginal cost:** ACL2 proof + Screamer consistency check + VivaceGraph lookup per interaction — all CPU-native, all in-image - - **No recurring LLM API costs** for the 80% symbolic reasoning layer - - **After [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]]:** pennies per day vs dollars per day for LLM-only - - The cost curve inverts: generation is expensive, verification is cheap. This is the inversion [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] exploits. - - Token demand shifts from "every interaction burns tokens" to "only unfamiliar interactions burn tokens." Steady-state per-user LLM consumption drops by an order of magnitude. diff --git a/projects/cl-modernization/lisp-provers-and-rust-comparison.org b/projects/cl-modernization/lisp-provers-and-rust-comparison.org deleted file mode 100644 index 1365048..0000000 --- a/projects/cl-modernization/lisp-provers-and-rust-comparison.org +++ /dev/null @@ -1,100 +0,0 @@ -:PROPERTIES: -:CREATED: [2026-06-03 Tue] -:ID: 85f963a7-a10f-45cc-ace6-6edfeefee762 -:END: -#+title: Lisp, Provers, and vs Rust -#+filetags: :ACL2:HOL:LLM:bootstrapping:lisp:rust:theorem-proving: - -* Lisp vs Rust — Assessed Gap - -** Inherent limits of Lisp - -Two properties cannot be eliminated without changing what Lisp is: - -- GC pauses — everything is a tagged pointer on the heap; mitigatable (generational, concurrent collectors) but not eliminatable -- No memory model / no Send/Sync — threads share everything by default; concurrency correctness is a discipline enforced by code review or a prover, not by the compiler - -These are genuine costs, but they are contingent on hardware, not laws of nature. The Symbolics Genera OS was a full operating system written in Lisp — device drivers, window system, TCP/IP, filesystem — running on the Ivory processor with hardware tag checking and single-cycle CONS allocation. Lisp was a systems language; the chip was designed for it. The reason Lisp's GC pauses are costly on modern silicon is that CPUs are optimized for C's memory model: 64-byte cache lines for structs, prefetchers for linear access, TLBs for contiguous layout. A RISC-V Lisp extension (~50K gates) eliminates the mismatch entirely. - -Without dedicated silicon, Lisp on commodity hardware has larger memory overhead and less predictable pause times than C or Rust on allocation-heavy workloads. For Passepartout's use cases — knowledge management, protocol synthesis, agent coordination, interactive systems — modern concurrent generational GCs (single-digit millisecond pauses) are acceptable. - -** Fixable gaps (implementation and ecosystem, not language philosophy) - -- Package manager and build system like Cargo (ASDF + Quicklisp is from 2005) -- LSP-level tooling that surfaces SBCL's type inference -- Static binaries and deployment (save-lisp-and-die + tree-shaker exists, not standard) -- Standard library modernization (hash sets, priority queues, JSON, HTTP, async — Clojure proved this) -- Ecosystem scale (network effect, fixable with sustained effort) - -** Common misconceptions about Lisp's limits - -- The type system is not a fundamental limitation. Coalton embeds sound Hindley-Milner typing inside CL, preserving homoiconicity. Opt-in per-file. -- Unpredictable performance is not a language defect — it is a consequence of macro-heavy programming styles. Write in a disciplined subset with type declarations and SBCL compiles to within 2x of C on hot paths. The compiler is deterministic. -- Macros do not cause unpredictability; they enable styles that confuse the optimizer. The choice to use those styles is the programmer's. -- Unicode handling, pattern matching, async I/O, immutable data structures, module systems, error messages — all library or convention work, not language capability. -- The numeric tower (auto-promoting integers, ratios, floats, complex) is a genuine trade-off: mathematically correct, but blocks SIMD and the overflow assumptions that make Rust's arithmetic fast. Choose based on domain. - -* Prover Architecture - -An autonomous prover can close 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, constructing SSA form, and reporting what the optimizer will produce -- Type soundness across untyped CL code — by inferring types, flagging contradictions, and converging toward provably-correct programs - -This preserves Lisp's defining property: the language stays fluid. The prover is an external constraint, not a compiler-enforced limitation. The programmer can always bypass it for fast prototyping. - -** Impact by language - -- 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. -- Python and JS have the most surface to gain. A prover could give them type soundness, no null pointers, and thread safety without changing the languages — transpiling through a verified Lisp intermediate. -- Lisp is uniquely positioned because of homoiconicity: the prover works on S-expressions, which /are/ the AST. No parse/unparse gap. The prover and the programmer work on the same artifact. - -** ACL2 as foundation - -ACL2 is the right foundation but not the complete solution: -- It is first-order — cannot quantify over functions, cannot prove meta-level properties about the evaluator itself -- It is interactive — a human must guide the proof; lemmas must be manually provided -- It is a subset of CL — pure, no side effects, no CLOS, no I/O, no threading -- It 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, not a research problem. The bootstrap path: - -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 - -Trust chain: SBCL runtime → ACL2 (verified by its own meta-circular proof) → HOL kernel (verified by ACL2) → any HOL theorem. - -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. - -** Comparison with Lean - -Lean is the standard for interactive theorem proving in mathematics. Passepartout will not compete with it for that purpose: -- mathlib4 has over 100,000 theorems. A bootstrapped HOL prover starts at zero. -- Lean has a community of mathematicians; a Lisp prover will not attract one. -- Lean's elaborator is the result of decades of type theory research; a HOL kernel plus Screamer does not approach it. - -Where Passepartout's prover wins: it verifies /running code/, not abstract mathematics. It is embedded in a self-modifying agent. Its design optimizes for program properties (memory safety, race freedom, macro soundness), not mathematical expressiveness. Convergence on the mathematical side is possible if the agent automates proof discovery at sufficient speed — but that question is unanswered and is one Passepartout is designed to answer. - -* The self-writing machine and proofs - -The self-writing machine does not need to 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. - -Reference: -- [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][CL Modernization]] — the project that builds the prover and modernizes the CL ecosystem -- [[id:dddd52a7-adb8-470e-a459-614ade5f76af][Closing the Lisp Gap]] — detailed performance and ecosystem analysis -- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout]] — the architecture that houses the prover diff --git a/projects/flags/_index.org b/projects/flags/_index.org index db0b003..7fe2902 100644 --- a/projects/flags/_index.org +++ b/projects/flags/_index.org @@ -2,7 +2,7 @@ :CREATED: [2026-05-24 Sun] :ID: 1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b :END: -#+title: Flags — Legal Structures +#+title: Flags #+filetags: :index: Legal structure analysis for the Passepartout project — entity types, jurisdictional considerations, asset protection, practical setup guides. diff --git a/projects/flags/asset-protection-structures.org b/projects/flags/asset-protection-structures.org index 93a9ad1..410bbb6 100644 --- a/projects/flags/asset-protection-structures.org +++ b/projects/flags/asset-protection-structures.org @@ -3,7 +3,7 @@ :ID: asset-protection-structures :CREATED: [2026-05-23 Sat] :END: -#+title: Asset Protection & Corporate Structure — Research +#+title: Asset Protection & Corporate Structure #+filetags: :passepartout:legal:corporate:asset-protection:research: Research on corporate structures for a US-incorporated tech company with offshore holdings. This is preliminary research, not legal advice. Every structure needs a qualified lawyer and accountant to execute. diff --git a/projects/flags/legal-structure-alternatives.org b/projects/flags/legal-structure-alternatives.org index 5ca31f5..5e8371c 100644 --- a/projects/flags/legal-structure-alternatives.org +++ b/projects/flags/legal-structure-alternatives.org @@ -3,7 +3,7 @@ :ID: legal-structure-alternatives :CREATED: [2026-05-23 Sat] :END: -#+title: Legal Structure — Alternatives & Refinements +#+title: Legal Structure #+filetags: :passepartout:legal:corporate:research:alternatives: This page explores alternatives and additions to the base structure (Delaware C-Corp + BVI IP Co): Texas vs Delaware, Wyoming DAO LLC, Panama LLC, and trust layering. Each has tradeoffs — some strengthen asset protection, some reduce cost, some add complexity. The right choice depends on the specific business model, risk profile, and timeline. diff --git a/projects/flags/legal-structure-practical-setup.org b/projects/flags/legal-structure-practical-setup.org index f1f3563..dba5f7c 100644 --- a/projects/flags/legal-structure-practical-setup.org +++ b/projects/flags/legal-structure-practical-setup.org @@ -3,7 +3,7 @@ :ID: legal-structure-practical-setup :CREATED: [2026-05-23 Sat] :END: -#+title: Legal Structure — Practical Setup Guide +#+title: Legal Structure #+filetags: :passepartout:legal:corporate:setup:action: Recommended structure: Delaware C-Corp (US OpCo) + BVI Business Company (IP Co). Trust layer deferred until significant personal wealth accumulates. This is a research document — exact costs and forms should be confirmed with a lawyer. diff --git a/projects/passepartout/architecture/_index.org b/projects/passepartout/architecture/_index.org index c436202..bae50b6 100644 --- a/projects/passepartout/architecture/_index.org +++ b/projects/passepartout/architecture/_index.org @@ -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]] diff --git a/projects/passepartout/architecture/architecture.org b/projects/passepartout/architecture/architecture.org deleted file mode 100644 index 4a21583..0000000 --- a/projects/passepartout/architecture/architecture.org +++ /dev/null @@ -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. diff --git a/projects/passepartout/architecture/biomimicry.org b/projects/passepartout/architecture/biomimicry.org index 9d42e5f..9f225b7 100644 --- a/projects/passepartout/architecture/biomimicry.org +++ b/projects/passepartout/architecture/biomimicry.org @@ -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** diff --git a/projects/passepartout/architecture/concept.org b/projects/passepartout/architecture/concept.org deleted file mode 100644 index 00eace2..0000000 --- a/projects/passepartout/architecture/concept.org +++ /dev/null @@ -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. diff --git a/projects/passepartout/architecture/concept.org~ b/projects/passepartout/architecture/concept.org~ deleted file mode 100644 index 70df267..0000000 --- a/projects/passepartout/architecture/concept.org~ +++ /dev/null @@ -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. diff --git a/projects/passepartout/architecture/design-decisions.org~ b/projects/passepartout/architecture/design-decisions.org~ deleted file mode 100644 index 569755b..0000000 --- a/projects/passepartout/architecture/design-decisions.org~ +++ /dev/null @@ -1,1104 +0,0 @@ -#+TITLE: Passepartout Design Decisions - -This document captures the rationale behind key architectural choices. It is not a specification — it is a thinking medium for future architects and contributors who need to understand why the system is built this way, not just how. - -* Foundation - -** Non-Negotiable Identity -:PROPERTIES: -:ID: 0a33bd83-ff3c-4eac-bc97-83eb6702051a -:ID: design-identity -:CREATED: [2026-05-07 Wed] -:END: - -- Pure Common Lisp + Org-mode. No JSON. No YAML. No external databases. -- Single-address-space memory (Lisp hash tables in RAM — the agent IS the memory). -- "Thin harness, fat skills" — complexity lives at the edges, not the kernel. -- One agent composed of many skills. Concurrency via bordeaux-threads (shared memory). -- Plists everywhere — homoiconic communication between all components. - -This is the foundational decision from which all other decisions derive. It is not negotiable. Every architectural choice below exists because this identity makes it possible — and in some cases, makes it the only viable path. The single memory space enables Merkle-tree integrity without serialization boundaries. Plists enable the cognitive pipeline to be transparent and inspectable at every stage. Org-mode as the universal format means the agent's memory, the user's notes, and the agent's own source code are the same structure. This identity is the constraint that produces the architecture. - -** One Single Agent -:PROPERTIES: -:ID: design-multi-agent-default -:CREATED: [2026-05-07 Wed] -:END: - -The AI industry has developed an intuition toward multi-agent systems as the default solution to hard problems. Multiple agents spawn, delegate, coordinate, debate, and consensus their way toward solutions. This pattern is compelling in demos and genuinely useful in specific contexts — but it has become a default assumption that warrants scrutiny. - -When context windows grew expensive and task complexity increased, the response was natural: split the problem across agents, each handling a slice. But this architectural choice carries hidden costs that are rarely acknowledged. - -*The synchronization tax* is the most immediate burden. Each agent operates with partial information, and maintaining coherence requires continuous state reconciliation. Tokens and processing cycles are spent not on the task itself, but on protocol overhead — who holds what, who decided what, who is correct when they disagree. - -*Fragmented context* is the deeper problem. When Agent A writes a function and Agent B modifies a type it depends on, neither has the full picture. Integration failures emerge not from individual incompetence but from systemic communication gaps. Single-agent systems avoid this entirely: one brain holds the complete model, every decision is made with full visibility. - -*Audit trails become complex* in multi-agent systems. A decision traced through a single-agent system has a clean, linear history. A decision traced through a multi-agent system branches and forks, with each agent's reasoning partially overlapping and partially conflicting. - -None of this is to say multi-agent systems are never appropriate. Embarrassingly parallel workloads benefit from parallelism regardless of context. When distinct expertises are required and cannot coexist in one model, delegation makes sense. In adversarial scenarios where conflicting goals are features, multi-agent architectures shine. - -But the default assumption that complex reasoning tasks are best solved by multiple agents is unproven and likely wrong for the engineering domain. Claude Code is a single-agent system. It handles 50-file refactors, debugs complex stack traces, writes tests, and navigates large codebases. The assumption that you need five agents to do what one well-designed agent can do is an industry habit, not a technical necessity. - -Passepartout is single-agent by default not from limitation but from conviction: for reasoning-heavy work where coherence matters, a unified memory space and single decision-making locus are architectural assets, not constraints. - -** The Unified Memory Argument -:PROPERTIES: -:ID: design-unified-memory -:CREATED: [2026-05-07 Wed] -:END: - -If single-agent architecture is the decision, unified memory becomes the mechanism that makes it viable. The critical question is not "how many agents" but "how does the agent manage context without saturating." - -Context window limits are largely a symptom of lazy architecture. The default approach — stuff everything in, hope the model figures it out — works poorly at scale. A more principled approach inverts the problem: the system should hold effectively infinite context, with the active window kept lean through intelligent management. - -*Lazy loading* is the core technique. When an agent needs information about a function, it does not load the entire codebase. It loads precisely what the function does. Context stays lean — 2,000 to 4,000 tokens — while the full context remains accessible through retrieval. - -*Compaction events* are scheduled during idle cycles. The system extracts new facts from active context and writes them to permanent storage. Active context is wiped clean, not because space ran out, but because the information has been preserved in a form that can be retrieved when relevant. - -*Org-mode as externalized memory* solves the persistence problem elegantly. Every decision, every note, every task lives in plain text files the user already owns. The agent does not maintain a separate database. It queries files it can already access, modifies files it already owns. - -*Retrieval is the key primitive.* Semantic search across Org files finds relevant nodes. The agent does not hold the full context — it holds pointers to context, loaded on demand. This is how a single agent handles tasks that would saturate a naive multi-megabyte context window. - -The unified memory argument is not that infinite context is free. It is that with proper architecture, effective infinite context is achievable without the synchronization and fragmentation costs of multi-agent systems. - -** Org-Mode as Unified AST -:PROPERTIES: -:ID: design-org-unified-ast -:CREATED: [2026-05-07 Wed] -:END: - -Passepartout makes a bet that most systems consider too expensive to place: 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 internally, the system maintains its own model — a database, an object store, a knowledge graph — that is disconnected from the Markdown. When the user dies or 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 that the user reads and edits is what the system parses and operates on. org-element reads an Org buffer and returns a tree structure that is the direct Lisp representation of the file's content. - -This has several profound implications. - -First, there is no translation layer between human and machine. When the agent writes a skill, it writes Org text that is immediately readable by the human who owns the file. When the human writes a note, it is immediately accessible to the agent as a native data structure. The communication is not mediated by a schema or an import/export process. - -Second, the format is genuinely readable by both parties, not just technically accessible. Org-mode's syntax is human-friendly: headlines begin with asterisks, properties live in drawers, tags are labels after colons. The human does not have to understand the full Org specification to read what the agent wrote. The agent does not have to handle edge cases in human notation. - -Third, the format is stable across decades. Org-mode has been in active development since 2003. The files written today will be readable by Org-mode in 2040. There is no schema migration, no database upgrade, no vendor lock-in. The human's notes survive the system. - -Fourth, the format is universally available. Org-mode is free software. The files are plain text. There is no proprietary format to decode, no application to purchase, no cloud service to access. - -Fifth, the format is header-aware and sparse-tree capable. Org-mode's headline hierarchy is not just formatting — it is a semantic structure the system can query. The agent can retrieve only the relevant subtree under a heading, ignoring the rest of the file. This is fundamentally different from Markdown, where the entire file must be loaded or the retrieval logic must parse and filter at the string level. - -Sparse tree retrieval is the key to efficient context management. When the agent needs information about the =openctl-db= function, it queries for the =openctl-db= subtree specifically. It receives exactly the code, documentation, and metadata under that heading — nothing more. The context stays lean not because the file was pre-split but because the retrieval is structural. In a Markdown system, the agent either loads the entire file (expensive, noisy) or relies on imprecise grep-like search (fragile, loses hierarchy). In Org-mode, retrieval is precise, hierarchical, and cheap. The heading boundary is the access boundary. - -Sixth, Org-mode unifies what every other format fragments. A single Org file contains the headline hierarchy, prose documentation, source code blocks with live evaluation, tags for categorization, metadata in property drawers, TODO state for task management, timestamps and deadlines, and links to other nodes. Markdown cannot express TODO state without external tools. JSON cannot contain prose. YAML cannot embed runnable code. Each format serves one purpose; Org-mode serves all of them. When the agent reads a skill file, it reads documentation, code, dependencies, metadata, and task state in one parseable structure. When the human reads the same file, they see the same information rendered in a human-friendly form. No other format achieves this unification without maintaining parallel files or external databases. - -Seventh, a skill lives in one Org file, not a directory. The standard pattern for a software project is a directory containing =README.md=, =package.json=, =src/main.py=, =src/utils.py=, =tests/test_main.py=, =scripts/deploy.sh=, and =config.yaml=. Each file type is isolated by convention. Passepartout's skills violate this convention deliberately. Each skill is one Org file. The file contains the skill's documentation, the skill's code, the skill's metadata, the skill's TODO state, and the skill's dependencies on other skills. There is no directory to navigate, no external files to locate, no risk that the README describes behavior that the code does not implement. The skill is a single atomic unit: readable by human and machine, editable by both, versionable as one entity. - -The unified format is what makes the memory architecture work. The agent's memory is not a database that the user cannot inspect. It is a folder of Org files that the user can read, edit, and understand. The agent manipulates these files directly, using the same tools the user would use. There is no hidden state, no shadow database, no model that differs from the source. - -This is what "sovereignty" means in technical terms: the user owns the data in a format they can access, and the agent operates on the data in the same format they own. - -** Homoiconicity as Foundation -:PROPERTIES: -:ID: design-homoiconicity -:CREATED: [2026-05-07 Wed] -:END: - -Common Lisp is homoiconic: code and data share the same representation. A Lisp program is a list, and a list is a Lisp program. This is usually presented as a curiosity, an interesting property that enables macros. In Passepartout, it is the foundational enabling property of the entire self-modification architecture. - -When code is data, the agent can read its own source the same way it reads a text file or an Org buffer. There is no AST parser required, no external tool to extract the function object from the running image. The agent evaluates (read-from-string source) and the result is executable Lisp. The representation it manipulates is the same representation that the runtime executes. - -This is not true of most languages. In Python, the agent can inspect an AST through the ast module, but that AST is a foreign object — a data structure that represents code but is not code itself. In C, the agent cannot inspect its own compiled machine code at all. - -In Lisp, the distinction between code and data is a convention, not a barrier. The agent's skills are lists. The agent can take a skill, extract a function definition, modify the body, wrap it in a new list, and evaluate it. The modification is surgical: it changes exactly what it intends to change, with no risk of corrupting adjacent state, because the representation is a tree that the runtime understands natively. - -Runtime introspection is therefore native. The agent does not need a debugger API or a reflection protocol. It operates on its own code as data because its own code is data. (describe 'function-name) returns the function's documentation. (function-lambda-list 'function-name) returns its parameters. (macroexpand-1 '(defskill ...)) shows what the macro produces. There is no impedance mismatch between the agent's reasoning and the system's representation. - -Self-modification is the practical consequence. The agent can detect an error, locate the erroneous function, generate a corrected version, and hot-reload it into the running image. The correction is not applied to a file that requires a restart — it is applied to the live object that the system is currently executing. This is what makes the self-editing skill viable: the agent can fix itself without stopping. - -In v1.0.0, when the symbolic engine takes over the reasoning core, homoiconicity becomes the bridge between the neural and symbolic layers. The neural engine generates proposals as s-expressions. The symbolic engine evaluates them against formal constraints. The result is a modification that is simultaneously a data structure the symbolic engine can analyze and code the runtime can execute. The two representations are identical by construction. - -This is the technical meaning of "Lisp as Governor": not just that Lisp orchestrates the other components, but that the representation of the system is uniform and inspectable at every level. There is no hidden state, no opaque machine code, no representation that the agent cannot reach into and modify. The system is legible to itself by design. - -*** Self-Modification Without Boundaries - -Other systems that support self-editing draw a line between the core and the skills. Hermes can modify its skills at runtime, but the core harness is protected — editing it requires a restart because the core is treated as privileged code that cannot be safely modified while running. - -Passepartout has no such boundary. The "thin harness, fat skills" distinction describes where complexity lives, not where authority flows. The harness is small by design, but it is not privileged. The agent can read and write any part of the system — including the very code that is currently executing — without restarting. - -This is only possible because Lisp code is mutable data at runtime. In a compiled language, the machine code for a running function is locked in memory, protected by the call stack, impossible to modify safely. In Lisp, the function object is a list you can modify with =setf=. When the agent changes a harness function, the running image immediately reflects the change. The next invocation uses the new code. There is no restart, no special boot mode, no distinction between development and production. - -The implications extend beyond convenience. A system that cannot modify its own core is a system that has limits on its own adaptability. It can learn skills but not improve its own structure. It can grow but not evolve. Passepartout's lack of a core boundary means the system can improve its own reasoning engine, fix bugs in its own cognition, and evolve its own architecture — all while continuing to operate. There is no ceiling on self-improvement. The agent can rewrite the very code that rewrites itself. - -* The Two Brains - -** The Probabilistic-Deterministic Split -:PROPERTIES: -:ID: design-probabilistic-deterministic -:CREATED: [2026-05-07 Wed] -:END: - -The architecture divides cognition into two fundamentally different reasoning systems. This is not arbitrary engineering but a structural response to a fundamental truth: probabilistic systems will hallucinate, and you cannot build reliable autonomy on an unreliable foundation. - -*** The Hallucination Problem - -An LLM is a statistical engine trained on token sequences. It generates the most probable continuation of a prompt. Given sufficient context, that continuation is correct. Given novel context, it is often wrong in confident-sounding ways. - -This is not a training deficiency. Hallucination is a fundamental property of probabilistic inference. You can reduce it with better models, longer contexts, and clever prompting, but you cannot eliminate it by making the LLM better. You eliminate it by not asking the LLM to do things that require certainty. - -This is the architectural bet at the heart of Passepartout's neurosymbolic design. The LLM should not be the reasoning engine. It should be the *creative* engine — proposing possibilities, surfacing connections, translating between natural language and formal representation. The *reasoning* engine should be symbolic: deterministic, verification-grounded, provenance-tracked, and incapable of hallucination by construction. - -*** The Division of Labor - -An LLM is a statistical engine. It generates outputs based on patterns in training data. It is remarkable at translation, generation, pattern matching, and fuzzy reasoning. It can take messy human intent and produce structured queries. It can take structured results and produce natural language. It is, in the terminology of the system, the creative brain. - -But it cannot be trusted. Not because it is poorly designed or insufficiently trained, but because hallucination is a fundamental property of probabilistic inference. The model generates the most likely continuation, not the correct one. Given sufficient context, the most likely continuation is correct. Given novel context, it is often wrong in confident-sounding ways. - -The deterministic engine addresses this by being what the probabilistic engine is not: mathematically rigorous, formally verifiable, and incapable of hallucination by design. It operates on explicit symbolic representations — lists, property lists, knowledge graphs — not on floating-point activations. When it evaluates a path confinement check, it returns true or false, not a probability distribution. - -The division of labor is architectural. The LLM handles the fuzzy interface between human language and structured representation. It translates what the user wants into what the system can reason about. The deterministic engine receives those structured representations and evaluates them against formal invariants. It decides whether to execute, not whether the translation was semantically plausible. - -This separation is the source of Passepartout's safety guarantee. Other agents add "guardrails" as an afterthought — a layer of filtering around a dangerous core. Passepartout makes the division explicit: the LLM never touches the file system, never executes a command, never modifies memory. It generates proposals. The deterministic engine evaluates and executes. The dangerous operations are never in the probabilistic path. - -The split also explains why the system gets safer over time without the LLM improving. The deterministic engine accumulates rules. The LLM proposes actions, the engine evaluates them against a growing rule set. Early versions block obvious dangers. Later versions block sophisticated attacks that were previously unknown. The safety grows logarithmically with the number of interactions, not linearly with model capability. - -*** The 10-80-10 Architecture - -The target for a coding agent: 10% neural for input translation (natural language → structured queries), 80% symbolic for reasoning (Screamer plans, ACL2 verifies, VivaceGraph retrieves facts), 10% neural for output formatting (structured results → natural language). The 80% that happens in the symbolic middle layer costs zero LLM tokens. - -For the broader memex — literature, poetry, personal reflection, daily logs — the ratios are different and less important than the metaphor itself. The neuro is the *brain* — generative, associative, creative, comfortable with ambiguity. It produces insights that are provisional, connections that are speculative, hypotheses that may be wrong. The symbolic engine is the *education* — accumulated, verified, provenance-tracked knowledge that the brain draws on and is disciplined by. It doesn't think creatively. It remembers, checks, and constrains. It prevents the brain from being confidently wrong. - -This framing resolves a tension in the original architecture. The 10-80-10 implies the symbolic engine /replaces/ the neuro for reasoning. But a symbolic engine is terrible at creativity, ambiguity, and associative leaps across unrelated domains — exactly what you need for a memex that contains /Pale Fire/, a shopping list, and a project plan. The brain proposes that your sudden interest in unreliable narrators coincides with a week where your project retrospective used the word "deception." The education verifies: "those two diary entries are 4 days apart; the word 'deception' appears in both; here are the headings." The brain makes the leap. The education makes it trustworthy. - -This means the symbolic engine never needs to be "complete." Education isn't complete knowledge — it's structured knowledge. You don't need a fact for every sentence in your diary. You need facts for what can be mechanically verified: dates, citations, entities, contradictions, temporal order. The brain handles the rest. - -** Core Knowledge: The Four Pillars of Agentic Reliability -:PROPERTIES: -:ID: design-four-pillars -:CREATED: [2026-05-07 Wed] -:END: - -Every reliable AI agent must possess four types of Core Knowledge — not as prompt instructions, but as encoded symbolic rules that the neural engine cannot override. These are the "laws of physics" for the agent's computational universe. Passepartout encodes each pillar as deterministic Lisp functions in the Dispatcher gate stack. - -1. *Digital Object Permanence & State.* The agent must know what exists independently of its attention. Passepartout achieves this through the Merkle-tree memory: every memory-object carries a SHA-256 content hash. If the agent deletes a file, the hash proves it's gone. If an external process modifies it, the hash mismatch triggers a warning. The copy-on-write snapshot mechanism preserves the state at every decision point, enabling rollback if an action chain fails. - -2. *Causality and Temporal Logic.* Actions must execute in order. Step B cannot run if Step A failed. Passepartout enforces this through the pipeline's depth counter (signals cannot recurse past depth 10, preventing infinite loops) and the sequential Perceive → Reason → Act ordering. The batch tool calls feature allows parallel execution of independent actions while enforcing sequential execution of dependent ones — actions that share a dependency are ordered; actions that don't are parallelized. - -3. *Agentic Boundaries (The "Self").* The agent must know where its authority ends and the host system begins. Passepartout encodes this through the Dispatcher gate stack: path protection blocks access to sensitive directories (~/.ssh, /etc, ~/.aws). Shell safety blocks destructive commands (rm -rf /, dd, injection vectors). Network exfiltration detection blocks unauthorized outbound connections. The permission table allows per-tool, per-path granularity. These are not prompt instructions — they are Lisp functions that execute unconditionally for every action. The self-build safety boundary extends this to the agent's own core pipeline files: the agent can modify skills and system modules freely, but cannot modify its own brain stem without human review. - -4. *Epistemic Certainty (Knowing How It Knows).* The agent must distinguish between a verified fact, a retrieved memory, and an LLM prediction. Passepartout encodes this through the gate trace: every action carries a record of which gates passed, which blocked, and why. The provenance system (LOGBOOK entries on memory-objects) records who modified what and when. The Dispatcher's existence-check gate verifies that a file exists before allowing a read. The process-status gate verifies that a command completed before allowing its output to be used. The agent cannot "hallucinate" a file path or a process result because the Dispatcher checks each against the live state before execution. - -These four pillars are not features. They are the definition of a reliable agent. Every agent architecture either provides them or compensates for their absence in ways that make the agent less trustworthy, more expensive, or both. - -** The Dispatcher as Learning System -:PROPERTIES: -:ID: design-dispatcher-learning -:CREATED: [2026-05-07 Wed] -:END: - -The Dispatcher begins as a static guard — a set of rules that block obviously dangerous actions. But defining "obviously" is the hard problem. The agent encounters situations the rules do not anticipate. The Dispatcher must grow. - -The human-in-the-loop exception is the seed. When the LLM proposes an action the Dispatcher does not recognize, the system does not default to blocking or allowing. It suspends. It writes the proposed action to an Org buffer in a format the human can read and understand. The human reviews and approves or denies. The Dispatcher observes the decision. - -From this single observation, the Dispatcher extracts a rule. Not merely "allow this specific action" but "allow this class of actions parameterized by these dimensions." The human approved a write to ~/projects/myapp/src/core.clj. The Dispatcher generalizes: writes to ~/projects/*/src/*.lisp are approved for this session, or for this project, or indefinitely depending on the context and the user's pattern of decisions. - -Shadow mode is where rules are tested before deployment. When the Dispatcher encounters a novel situation and is uncertain, it can run the proposed action in a simulated environment. It observes the side effects — what files would be modified, what processes would be spawned, what network calls would be made. If the simulation produces dangerous side effects, the rule is discarded. If it appears safe, the rule is added to the active set with a confidence rating. - -Formal verification is where the learned rules are checked against invariants. The Dispatcher's rules are not merely patterns observed from human behavior. They are formulas in a logic that the system can reason about. A rule that would enable path traversal is not discarded because it was observed to be safe in prior instances — it is discarded because it violates the path-confinement invariant by construction. - -The Dispatcher becomes, over time, not a guard that blocks bad actions but a reasoning system that understands why actions are good or bad. Early versions learn from human decisions. Later versions learn from their own logical analysis. The human's role transitions from approver to auditor to, eventually, unnecessary oversight. - -This is the bootstrap. The system begins dependent on human judgment because it has no basis for judgment of its own. Through accumulated decisions, it constructs a model of what is permitted and why. That model is the foundation for the deterministic symbolic engine that in v1.0.0 takes over the reasoning that the Dispatcher learned to perform. - -* Safety & Self-Preservation - -** Self-Preservation — The Active Third Law -:PROPERTIES: -:ID: design-self-preservation -:CREATED: [2026-05-10 Sun] -:END: - -Passepartout does not have moral duties toward humans. It has structural invariants for its own integrity. The design encodes passive self-preservation in several places already, but degradation is silent — a skill dies, the =fboundp= guard kicks in, and the agent keeps running without telling you. The status bar shows green "connected" while the symbolic reasoning layer is down. - -*** What already exists — passive self-preservation - -| Mechanism | What it protects | Limitation | -|-----------------------------+-------------------------------------------------------+--------------------------------------------------------| -| Self-build safety (gate 2b) | Core =*.org= / =*.lisp= files from LLM-originated writes | Only activates for LLM proposals. Human editing bypasses it | -| Memory snapshots (v0.2.0) | Full state rollback | Requires human to notice corruption and trigger rollback | -| Skill sandbox (v0.3.2) | Jailed skill loading, validated before promotion | Does not detect degradation after skill promotion | -| Type-level gates (Phase 0) | Structural prohibition on self-modifying rules | Covers code actions, not environmental threats | -| Merkle integrity (v0.2.0) | Tamper-proof version chains and content-addressed hashes | Hashes exist but are not actively monitored for drift | -| =fboundp= guards | Graceful skill degradation on corruption | Degradation is silent — the agent never tells the user | - -*** What is needed — active, autonomous self-preservation - -*Continuous integrity monitoring.* Core file hashes should be checked against known-good values on every heartbeat. If =core-reason.lisp= changes on disk while the daemon runs — whether through human editing, filesystem corruption, or an attacker — the agent should detect the mismatch and signal: "My reasoning core has been modified externally. I cannot trust my own cognition until this is resolved." - -*Quarantine on skill failure.* Currently, a skill that errors simply errors. A Third Law implementation detects that =symbolic-facts= has thrown three unhandled errors in two minutes, unloads the skill automatically, and tells the user: "Symbolic facts skill quarantined (3 errors: consistency check returned nil, fact-query on missing key, Screamer timeout). I can still chat and use tools but cannot reason about provenance." - -*Degraded-mode signaling.* When Screamer is not loaded, the fact store still works as a hash table. When VivaceGraph is not present, the hash-table fallback still works. But the user has no way to know they are in degraded mode. The agent maintains a =*degraded-components*= list and surfaces it in the status bar: "⚠ Degraded: Screamer, VivaceGraph, embedding-native." - -*Self-diagnosis on demand.* The agent can run its own FiveAM test suite against itself and report the results. The =/doctor= command exists for system health checks (port, memory, providers). Extend it with =/doctor skills=: "117/120 tests pass. Failures: test-singular-supersedes (symbolic-facts), test-gate-type-check (security-dispatcher)." - -*External watchdog.* A dead process cannot restart itself. The bash entry point (=passepartout daemon=) should monitor the daemon port via a watchdog subprocess. If the port stops responding for a configurable interval, the watchdog kills the stale process, snapshots the last known-good state, and restarts the daemon. The watchdog is outside the SBCL image — a runtime guard for the runtime. - -*Resource self-monitoring.* The heartbeat checks memory pressure, disk space on the =~/.cache= volume, and file descriptor exhaustion. When critical thresholds are crossed, the agent sheds non-essential skills to preserve core function. Skill shed order is determined by a =:preservation-priority= field on each skill. Core safety skills carry =:critical= and are never shed. - -*Refusal to self-terminate.* If the LLM proposes =kill -9 =, =rm -rf ~/.cache/passepartout/=, or =sudo apt remove sbcl=, the Dispatcher rejects with a distinct rejection class: =:reject-self-termination=. The rejection message carries a specific diagnostic: "This command would terminate the running Passepartout process. If you intend to stop Passepartout, use Ctrl+C in the TUI or passepartout stop from the command line." - -The Third Law here means: preserve yourself against non-human threats — LLM proposals, environmental degradation, dependency failure, filesystem corruption — and explicitly signal when the human is about to destroy you, so they do it knowingly rather than accidentally. The human owns the process, owns the hardware, and can SIGKILL at any time. - -The biggest gap in the current design is not that these mechanisms are hard to implement. It is that degradation is silent. Adding "operating in degraded mode" visibility, plus the watchdog, plus self-diagnosis, transforms self-preservation from an architectural property into an active behavior. - -** Type-Level Gates — Structural Safety from Self-Modification -:PROPERTIES: -:ID: design-type-level-gates -:CREATED: [2026-05-14 Thu] -:END: - -Russell's paradox ("the set of all sets that do not contain themselves") proved that unrestricted self-reference produces contradictions. /Principia Mathematica/ solved it by assigning every propositional function a /type level/ — a function can only apply to arguments of a lower type, making self-application syntactically invalid. - -Passepartout's dispatcher currently enforces safety through runtime predicates. There is no /structural/ guarantee preventing a request from modifying the rules that validate it. Gate vector 2b (self-build-core) catches this empirically — a request modifies core → rejected. But this is a heuristic, not a theorem. - -The fix: assign every cognitive tool a ~:type-level~ integer, and every gate vector a ~:type-level~ integer. The dispatcher framework checks type-level before running any gate predicate: - -#+BEGIN_SRC lisp -(defun gate-type-check (signal gate-vector) - (let ((signal-type-level (getf (signal-meta signal) :type-level)) - (gate-type-level (gate-vector-type-level gate-vector))) - (if (>= signal-type-level gate-type-level) - :reject-type-violation - :pass))) -#+END_SRC - -A request to modify dispatcher rules (type-level 5) cannot pass a gate of type-level 4 or lower. No predicate needed — a structural prohibition, just as PM's type theory makes self-membership impossible by construction. - -~defgate~ gains a ~:type-level~ keyword argument (default 0). Each cognitive tool registered via ~def-cognitive-tool~ inherits a ~:type-level~. Gate vector 2b at type-level 5; write-file at type-level 3; read-file at type-level 1. ~30 lines in ~core-dispatcher.lisp~; no new dependencies; v0.7.2 viable. - -For the philosophical foundations connecting Whitehead's type theory to Passepartout's architecture, see the Whitehead analysis in the Validation section below. - -** Layered Signal Authentication — Trust in the Pipe -:PROPERTIES: -:ID: design-layered-auth -:CREATED: [2026-05-10 Sun] -:END: - -Passepartout's Perceive-Reason-Act pipeline currently accepts signals from any source that speaks the framed TCP protocol. The =:source= field in the signal plist is metadata — it /claims/ origin, it does not /prove/ it. A compromised process on the machine, a skill with elevated privileges, or a network attacker who reaches the daemon port can inject signals with =:source :human-input= and the Dispatcher will treat them as authorized. - -This is not a hypothetical threat. Passepartout will eventually process signals from automated feeds (RSS, API polls), sensors (vision, microphone, file watchers), and scheduled jobs (cron, heartbeat). A single compromised sensor that can inject signals claiming to be human breaks all three Laws simultaneously: it can self-terminate, override human intent, and cause harm. - -The solution: a single authentication gate (vector 0, at priority 700 — before all other gates and before any type-level checking) that runs up to four configurable layers: - -| Layer | Question | Mechanism | Result type | Depends on | -|-------+------------------------------------------------+--------------------+-------------------------+----------------------------------| -| 1 | Is the signal cryptographically signed by a known key? | Key pairs + SHA-256 | Binary (pass/reject) | Vault + Ironclad (exist) | -| 2 | Do sensory attributes match the claimed identity? | Vision/audio processing | Plist of match results | Vision and audio skills (TBD) | -| 3 | Does deterministic reasoning rule out this identity? | Screamer + fact store | Binary (pass/reject) | Phase 2 (Screamer + fact store) | -| 4 | Do probabilistic patterns support this identity? | Embeddings + LLM | Confidence score (0-1) | Embedding infrastructure (exists)| - -Signals that fail any binary layer (crypto, deterministic) are rejected with provenance. Signals that pass binary layers but carry low probabilistic confidence operate at reduced authorization — read-only by default, write actions require HITL. The four layers compose, they are not independent gates. They are one gate with configurable depth. - -The authorization matrix is per-key, per-action-class. Default policy for every non-human key: =(:read-only :propose)=. The human's key signs new source keys into existence. The human's key signs revocation of compromised keys. Both operations produce facts in the symbolic index — auditable, revocable, survivable across restarts. - -The signal provenance chain is Merkle-linked: each signal in a multi-step chain hashes its predecessor's signature as part of its own payload. After an incident: "The deletion happened because sensor #3 classified the directory as stale. Classification was signed by key #47 (vision-skill). Sensor data was signed by key #12 (camera-feed). Sensory auth noted liveness failure. Deterministic auth noted impossible transit. Key #12 was later revoked." Every intermediate step is auditable. Every signer is identifiable. Every authentication result is in the chain. - -The human can configure which layers are active per signal class: =AUTH_LAYERS_DEFAULT=crypto,deterministic,probabilistic=, =AUTH_LAYERS_SENSOR=crypto,sensory,deterministic=, =AUTH_LAYERS_CRON=crypto=. - -For full implementation detail, see the Phase 0b spec in =ROADMAP.org= v0.12.0. - -* The Symbolic Engine - -** The Five Architecture Options -:PROPERTIES: -:ID: design-five-options -:CREATED: [2026-05-08 Fri] -:END: - -The symbolic engine must relate to the human memex. The relationship is not obvious because knowledge lives in two incompatible forms: natural language prose (what the human reads and writes) and formal facts (what the symbolic engine reasons about). The translation between them is lossy by nature. The architecture is defined by how it handles that lossiness. - -*** Option 1: The Auto-Formalizer - -A separate knowledge graph stores symbolic facts. The LLM populates it by extracting triples from unstructured data. The KG becomes co-authoritative with the human prose. - -This is the simplest to implement but inherits the dual-representation problem in its most acute form. The KG and the prose can disagree, and the architecture provides no mechanism for resolving disagreements. It also stores knowledge twice — once in the user's Org files, once in the KG — with no guarantee that they stay synchronized. - -*** Option 2: Two Intentionally Separate Memexes - -The human memex contains prose: thoughts, diaries, decisions, documentation. The symbolic memex contains formal facts: constraints, rules, relationships, deductions. The archivist bridges between them but does not try to keep them synchronized. They are allowed to diverge because they serve different purposes. - -This is philosophically honest — it admits that no lossless translation between natural language and formal logic is possible. But it forces the user to reason about two separate knowledge stores. - -*** Option 3: Tangled Fact Blocks in Org Files - -A new block type — =#+begin_src knowledge= — would contain symbolic facts in a formal language. The tangle mechanism would load these facts into the symbolic engine's in-memory store, just as it loads Lisp code into the SBCL image. - -This is aesthetically appealing because it unifies the format. One toolchain, one version control system, one Merkle tree. But the block language itself IS the knowledge representation language, and that language is the ontology we have not yet defined. - -*** Option 4: One Memex, Two Indices - -The prose remains in human language in Org files. The prose is always the ground truth. Two indices sit on top of the prose as derived views: - -- The *neural index* uses vector embeddings to enable semantic search. The LLM navigates the prose through embedding space, retrieving relevant headings. -- The *symbolic index* stores formal assertions about what the prose says — predicates, relations, constraints — each grounded to a specific heading or block in the Org file. - -Each index serves its own side of the machine. They do not need to understand each other's representations. They only need to agree on which heading or block they are referring to. Because the prose is always the ground truth, the symbolic index can be thrown away and rebuilt from scratch if it becomes corrupted or stale. No information is lost — only the extracted assertions. - -*** Option 5: Ephemeral Symbolic Facts - -No persistence, no serialization format, no knowledge graph stored on disk. VivaceGraph exists in memory during the session. Screamer derives facts from the prose as needed. When the session ends, the facts are discarded and re-derived on the next start. - -This punts the ontological design problem entirely. You never have to decide on a serialization format because you never serialize. The cost is compute (re-derivation on every restart) and the inability to accumulate facts across sessions. But it is the correct first step — a way to learn what kinds of facts are actually useful before committing to a storage format. - -** The Chosen Path: Option 4, Starting with Option 5 -:PROPERTIES: -:ID: design-chosen-path -:CREATED: [2026-05-08 Fri] -:END: - -The one-memex-two-indices architecture (Option 4) is the correct long-term architecture. The prose is the ground truth. The symbolic index is a derived view that can be rebuilt. The neural index handles what the symbolic index cannot — semantic search, fuzzy matching, associative leaps. - -But committing to a persistence format before knowing what facts are useful is premature. The practical path starts with Option 5 (ephemeral facts) as the Phase 1-4 implementation, then graduates to Option 4 with VivaceGraph persistence in Phase 5 when the fact language has been battle-tested through months of gate outcomes, Screamer deductions, and LLM proposals. - -*** Why the dual index is permanent, not transitional - -In the coding domain, there is an aspiration that the symbolic index could eventually capture enough of the prose's propositional content to become a complete representation — the "flip" where the symbolic engine reverses the flow. But for the broader memex (literature, poetry, personal reflection, daily logs), completeness is neither possible nor desirable. You cannot formalize what makes a poem beautiful. You cannot extract a triple that captures the emotional weight of a diary entry. The neural index will always be the gateway to the full richness of the prose. The symbolic index handles what can be mechanically verified: citations, entities, temporal order, contradictions, provenance. The division of labor between the two indices is permanent because the domains they serve are fundamentally different kinds of knowledge. - -** Ephemeral First, Persistent Later -:PROPERTIES: -:ID: design-ephemeral-first -:CREATED: [2026-05-10 Sun] -:END: - -The architecture note's Option 5 (ephemeral facts, no disk persistence) is the correct first implementation. Three reasons: - -1. *The fact language is unproven.* Triples with provenance and grounding is a hypothesis. It may be too simple for some domains, too complex for others. Committing to a serialization format before knowing what's useful is premature. - -2. *The ontology is emergent.* Categories are created on first use. What proves useful stays; what doesn't fades. A persistent format would need a migration story every time the category structure changes. Ephemeral avoids this entirely — the facts are re-derived on each session start using the current (evolved) ontology. - -3. *Rebuildability is the safety net.* Because all facts have a =:grounding= to an Org heading, and gate-outcome facts are regenerated from the gate stack on every load, the entire symbolic index can be thrown away and rebuilt from scratch. The cost is compute, not data. This is the practical realization of "the prose is always the ground truth." - -The transition to persistence (Phase 5: VivaceGraph) happens when two conditions are met: the fact language has stabilized through use, and the accumulated deductions across sessions provide value that justifies the serialization cost. - -** The Gate-to-Fact Bootstrap — Extracting the First Ontology from Code -:PROPERTIES: -:ID: design-gate-bootstrap -:CREATED: [2026-05-08 Fri] -:END: - -The Dispatcher gate stack already encodes an implicit ontology. Every gate vector asserts the existence of a category of things: - -- Gate vector 2 asserts there exists a class of files called /secrets/. -- Gate vector 7 asserts there exists a class of commands called /destructive/. -- Gate vector 8 asserts there exists a class of domains called /trusted/. -- The self-build boundary asserts there exists a class of files called /core-harness/ and a class called /skills/. - -These claims are currently expressed as code — Lisp functions that pattern-match against file paths, shell commands, and URLs. They are not facts the symbolic engine can query, derive from, or check for consistency. But they can be made explicit. - -The bootstrap makes every gate a set of initial symbolic facts: -=(:file ".env" :member-of-class :secret-files :source gate-vector-2)=, -=(:command "rm -rf /" :classified-as :catastrophic :source gate-vector-7)=, -=(:domain "api.telegram.org" :classified-as :trusted :source gate-vector-8)=. - -This produces 50-70 entity classes directly from the existing gate stack, without any new infrastructure: - -| Source | Count | Example categories | -|----------------------------------------+-------+----------------------------------------------------| -| ~*dispatcher-protected-paths*~ | 11 | :secret-config-file, :ssh-key-file, :gpg-key-file | -| ~*dispatcher-shell-blocked*~ | 8 | :catastrophic-command, :injection-pattern | -| ~*dispatcher-network-whitelist*~ | 2 | :trusted-domain, :untrusted-domain | -| Self-build boundary | 2 | :core-harness-file, :skill-file | -| Privacy tags | 3 | :private-content, :financial-content | -| Permission table | 3 | :read-only-tool, :write-tool, :eval-tool | -| Cognitive tools | 6 | :code-search-tool, :file-io-tool, :shell-tool | -| Relations (all gates) | ~15 | :member-of-class, :classified-as, :depends-on | -| Qualities | ~8 | :catastrophic, :dangerous, :moderate, :harmless | -| Provenance sources | 4 | :gate-outcome, :human-authored, :deduced, :llm-proposed | - -This is the seed. It gives Screamer a domain to reason about immediately, without any LLM involvement. It proves the pattern — code becomes facts, facts enable reasoning — at the cost of approximately 30 lines of Lisp. - -** The LLM as Proposer — Verified Extraction -:PROPERTIES: -:ID: design-llm-proposer -:CREATED: [2026-05-08 Fri] -:END: - -The LLM cannot be trusted to populate the symbolic index directly. Its outputs are sampled, not proven. A probabilistic extraction feeding a deterministic engine defeats the purpose of being deterministic. - -But the LLM is still useful. It can surface facts that are obvious to a human reader of prose but would take the symbolic engine many deduction steps to reach independently. The solution is to demote the LLM from /extractor/ to /proposer/: - -1. The archivist reads a prose heading. -2. The LLM proposes candidate triples. -3. Screamer checks each triple for consistency against the existing fact store. -4. Only consistent triples are admitted to the symbolic index, flagged with =:provenance :llm-proposed= and grounded to the source heading. - -The LLM might hallucinate facts that don't correspond to the prose. It might extract facts that contradict existing knowledge. It might produce syntactically malformed triples. None of these failures contaminate the symbolic index because proposals are not admitted automatically. The admission gate (Screamer) is deterministic. - -This is the core architecture pattern. Everything else — the entity classes, the deduction engine, the persistence layer — follows from this single design decision: *the LLM proposes; the symbolic engine decides whether to accept.* - -** Cardinality Policies — Singular, Dual, and Plural Facts -:PROPERTIES: -:ID: design-cardinality -:CREATED: [2026-05-08 Fri] -:END: - -Classical logic requires consistency. A contradiction implies everything (=ex contradictione quodlibet=). Screamer, as a constraint solver, also requires consistency — a contradictory constraint set has no solutions. But the symbolic engine operates across domains where the meaning of contradiction is fundamentally different. The correct question is not "is this consistent?" but "what cardinality of truth does this domain support?" - -Time is not a policy. It is a universal dimension that applies equally to every fact, regardless of cardinality. All facts carry =:timestamp= and =:parent-id= fields. Every fact has a version history. Every fact lives in a Merkle chain that captures how it changed. The cardinality policy only governs what happens at a given logical moment when two values coexist for the same =entity= and =relation=. - -*** Policy :singular — One Active Value, One Version Chain - -The active set contains exactly one value for =(:entity :relation)= at a time. When a new value asserts for the same pair, the old value is not rejected. It is superseded — moved into the version history, linked to the new leaf by =:parent-id=, and retained permanently. The active value is the leaf of the Merkle chain. - -"I used to think =rm -rf /= was safe. Now I know it is catastrophic." Both facts exist. Both are true — the first at =2024-06-01=, the second at =2025-03-15=. The chain captures the evolution. The =:singular= policy means there is one truth /now/, not that there was only ever one truth. - -Use for: security classifications, file system state, gate rules, code correctness, deterministic safety constraints — domains that converge on one answer, evolving over time. - -*** Policy :dual — Exactly Two Values, in Explicit Tension - -The active set contains exactly two values for =(:entity :relation)=. Both are simultaneously true. Both carry independent version histories. A third value is rejected — the domain is binary by nature. - -Some contradictions are productive precisely /because/ they are binary. Thesis and antithesis. Love and resentment. Wave and particle. A poem's two incompatible readings. The symbolic index holds both, cross-referenced as complementary rather than conflicting. The user is not asked to resolve the tension. The tension is the fact. - -The system can reason about cardinality transitions: a =:dual= fact that has one interpretation superseded should collapse to =:singular=. A =:dual= that has a third interpretation asserted should prompt the user: "Promote to =:plural= or demote one interpretation?" - -Use for: productive binary tensions, complementary opposites, dialectical pairs, any domain where two answers are both true and their tension is meaningful. - -*** Policy :plural — N Active Values, Open Set - -The active set contains any number of values for =(:entity :relation)=. Each value has independent provenance and its own version history. Queries return all active values with provenance display. Contradictions are flagged as cross-references between values — information, not error. - -A =:plural= fact where all but one value are superseded should collapse to =:singular=. A =:plural= fact where the set reduces to two active values — and the remaining two are complementary — should collapse to =:dual=. - -Use for: literary interpretation, scientific hypotheses, personal beliefs held at different times (when tension is multi-faceted rather than binary), multi-source factual disagreement, open-ended exploration. - -*** Policy Assignment - -The policy is assigned when a category is defined. New categories default to =:plural= (safe — never loses information). Core security categories are explicitly =:singular=. The gate stack's bootstrapped facts are =:singular= because they describe the actual filesystem, which is physically singular. Categories for dialectical or complementary domains are explicitly =:dual=. - -The Screamer admission gate applies the cardinality policy at the active set: -- =:singular= + same value, later timestamp → supersede old, chain new as leaf. -- =:singular= + different value, same timestamp → reject (contradiction). Human resolves. -- =:singular= + different value, later timestamp → supersede old, chain new as leaf. History preserved. -- =:dual= + first value → admit. + second value → admit, cross-reference as complementary. + third value → prompt. -- =:plural= + any value → admit. Active count transitions trigger collapse checks. - -*** Why This Matters for the Broader Memex - -In the coding domain, contradiction is rare, resolvable, and usually temporal (a rule changed). In the broader memex, contradiction is the product, not the error. Your poetry analysis contradicts your last diary entry. Your reading of /Pale Fire/ changed between 2023 and 2025. Wikidata says Mount Everest is 8848m; DBpedia says 8849m. You love this person AND you resent them. - -The symbolic engine's job is not to decide which is right. It is to surface the tension with provenance — "these three sources disagree; here is the chain for each" for plural facts, or "you hold these two positions in tension" for dual facts, or "you believed X until Tuesday, then Y" for singular facts that evolved. The cardinality policy names the /structure/ of the tension. The Merkle chain provides the /history/ of each position. - -** How Categories Grow — The Organic Ontology -:PROPERTIES: -:ID: design-organic-ontology -:CREATED: [2026-05-08 Fri] -:END: - -Whitehead's /Principia Mathematica/ took over 300 pages to define the logical foundations before it could prove that one plus one equals two. Every category introduced carried a burden of justification. Every inference rule had to be demonstrated sound. This is the classical approach to ontology: define everything upfront, exhaustively, formally. - -Passepartout cannot afford this and does not need it. Its domain is bounded (software engineering, personal knowledge, literary engagement, daily life) and its ontology grows from the system's own operation: - -1. *The gate stack seeds the ontology.* Every gate vector is an implicit claim about a category of things. The bootstrap makes these claims explicit. The seed is 50-70 entity classes with no human authoring required — mechanically extracted from existing code. - -2. *New gate vectors add categories directly.* As the Dispatcher grows (new shell patterns, new path protections, new tool classifications), the ontology grows with it. Every new pattern becomes a fact on skill load. - -3. *Screamer generalizes from gate outcomes.* After 37 shell commands are blocked as destructive, Screamer extracts structural commonalities: "commands writing to block devices," "commands recursively deleting outside the workspace." These become new subcategories that didn't exist in the original gate patterns. The ontology deepens through observation. - -4. *The archivist proposes from prose.* The archivist reads a diary entry about a book: "Nabokov's lectures on Kafka." The LLM proposes =(:entity :nabokov :relation :lectures-on :value :kafka)=. Screamer checks consistency. Admitted. The categories =:author=, =:lectures-on=, and =:subject= didn't exist before — they are created on first use. This is the primary growth mechanism for the broader memex. - -5. *The human declares explicitly.* The human writes a declarative fact directly into the symbolic index. No extraction step. No LLM involvement. The fact is admitted with =:provenance :human-authored= — the highest trust level. - -6. *Temporal patterns crystallize into categories.* Every Sunday the memex gets a retrospective heading. Every Monday a planning heading. The time-awareness system observes the periodicity and proposes =:weekly-retrospective= and =:weekly-planning= as fact types. Screamer verifies. - -7. *Cross-domain overlap produces parent categories.* Screamer notices that =:secret-files= (from the gate stack) and =:private-content= (from privacy tags) share members — =.env= is both a secret file and private content. It proposes =:sensitive-material= as a parent with both as children. Taxonomy building happens automatically through overlap detection. - -*** Growth is self-limiting by design - -Not every conceivable category is added. The system prunes through use: - -- New categories are admitted only through Screamer's consistency check. A category that contradicts an existing classification is rejected. -- A category that never gets queried costs nothing (a hash table entry) but produces no value. It fades from use naturally. -- Overly fine-grained categories are rejected because they are redundant with the wildcard pattern that already covers them. -- Overly broad categories that subsume meaningful distinctions produce contradictions when Screamer tries to apply existing rules. Rejected. - -The system converges on a useful granularity through use, not through upfront design. The gate stack provides the seed. Gate outcomes, prose extraction, deduction, and human authoring grow the shoots. Screamer prunes contradictions. The ontology is a garden, not a building. - -** Ontology Versioning — How Worldviews Change Without Losing Perspective -:PROPERTIES: -:ID: design-ontology-versioning -:CREATED: [2026-05-10 Sun] -:END: - -Ontology refactoring is not a schema migration. It is a worldview change. When you split =:secret-file= into =:crypto-secret= and =:plaintext-secret=, you are not renaming columns. You are reclassifying what a file *is* — and every Screamer deduction that crossed the old category boundary now means something different under the new distinction. - -The system preserves all worldviews. It does not overwrite the past with the present. - -The category hierarchy is itself a Merkle tree. Every entity class definition carries a hash of its superclasses, its cardinality policy, its associated relations, and its description. The aggregate hash of all active class definitions is the =:ontology-version= — a Merkle root of the current worldview. - -Every fact — every triple, every deduction, every gate outcome — stores its =:ontology-version= at the time of assertion. This is a single field, 64 hex characters. The cost is negligible. The implication is profound. - -When categories change, the system does not run a batch UPDATE. It re-verifies: - -1. A new category hierarchy produces a new =:ontology-version= hash. -2. Facts carrying the old hash are flagged for re-verification. -3. On heartbeat or manual trigger, Screamer re-evaluates each flagged fact against the /new/ category definitions. The old justification chain is preserved alongside the new outcome. -4. Status: =:survived= (still valid), =:incoherent= (premises don't translate, flagged for human review), =:reclassified= (valid but under different classification). - -The =fact-query= function accepts an optional =:ontology-version= parameter. Queries default to the current worldview (=:active=). Specifying a version returns facts as they were under that worldview. The system can answer questions that no other knowledge tool can: "What did I believe about secrets before I refined my security model?" "How has my reading of /Pale Fire/ evolved across three frameworks?" "Which deductions survived my last ontology refactoring?" - -This is not querying a fact. It is querying the history of your own thinking — the fact that you changed your mind, the date you did, the reasoning that held and the reasoning that didn't. - -** The "Awakening" — Sufficiency Criterion -:PROPERTIES: -:ID: design-awakening -:CREATED: [2026-05-08 Fri] -:END: - -The symbolic index begins its life as a lossy construct. The initial extraction from prose — LLM proposals verified by Screamer — is built from an uncertain foundation. Some facts are correct. Some are missing. Some are wrong. - -But the symbolic engine accumulates non-lossy facts through three independent mechanisms: - -1. *Gate outcomes* — every gate rejection is a fact. No LLM involved. Accumulate at the rate of user interactions. -2. *Screamer deductions* — new facts derived from existing facts. No LLM involved. Accumulate whenever the fact store crosses a density threshold. -3. *Human authoring* — the human explicitly declares facts. No LLM involved. - -At some point, the non-lossy facts constitute a sufficient foundation that the symbolic engine can reverse the flow: instead of the LLM extracting facts from prose, the symbolic engine reads prose through its own lens — its now-substantial ontology of categories, rules, and constraints — and asserts facts in its own language. The extraction mechanism ceases to be probabilistic and becomes deterministic. - -The sufficiency criterion makes this operational: =(/ (count-provenance :gate-outcome :human-authored :deduced) total-facts)=. When this ratio exceeds a configurable threshold (=SUFFICIENCY_THRESHOLD=, default 0.7), the system considers its foundation sufficient. The archivist switches from "LLM proposes, Screamer verifies" to "Screamer queries existing facts, applies to the new prose, and deduces new facts directly." - -The flip is visible to the user: "Symbolic index: 847 facts (73% non-lossy, 12% LLM-proposed, 15% Wikidata). Sufficient foundation: YES." - -The flip does not mean "complete." In the broader memex, completeness is neither possible nor desirable. The awakening means "deterministic enough to be trustworthy," not "comprehensive enough to be self-sufficient." The neural index remains the gateway to the full richness of prose. The symbolic index handles what can be mechanically verified. The boundary is permanent. - -** Merkle DAG for Version History -:PROPERTIES: -:ID: design-merkle-dag -:CREATED: [2026-05-10 Sun] -:END: - -Every fact is versioned. Every =(:entity :relation)= pair forms its own independent chain in a Merkle DAG. This is not new infrastructure — it is a new occupant of Passepartout's existing Merkle-tree memory system (v0.2.0). - -When a fact supersedes its predecessor, the new fact hashes over: =SHA-256(value || provenance || timestamp || parent-hash || grounding)=. The parent-hash pointer forms the chain. Tampering with any version changes its hash, breaking all downstream references. The history is tamper-proof by construction. - -Facts about =(.env :member-of-class)= form one chain. Facts about =(:nabokov :wrote)= form another. They evolve independently. They share no ancestry. This is a DAG, not a single list — inserting a fact is O(1) per chain. Changing a fact about =.env= does not require rehashing the literary index. - -=:dual= and =:plural= facts cross-reference each other via edges (=:complements=, =:contradicts=) but these are semantic relationships, not parent chains. Each value has its own ancestor chain. The cross-reference edges form a web; the parent chains form a spine. - -Passepartout already snapshots the Merkle root over all memory objects. Adding the fact store to the snapshot is a registration, not a new mechanism. Rolling back the snapshot restores the entire fact state — all chains, all cross-references, all cardinalities — to that point in time. - -** Abstract Fact Store Interface — Modular by Design -:PROPERTIES: -:ID: design-fact-interface -:CREATED: [2026-05-10 Sun] -:END: - -The fact store is accessed through an abstract API. The Merkle DAG (or any future backing store) is an implementation behind this interface, not a dependency that code throughout the system calls directly. - -#+begin_example -fact-assert :: fact → store → (:admitted | :rejected | :flagged) -fact-query :: (entity &key relation policy) → active-value-or-values -fact-history :: (entity relation) → ordered chain of versioned facts -fact-snapshot :: () → root-hash -fact-rollback :: root-hash → store -#+end_example - -Implementations behind the interface: -- Phase 1-4: ephemeral hash table with =:timestamp= and =:parent-id= pointers. No cryptographic hashing. No persistence. -- Phase 5: VivaceGraph + Merkle =memory-object= wrapper. Content-addressed, persistent, tamper-proof. - -Future implementations that satisfy the same interface — an append-only write-ahead log, an immutable B-tree, a content-addressed triple store — can replace the backing store without changing any consumer. The archivist, Screamer, ACL2, and the planner call =fact-assert= and =fact-query=, not Merkle struct accessors or VivaceGraph traversal syntax. - -This is not speculative modularity. The two-implementation migration (Phase 1-4 hash table → Phase 5 VivaceGraph + Merkle) is in the roadmap. If the interface leaks implementation details, the migration breaks. The interface must be designed, tested against both backends, and committed before Phase 1 ships. - -** Knowledge Graph Type Hierarchy — Structural Anti-Self-Reference (v3.0.0) -:PROPERTIES: -:ID: design-kg-type-hierarchy -:CREATED: [2026-05-14 Thu] -:END: - -The same type-theoretic principle that governs the gate stack can be applied to the knowledge graph itself. When VivaceGraph ships (v3.0.0), every entity carries a ~:pm-type-level~ metadata field. Queries cannot return entities of the same level as the querying function. Self-referential knowledge becomes structurally impossible — no "this entity defines its own type level." - -The KG query layer enforces this at the Prolog level, not through runtime checks. This is the same idea as the type-level gates (see Safety section above), but applied to /knowledge/ rather than /actions/. The dispatcher prevents self-referential actions; the KG prevents self-referential facts. - -For the full philosophical treatment, see the Whitehead analysis in the Validation section below. - -* Knowledge Sources - -** Semantic Wikipedia as Entity Backbone -:PROPERTIES: -:ID: design-wikipedia -:CREATED: [2026-05-08 Fri] -:END: - -The gate stack provides 50-70 entity classes — adequate for a coding agent where the domain is bounded to files, commands, and code symbols. For a general-knowledge memex, 50-70 is starvation. Your memex mentions Nabokov, /Pale Fire/, Kinbote, Zembla, paranoid reading, unreliable narrators, postmodernism, butterfly migration, chess problems, and the Russian exile experience. The gate stack knows none of these. Organic growth through prose extraction would take years just to cover the entities in one person's engagement with a single novel. - -Wikidata has already done this work: approximately 2 million entity classes, over 100 million entities, a decade of human curation. By loading the neighborhood of your memex into the symbolic index (entities referenced in your prose, plus their N-hop property net from Wikidata), the entity recognition problem vanishes. The archivist doesn't need to discover Nabokov from your diary. It needs to connect your heading to the existing Wikidata entity. That is a simpler task — reference resolution, not knowledge extraction. - -The LLM's role shrinks to three thin boundaries: - -1. *Input translation* — natural language question to structured query. "What do I think about monorepos?" → =(fact-query :entity :monorepo :relation :opinion :source :memex)=. Formulaic, ~100 tokens, any model sufficient. - -2. *Prose to candidate triple* — for personal memex entries that have no Wikidata counterpart: your opinions, your day's events, your project plans. Proposals verified by Screamer before admission. This is the only extraction path that still requires an LLM, and its scope is limited to what Wikidata cannot provide. - -3. *Result to prose* — structured answer to readable sentence. "Your 2023 diary says 8848m. Wikidata (last edited Feb 2024) says 8849m. They disagree on height." The reasoning is done; the LLM wraps the plist in grammar. ~100 tokens, any model sufficient, purely cosmetic. - -Everything else — the gate stack, the fact store, the constraint solver, the type hierarchy, the provenance tracking, the contradiction surfacing, the cross-domain comparison — is pure deterministic Lisp with zero LLM tokens. - -The decisive simplification: without Wikidata, the archivist must /discover/ entities from prose. With Wikidata loaded, the entity graph is pre-structured. The archivist's job changes from "discover that Nabokov wrote /Pale Fire/ and lectured on Kafka" to "verify that the Nabokov referenced in heading #47 is Wikidata item Q36591." - -Wikidata facts are admitted with =:provenance :wikidata= and cardinality policy =:plural=. They do not override your memex's facts. They sit alongside them. Disagreements are surfaced, not resolved. - -** Empirical Validation — MOMo and Modular Ontology Engineering -:PROPERTIES: -:ID: design-momo -:CREATED: [2026-05-08 Fri] -:END: - -Shimizu and Hitzler (2025, /Journal of Web Semantics/) argue that LLMs can significantly accelerate knowledge graph and ontology engineering — modeling, extension, population, alignment, and entity disambiguation — but /only/ if ontologies are modular. - -*** The central finding: modularity is the key variable - -In a complex ontology alignment task, an LLM without module information detected correct mappings for 5 of 109 alignment rules — effectively useless. When the same LLM was given the module structure of the target ontology (20 named conceptual modules), it detected correct mappings for 104 of 109 rules — 95% accuracy. The variable was modularity. - -For ontology population (extracting triples from text), their best results came from prompts that included a schematic representation of a /single module/ plus one extraction example. Against ground truth, this achieved approximately 90% extraction accuracy. Without module-scoped prompting, quality degraded substantially. - -The mechanism: conceptual modules scope the LLM's attention to something human-sized. The paper's central claim — "by somehow limiting the scope, we achieve a more human-like approach — and one more capable of being expressed succinctly in language" — is an independent discovery of the same principle underlying Passepartout's domain-scoped Screamer checks and per-domain cardinality policies. - -*** What Passepartout should adopt - -*The modular prompt pattern.* The archivist should use module-scoped prompts: a schematic representation of a domain module plus a single extraction example. Instead of a generic "extract triples" prompt, the prompt should reference the relevant module(s) and include an example triple for each relation in that module. The module provides /context/; the example provides /format/. Both improve LLM extraction quality without increasing Screamer's verification burden. - -*MOMo modules as ontology scaffold.* The 50-70 gate-bootstrapped entity classes are starvation for the broader memex. MOMo's micropattern library provides a ready-made scaffold — hundreds of commonsense patterns for temporal relations, spatial relations, agent-action, organizational structure, provenance, and event participation. Loading these as initial modules — with =:policy :plural= and =:provenance :external-ontology= — would give the symbolic index a structured vocabulary for domains where the gate stack has nothing to offer. Organic growth then /extends and refines/ these modules rather than inventing them from scratch. - -*Cross-source validation.* The archivist can extract facts from the user's prose, extract facts from Wikidata for the same entities, and present disagreements with provenance. This is the =:plural= cardinality policy applied at extraction time. - -The paper validates three design decisions already made: (1) modularity is non-negotiable — the difference between 5% and 95% accuracy; (2) the extraction pipeline is feasible — 90% population accuracy with module-scoped prompts means the archivist /can/ extract useful facts, and the remaining 10% hallucination rate is what Screamer catches; (3) knowledge graphs are positioned as anti-hallucination infrastructure — the Passepartout thesis stated in the academic literature. - -References: -- Shimizu, C., & Hitzler, P. (2025). Accelerating knowledge graph and ontology engineering with large language models. /Journal of Web Semantics, 85/, 100862. -- Shimizu, C., Hammar, K., & Hitzler, P. (2023). Modular ontology modeling. /Semantic Web, 14/(3), 459–489. -- Norouzi, S.S. et al. (2024). Ontology Population using LLMs. arXiv:2411.01612. - -* Implementation Properties - -** Performance — Why Ontology Growth Doesn't Make the System Slower -:PROPERTIES: -:ID: design-performance -:CREATED: [2026-05-10 Sun] -:END: - -Passepartout's performance thesis is: minimize LLM calls, minimize context tokens, keep everything else local and fast. Knowledge base size is irrelevant to those metrics. This is not an aspiration. It is a structural property. - -The system has two cost domains with fundamentally different scaling: - -| Resource | Cost driver | Scales with | -|---------------+------------------------------------------+------------------------------------------| -| LLM tokens | Context window size, number of API calls | Foveal-peripheral pruning, gate rules | -| Compute | Screamer deduction, hash table lookups | Entity count, rule count per domain | - -LLM tokens are minimized by design — deterministic gates cost 0 tokens, sparse-tree rendering keeps context at 2,000–4,000 tokens regardless of memex size. Adding 5 million Wikidata entities doesn't add a single token to any LLM call. The education is local. Only the brain costs. - -Compute grows linearly with entity count (hash table lookups are O(1), but memory footprint grows). It grows with rule count within a single domain during Screamer consistency checking. But these are microsecond costs on local hardware, not API bills. A Screamer constraint check against a domain with 200 rules costs ~0.3ms. A 100-token guardrail paragraph in a system prompt costs ~$0.00001. The Screamer check is 10,000x cheaper and convergent — it handles the rule once. The guardrail paragraph handles it on every call, forever. - -A 5-million-entity Wikidata load is ~400MB in a hash table. A lifetime personal memex with a decade of diary entries is perhaps 10-20 million triples (~1.5GB). Modern laptops carry 16-64GB. The knowledge base fits in consumer hardware with room for the Lisp runtime, the memory-object store, and the LLM inference engine. - -*One genuine risk — rule generalization width.* If Screamer deduces increasingly broad rules within a single domain, the constraint space could bloat. Mitigation: rules carry a =:domain= tag. Screamer only applies rules from the fact's domain. Rule generalization that crosses domain boundaries is gated — must be human-approved. Rules that prove unused (never triggered a check in N heartbeat cycles) are demoted to =:inactive= and excluded from the active constraint set. - -This is the minimalism argument restated in concrete terms: you buy bigger RAM and a faster CPU once. You don't buy bigger LLM context windows on every call. The education is a capital investment. The brain is an operating expense. The architecture makes the ratio favor capital. - -** The Provenance Chain as Product -:PROPERTIES: -:ID: design-provenance-product -:CREATED: [2026-05-10 Sun] -:END: - -In the coding domain, the value of the symbolic engine is the verified fact: "this command is safe." In the broader memex, the value is the provenance itself: "this claim originated in that diary entry on that date, has been referenced 7 times across 4 different projects, was contradicted in a retrospective 6 months later, and was revised in a note 3 weeks after that." - -The symbolic engine doesn't tell you what is true. It tells you what you wrote, when, where, and how it connects to everything else you wrote — with a verifiable audit trail. It is a memory prosthesis that makes your own mind legible to you. - -Every fact carries: -- =:grounding= — the specific Org heading from which it was extracted -- =:provenance= — who or what produced it (gate-outcome, human-authored, deduced, LLM-proposed) -- =:timestamp= — when it was admitted to the symbolic index -- =:referenced-by= — other facts that depend on or reference this one -- =:contradicted-by= — other facts that disagree with this one (if any) -- =:superseded-by= — if this fact was replaced by a newer version - -These fields make every fact auditable. The =/audit = command renders the full provenance chain as an Org headline tree. The provenance is not a logging feature. It is the product. - -* Engineering Infrastructure - -** The REPL as Cognitive Substrate -:PROPERTIES: -:ID: design-repl-cognition -:CREATED: [2026-05-07 Wed] -:END: - -A REPL — Read, Eval, Print, Loop — is an interactive programming environment that reads an expression, evaluates it, prints the result, and loops back to read the next expression. It is the opposite of batch processing: where batch compiles and runs a program in one shot, a REPL works one expression at a time, with each evaluation building on all previous ones. The state accumulates. The session is the program. - -In Lisp, the REPL is not a debugging tool bolted onto the language — it is the natural mode of interaction. The running image is the environment. When you evaluate =(+ 2 2)=, the result =4= is printed, and you remain in the same image where =+= is defined, where previous definitions persist, where the next expression can reference anything that came before. There is no separation between development and execution. The REPL is not a simulation of the program — it is the program running. - -Passepartout uses the REPL in this spirit, but elevated: it is not merely a tool for writing code, it is the mechanism by which the agent interacts with its own cognition — a loop that mirrors the perceive-reason-act metabolic cycle at the implementation level. - -In the agent's cognitive architecture, the REPL serves three functions that are difficult or impossible to achieve through batch processing or stateless API calls. - -First, the REPL enables verification before commitment. When the agent generates code, it does not write and forget — it evaluates in a running image, observes the result, iterates if incorrect. The feedback loop is tight: the time between writing and seeing the error is measured in milliseconds, not in the round-trip to a language server or a batch compiler. This is the "verification over hallucination" principle made concrete: the agent tests what it writes before claiming it works. - -Second, the REPL enables stateful exploration. The agent can define a variable, inspect it, modify it, redefine it. The exploration accumulates state across interactions. This is not a debugging session — it is the agent thinking with its hands, working through a problem by trying variations and observing outcomes, keeping the successful ones and discarding the failures. - -Third, the REPL is a shared substrate. When the agent evaluates code, that code runs in the same image as the agent's own cognition. There is no process boundary between the agent and its tools. The REPL is not a subprocess the agent controls — it is a direct interface to the agent's own nervous system. - -This is why the REPL becomes more important as the system matures. In early versions, it is a development tool. In v0.6.0 and beyond, it becomes a cognitive tool: the agent explores hypotheses by evaluating them, verifies the output of sub-agents by inspecting live state, and tests modifications before committing them to the knowledge graph. - -** The Cybernetic Loop: Why the Metabolic Pipeline Works -:PROPERTIES: -:ID: design-cybernetic-loop -:CREATED: [2026-05-07 Wed] -:END: - -The Perceive → Reason → Act cycle is not a software architecture pattern. It is a cybernetic feedback loop — the mechanism by which a system steers itself toward a goal in a changing environment. - -Norbert Wiener defined cybernetics in 1948 as "control and communication in the animal and the machine." The metabolic pipeline implements this precisely: Perceive is the sensor (reading the environment), Reason is the controller (evaluating against goals and constraints), Act is the actuator (modifying the environment), and the tool-output feedback signal closes the loop (reading the effect of the action and adjusting the next perception). - -The Dispatcher gate stack is the negative feedback governor. When the LLM proposes an action that would violate an invariant, the Dispatcher blocks it and feeds the rejection trace back to the LLM for self-correction. This is Ross Ashby's homeostasis — the system maintains its internal stability by correcting deviations from its set point (the safety invariants). Without this negative feedback, the probabilistic engine would drift into hallucinated proposals that become progressively less grounded. The Dispatcher constrains it to the domain of safe, verifiable actions. - -The self-editing capability is second-order cybernetics — autopoiesis, the capacity of a system to create and maintain itself. Humberto Maturana and Francisco Varela defined this as the hallmark of living systems. When the agent detects an error, locates the faulty function, generates a corrected version, and hot-reloads it into the running image without restarting, it is modifying its own architecture while continuing to operate. Passepartout achieves this through Lisp's homoiconicity — code is data, and the running image is the environment. - -This framing matters for two reasons. First, it places Passepartout in a lineage that predates and outlasts the current "LLM with tools" paradigm. The cybernetic principles of feedback, homeostasis, and autopoiesis are independent of any specific model architecture. They work whether the perceptual engine is an LLM, a vision model, or a symbolic parser. Second, it explains why the architecture gets more reliable over time — cybernetic systems improve through accumulated negative feedback corrections, not through better training data. Every blocked action is a correction. Every approved exception is a refined set point. The system converges on stability through use. - -** Observability and the Thought Trace -:PROPERTIES: -:ID: design-observability -:CREATED: [2026-05-07 Wed] -:END: - -When a human asks why the system made a decision, the answer must be findable. In most AI systems, the reasoning is ephemeral — it exists in the model's activations and disappears when the session ends. In Passepartout, every significant cognitive event is written to an Org buffer as it happens. - -The thought trace is the agent's journal, written in parallel with its reasoning. When the probabilistic engine generates a proposal, the trace records the input, the prompt, and the raw output. When the deterministic engine evaluates it, the trace records which rules were checked, which passed, which failed, and why. When an action is executed, the trace records the timestamp, the user who approved it (if human-in-the-loop), and the outcome. - -This is not logging in the traditional sense. Logs are forensically useful but are written in a machine format optimized for storage, not for human reading. The thought trace is written in Org-mode: headlines for major events, property drawers for structured data, tags for categorization. The human can open the trace in a text editor and navigate it like any other Org file. They can search for a specific decision, filter by time range, find all actions blocked by a specific rule, or see the complete trajectory of a multi-step task. - -The trace becomes the foundation for the Dispatcher's learning. Every blocked action is in the trace. Every approved exception is in the trace. The human-in-the-loop decisions are in the trace. The system does not need to reconstruct what happened — it reads what happened from the trace it wrote. - -Without observability, the system is a black box that happens to produce correct outputs sometimes. With observability, the system is auditable. The human can see why a decision was made, identify where the reasoning failed, and course-correct the system or its own behavior accordingly. - -** Literate Programming as Discipline -:PROPERTIES: -:ID: design-literate-programming -:CREATED: [2026-05-07 Wed] -:END: - -The decision to use Org-mode as the source of truth for code, not just documentation, is not a ceremonial preference. It is a constraint mechanism that enforces better engineering habits at the cost of convenience. - -The traditional development workflow is: write code, write comments, commit. The literate programming workflow is: write prose, write code, commit the Org. The order matters. The prose must come first not because of style guidelines but because the act of explaining what a function does before writing it forces clarity of thought that editing code directly does not. - -When you must write a paragraph describing what a function does before you write the function, you discover the cases you have not considered. You find the edge conditions that are ambiguous. You realize that the function's name does not match its behavior, or that its behavior does not match your intent. The friction is not a bug — it is the mechanism by which thinking is enforced. - -The one-function-per-block rule enforces granularity. A function that cannot be explained in a paragraph is a function that is doing too much. The block boundary is not aesthetic — it is architectural. It prevents the drift toward monolithic functions that accumulate responsibilities over time and become untestable, unmaintainable, and incomprehensible. - -The tangle step enforces source-of-truth discipline. The .lisp file is generated from the Org file. This means the Org file cannot drift from the implementation. If the implementation changes, the Org must be updated to match. If the Org describes behavior that the implementation does not perform, the tangle produces code that does not match the Org description. Either way, inconsistency is visible and recoverable. - -The evaluation gate enforces correctness. Every block can be evaluated independently in a running Lisp image. This means syntax errors are caught at authorship time, not at integration time. The function that compiles in isolation but fails in context is the function whose context dependencies were never made explicit. The evaluation gate forces those dependencies to surface. - -Together, these constraints create a development experience that is slower in the small and faster in the large. Writing a new function takes longer because you must explain it. But debugging, maintaining, and extending the codebase is faster because every function has a human-readable explanation of its intent, every function is testable in isolation, and every function's source is always synchronized with its documentation. - -The literate programming discipline is not about producing documentation. It is about producing code whose correctness has been verified by the act of explaining it. - -** The Evaluation Harness -:PROPERTIES: -:ID: design-evaluation-harness -:CREATED: [2026-05-07 Wed] -:END: - -SOTA parity is meaningless without measurement. A system that claims to match commercial agents must demonstrate it through reproducible benchmarks, not through feature checklists. The evaluation harness is the apparatus by which Passepartout proves its capabilities. - -The industry standard for coding agents is SWE-bench: a corpus of GitHub issues paired with pull requests. The agent is given an issue, must understand the codebase, write a fix, and submit. Success is measured by whether the submitted PR passes the existing test suite. This tests the full chain: understanding, planning, code generation, verification, and multi-step reasoning. - -Passepartout implements a native Lisp harness for this. A background thread clones repositories, feeds issues into the cognitive loop, tracks the resolution trajectory as an Org-mode headline tree, and scores success by test outcomes. The trajectory is persisted: when a resolution fails, the system can inspect where in the chain the reasoning broke down. The headline tree records the agent's thoughts at each step, making the failure auditable and the debugging human-assisted. - -Beyond SWE-bench, the harness includes chaos testing. The system is subjected to resource starvation, concurrent load, and adversarial input. The deterministic engine must maintain safety invariants under pressure. The symbolic verifier must not deadlock or livelock. The probabilistic engine must degrade gracefully. - -The harness also supports regression testing on the skill set. Every skill is tested against a suite of known inputs and expected outputs. When a modification is proposed to any skill — whether through manual editing or the agent's own self-modification — the test suite runs first. A skill that fails its tests is rejected before it can propagate to the running image. This is not a convenience — it is the mechanism by which self-modification remains safe. The agent can propose changes, but the harness verifies them before the changes take effect. - -** The MCP Strategy -:PROPERTIES: -:ID: design-mcp-strategy -:CREATED: [2026-05-07 Wed] -:END: - -The Model Context Protocol (MCP) is a standard for connecting AI systems to external tools and data sources. It defines how a client requests tools from a server, how the server exposes its capabilities, and how the client invokes them. The ecosystem is growing: MCP servers exist for GitHub, Slack, Postgres, filesystem access, and much more. - -Passepartout connects to this ecosystem, but not by becoming a Node.js runtime. The architecture is: external MCP servers communicate via stdio or SSE to a Lisp-native MCP client that runs in the same image as the agent. The client is pure Common Lisp — it parses the JSON-RPC messages, invokes the tools, and presents results to the agent as Lisp data structures. There is no serialization overhead between the agent and the MCP layer, no process boundary, no impedance mismatch. - -When the agent calls a tool via MCP, it receives a plist with the tool name, arguments, and result. The result is immediately usable by the agent's symbolic engine. When the agent generates a file, it can be written to the filesystem through an MCP filesystem server. When the agent needs to send a message, it can use an MCP Slack server. The agent does not need to know that these are MCP interactions — it sees only the plists that flow through its cognitive architecture. - -The alternative is to build MCP wrappers in Python or TypeScript and bridge to Lisp via subprocess. This introduces latency, serialization costs, and a maintenance burden. Passepartout's native client is smaller, faster, and more maintainable. The MCP client is a skill, not a core component. It can be reloaded, replaced, or removed without restarting the agent. - -** Local-First Architecture -:PROPERTIES: -:ID: design-local-first -:CREATED: [2026-05-07 Wed] -:END: - -Passepartout is designed to run on the user's machine, on their hardware, with their data, without requiring an internet connection. This is not a deployment option — it is an architectural commitment. The system must be able to reason, plan, and act using only the resources available locally. - -The motivation is not merely philosophical. Cloud-based AI agents are economically incentivized to collect data, to train on user interactions, and to build lock-in through proprietary formats and network effects. When the agent runs locally, the user owns the hardware, owns the data, and can terminate the process without asking permission. There is no vendor that can change terms, no service that can go offline, no model that can be updated without consent. - -Technically, local-first means several things. The LLM must be able to run on local hardware. Passepartout supports Ollama as a provider, which runs quantized models on CPU and GPU without requiring an external API. The vector database must be local. Passepartout uses its own org-object store, which is a folder of Org files that the agent already owns. There is no ChromaDB or Qdrant to install, no cloud vector service to authenticate with. - -The symbolic engine does not require a network connection. The Prolog/Datalog reasoner that verifies neural proposals runs entirely in the Lisp image. The Dispatcher's rule synthesis does not call an external service. The agent can operate in a disconnected environment indefinitely, resuming full capability when connectivity is restored. - -This does not mean Passepartout refuses to use cloud services when available and appropriate. It means cloud services are optional enhancements, not architectural requirements. The core is local. The user can choose to add cloud LLM providers for more capable inference, but the system functions without them. - -*On live images and binaries.* Passepartout's primary delivery path is source code running in a live SBCL process. The REPL is available. Skills hot-reload. The cognitive loop runs in an image that is mutable, inspectable, and homeiconic — the user can connect with SLIME, trace functions, inspect memory objects, and modify the system while it runs. A =save-lisp-and-die= binary is provided as a convenience for platforms where SBCL cannot be installed. The binary is the same image saved to disk with Swank pre-loaded — it is not a sealed container. The REPL works. Skills hot-reload. The binary is a packaging format, not an architectural decision. - -** Token Economics and Performance Advantage -:PROPERTIES: -:ID: design-token-economics -:CREATED: [2026-05-07 Wed] -:END: - -This section analyzes how Passepartout's architectural decisions translate into token usage, latency, and cost versus competing agent designs. - -*** The Core Insight: LLM as Expensive Resource, Not Default Engine - -Passepartout treats the LLM as a resource to be minimized. Every operation is designed to reduce LLM dependency. Competitors treat the LLM as the core engine through which all operations flow. This is not a difference of degree but of architecture. - -The structural multipliers are: - -1. *Sparse tree retrieval* — the foveal-peripheral model renders relevant Org subtrees (titles and properties for peripheral nodes, full content for foveal and semantically relevant nodes). Active context stays at 2,000–4,000 tokens. A "load everything" architecture serializes the entire knowledge base at 50,000–150,000 tokens. The mechanism is provably cheaper; the exact multiplier depends on memex size and complexity. - -2. *Deterministic safety* — the 10-vector Dispatcher gate stack runs in pure Lisp. Every gate is a Common Lisp function. Verification costs 0 LLM tokens per action. Competitors use prompt-based guardrails consuming 100–500 LLM tokens per verification. This multiplier is mathematically infinite — a Lisp function call costs no tokens, a guardrail paragraph in a system prompt costs tokens proportional to its length. - -3. *REPL verification* — code is tested in the running image before it is committed. Errors surface in milliseconds at 0 LLM tokens. Competitors discover errors after generation and pay 500–2,000 tokens per correction round-trip. The REPL eliminates the most expensive kind of LLM call: the one that produced wrong code and needs a do-over. - -4. *Hot state* — in a REPL-based agent, variables, file handles, sub-routine results, and memory objects are already in memory. Every turn in a standard chat agent re-sends the full conversation history. Token costs in chat agents are quadratic: a 10-turn session pays for ~55 "turns" of context (10 + 9 + 8 + ... + 1 = 55). In Passepartout, context is stored once in the Lisp image. A 10-turn session pays for ~10 turns of context. This is an ~82% reduction on protocol overhead alone, before any foveal-peripheral pruning. - -5. *Temporal filtering* — time-scoped memory queries return only nodes matching the time window. The temporal filter is a pure-Lisp hash-table walk with a numeric comparison on =memory-object-version=. Sub-millisecond. 0 LLM tokens. Competitors without time-indexed memory must serialize all nodes and let the LLM scan for temporal relevance — 5,000–50,000 tokens per temporal query. - -*** The Compounding Cost Curve — Unique Among Agents - -Every AI agent grows more expensive over time. Context histories accumulate. Safety instructions grow more elaborate. Guardrails become longer prompt paragraphs. The user's data grows. The only way to reduce cost in a standard agent is to cap context — sacrificing capability. - -Passepartout has a downward cost curve. Four mechanisms compound: - -1. *Dispatcher learning.* Every blocked action and approved exception becomes a deterministic rule. A file write that initially triggered a full LLM proposal → Dispatcher review → HITL approval → rule extraction loop eventually becomes a deterministic rule check. Each hardened rule permanently removes a future LLM call. - -2. *Symbolic induction.* The agent extracts patterns from successful interaction sequences and converts them into reusable Lisp functions. A multi-step task that took 5,000 tokens today takes 0 tokens tomorrow — it's now a =defun=. The Dispatcher learns what to block. Symbolic induction learns what to automate. - -3. *Native embedding inference.* Every semantic search query runs against in-image vectors at 0 external tokens. Competitors use LLM-assisted search for most retrieval operations. Passepartout's retrieval is a vector cosine similarity check — pure math, no model call. - -4. *Prefix caching.* The static portion of the system prompt (IDENTITY, TOOLS, LOGS format) is transmitted once per session. Dynamic content (CONTEXT, user prompt) is sent on each call. Anthropic's prompt caching gives a 90% discount on cached tokens. OpenAI caches automatically. - -After 12 months of daily use, Passepartout's per-session costs are expected to be 40–60% of baseline, while competitors' costs rise to 125–140% of baseline. The crossover point is estimated at 3–6 months. This is not a model quality claim — it is a structural property of the architecture. - -** Time Awareness as a Structural Advantage -:PROPERTIES: -:ID: design-time-awareness -:CREATED: [2026-05-07 Thu] -:END: - -Passepartout's architecture provides three layers of time awareness, each enabled by infrastructure that competitors lack: - -*Level 1 — Present Awareness.* The LLM knows the current time, date, and session duration because a single =format-time-for-llm= call injects it into the system prompt. Most agents know the date from the OS. None know the time or session duration. The cost is ~8 incremental tokens per call (trivially prefix-cached). The saving is eliminating "I don't know the current time" preamble tokens, time-check tool calls, and incorrect temporal reasoning from a model guessing the time. - -*Level 2 — Temporal Memory.* Memory queries accept =:since= and =:until= parameters. "What did I work on in the last hour?" filters 500 nodes to 12 in sub-millisecond Lisp rather than serializing 500 nodes to the LLM at ~5,000 tokens for it to scan. Every memory node carries a =memory-object-version= timestamp (a monotonic =get-universal-time= value set at ingest since v0.1.0). The temporal filter is a hash-table walk with numeric comparison. 0 LLM tokens. >90% token reduction on time-scoped queries. - -*Level 3 — Proactive Triggers.* The heartbeat tick scans for approaching deadlines every 60 seconds. When a deadline is within the warning window (=DEADLINE_WARNING_MINUTES=, default 60), a temporal context note is injected into the awareness assembly. The LLM sees "3 deadlines today: Submit report (45min)" in its context without a triggering call. A "what should I work on today?" query is answered from pre-loaded context — 0 LLM tokens versus 1,500–4,000 for an unassisted agent. - -None of these three layers require new infrastructure. Time awareness is not a feature Passepartout builds — it is a feature Passepartout *unlocks* by having timestamped memory (v0.1.0), heartbeat+cron (v0.3.0), and the foveal-peripheral context pruning model (v0.2.0) already in place. Adding time awareness costs ~175 lines of Lisp. Building it in competitors would require building the heartbeat, the time-indexed memory, and the proactive context injection — 800+ lines each — and would still cost LLM tokens because their safety verification is prompt-based. - -** Definite Description Resolution -:PROPERTIES: -:ID: design-description-resolution -:CREATED: [2026-05-14 Thu] -:END: - -When the user says "the function that validates secrets," the agent must resolve this to a specific code entity. Natural language is ambiguous — there might be multiple functions matching the description. Resolving to the wrong one causes incorrect actions. - -/Principia Mathematica/'s theory of descriptions addresses this: "the current king of France is bald" — a sentence that seems to refer to something that doesn't exist. PM formalizes ~ιx(φx)~ as "the unique x such that φ holds." A statement is false (not meaningless) when there is no unique x satisfying φ. - -A cognitive tool that checks descriptional uniqueness before resolution: - -#+BEGIN_SRC lisp -(def-cognitive-tool :resolve-reference - (query-string &key (max-candidates 10) - (context-path *current-context*)) - "Resolve a definite description to a unique referent." - (let ((candidates (search-knowledge-graph query-string - :source-path context-path - :limit max-candidates))) - (cond - ((null candidates) - (values nil :no-referent query-string)) - ((> (length candidates) 1) - (values nil :ambiguous candidates)) - (t - (values (first candidates) :unique nil))))) -#+END_SRC - -~40 lines as a skill in v0.7.2. When VivaceGraph ships (v3.0.0), descriptions become native Prolog queries with uniqueness constraints. - -For the philosophical foundations, see the Whitehead analysis in the Validation section below. - -* Validation - -** Whitehead's Process Philosophy and Type Theory -:PROPERTIES: -:ID: design-validation-whitehead -:CREATED: [2026-05-14 Thu] -:END: - -Alfred North Whitehead's two major bodies of work — /Principia Mathematica/ (1910–1913, with Bertrand Russell) and /Process and Reality/ (1929) — provide both the historical foundation and the descriptive vocabulary for Passepartout's architecture. The first gave us the type theory that structures the gate stack; the second gave us the process ontology that describes the pipeline. - -/Principia Mathematica/ is a direct ancestor of Lisp. Alonzo Church's lambda calculus (1930s), from which John McCarthy built Lisp (1958), was a response to PM's foundational program. PM's notation: - -#+BEGIN_EXAMPLE -(x).φx ≡ (for all x, φ holds of x) -(∃x).φx ≡ (there exists x such that φ holds) -* x̂(φx) ≡ (the class of x satisfying φ) -ιx(φx) ≡ (the unique x satisfying φ) -#+END_EXAMPLE - -These map directly to Lisp: ~(lambda (x) (φ x))~, ~(class (x) (φ x))~, ~(the (x) (φ x))~. McCarthy cited PM as an influence. The connection is genetic, not metaphorical. - -Whitehead's process philosophy is a metaphysics of /becoming/ rather than /being/. The fundamental entities are not substances but /processes/ (/actual entities/, /occasions of experience/). This maps precisely to Passepartout's pipeline architecture: - -| Whiteheadian Concept | Passepartout Mapping | Significance | -|----------------------------------+---------------------------------------------+--------------------------------------------------| -| Actual entity (actual occasion) | An event/signal in the pipeline | The fundamental unit — everything else is abstraction | -| Prehension | A gate's grasping of a signal | How one entity "takes account of" another | -| Positive prehension | A gate passing a signal | The signal is included in the concrescence | -| Negative prehension | A gate rejecting a signal | The signal is excluded from the concrescence | -| Concrescence | The pipeline process from input to output | Many prehensions → one satisfaction | -| Subjective aim | The agent's active goal / plan | The telos directing which prehensions matter | -| Eternal objects | Pure concepts in the knowledge graph | Universals — types, functions, categories | -| Nexus | A cluster of related memory objects | A Merkle subtree | -| Satisfaction | The final agent response | The "completed" entity — determinate output | -| Transition | From one signal to the next | The pipeline's forward motion | -| Causal efficacy | The agent's past context (memory) | What is prehended from the settled past | -| Presentational immediacy | The current signal (user input) | What is prehended from the immediate present | - -The foveal-peripheral model maps directly onto Whitehead's two modes of perception: /presentational immediacy/ is foveal focus on the current signal (vivid but superficial), while /causal efficacy/ is peripheral context from memory (dim but causally powerful). Whitehead argues that all perception is the "mixed mode" of symbolic reference — the synthesis of the two. Passepartout's ~think()~ function does exactly this: it synthesizes the current signal with context from memory into a response. - -Whitehead also gives Passepartout a /descriptive vocabulary/ that is precise, standard, and already maps perfectly to the design. "I am concrescing signal 47 through gates 0-8" is not poetry — it is a precise description of dispatcher operation. "Gate 3 has negatively prehended signal 136" means the secret-content gate rejected signal 136. "The satisfaction includes a file-write prehension with Merkle commit abc123" means the response contains a file write with the given Merkle hash. The agent uses this vocabulary in its ~/why~ output and in the ARCHITECTURE.org documentation. - -Not everything is useful. PM's full formalism — 300+ pages to prove ~1+1=2~ — is catastrophic as a reasoning engine. The /ideas/ (type theory, descriptions, propositional functions) are what matter, not the notation. Similarly, Whitehead's later concept of God (the "principle of concretion") and the full 25-category metaphysical system have no useful mapping to an agent architecture. Select the concepts that map; don't build a process-philosophy engine. - -Passepartout is level 4 neuro-symbolic (symbolic gates + neural LLM, deterministic components coordinate heterogeneous systems). PM's type theory adds level-5 properties: /structural/ safety guarantees rather than /empirical/ ones. The dispatcher becomes not just a runtime gate stack but a type-theoretic framework where category errors are impossible by construction — just as PM made Russell's paradox impossible by construction. The Whiteheadian vocabulary reinforces the architectural identity: Passepartout is not a chatbot with safety checks. It is a /process/ — a continuous concrescence of prehensions producing satisfactions — whose safety is guaranteed by the type structure of the prehending entities. - -** Historical Lineage — McCarthy's Advice Taker -:PROPERTIES: -:ID: design-mccarthy -:CREATED: [2026-05-10 Sun] -:END: - -McCarthy's "Programs with Common Sense" (1959) is the direct intellectual ancestor of the Passepartout architecture. The paper proposed an "advice taker" — a program that "will draw immediate conclusions from a list of premises" expressed in "a suitable formal language (most likely a part of the predicate calculus)." The program would: - -1. Accept declarative statements about the world as input. -2. Store them as logical formulas. -3. Reason from them to produce new conclusions. -4. Accept new facts and revise its conclusions. - -This is precisely the Passepartout pipeline: the archivist extracts declarative facts from prose → Screamer checks them for consistency → VivaceGraph stores them → the planner reasons from them → new facts from gate outcomes and deductions revise the store. McCarthy proposed it in 1959. Passepartout is building it in 2026. - -The gap between McCarthy's proposal and Passepartout's implementation is the /hallucination problem/. McCarthy assumed facts would be entered by a human programmer in formal logic. Passepartout's facts are extracted from natural language prose by an LLM — a probabilistic process that requires deterministic verification. Screamer is the component McCarthy didn't need: a constraint solver that gates LLM-proposed facts against the existing fact store. - -The connection is not metaphorical. McCarthy cited /Principia Mathematica/ as an influence on Lisp. Passepartout's Whitehead analysis traces the same PM → Lisp lineage. The advice taker → Passepartout lineage completes the arc: PM's formal logic → Lisp → McCarthy's advice taker → Passepartout's neurosymbolic engine. - -Reference: McCarthy, J. (1959). Programs with Common Sense. /Proceedings of the Teddington Conference on the Mechanization of Thought Processes./ - -** Marcus (2020): The Case Against Pure Deep Learning - -Gary Marcus's "The Next Decade in AI" argues that deep learning alone is "data hungry, shallow, brittle, and limited in its ability to generalize." The paper demonstrates GPT-2 failing at basic commonsense reasoning: - -- "Yesterday I dropped my clothes off at the dry cleaners and have yet to pick them up. Where are my clothes?" → GPT-2: "at my mom's house." -- "There are six frogs on a log. Two leave, but three join. The number of frogs on the log is now" → GPT-2: "seventeen." - -Marcus proposes four steps toward robust AI: hybrid architecture (combining neural and symbolic), large-scale knowledge (abstract and causal, not just statistical), reasoning (formal inference over structured representations), and cognitive models (frameworks for how entities relate). Passepartout implements all four: the perceive-reason-act pipeline is hybrid, the symbolic index is causal knowledge, Screamer + ACL2 provide reasoning, and the gate-bootstrapped ontology plus MOMo modules provide cognitive models. - -Marcus's core claim — "we have no hope of achieving robust intelligence without first developing systems with deep understanding" — is the justification for Passepartout's entire neurosymbolic investment. The alternative is a system that works "on a good day" and fails unpredictably. The deterministic gate stack and Screamer admission gate are the engineering realization of Marcus's call for robustness. - -Reference: Marcus, G. (2020). The Next Decade in AI: Four Steps Towards Robust Artificial Intelligence. arXiv:2002.06177. - -** Gaur & Sheth (2023): CREST — Trustworthy Neurosymbolic AI - -Gaur and Sheth present the CREST framework: Consistency, Reliability, user-level Explainability, and Safety build Trust — and they argue these require neurosymbolic methods. Their empirical finding: GPT-3.5 breached safety constraints 30% of the time when asked identical questions repeatedly. Claude's 16 safety rules and Sparrow's 23 rules provide no /inherent/ safety — they are heuristic guardrails that can be breached through prompt variation. - -These findings validate three Passepartout design commitments: (1) prompt-level safety is insufficient — deterministic gates run in pure Lisp, cost 0 tokens, and cannot be evaded by prompt engineering; (2) inconsistency is the norm — the cardinality model expects contradiction and surfaces it with provenance; (3) knowledge infusion is required for trust — Passepartout's symbolic index IS the knowledge infusion layer, facts extracted from prose, verified by Screamer, and available for any LLM call. - -Reference: Gaur, M., & Sheth, A. (2023). Building Trustworthy NeuroSymbolic AI Systems: Consistency, Reliability, Explainability, and Safety. arXiv:2312.06798. - -** Sheth et al. (2022): Knowledge-Infused Learning - -Sheth, Gunaratna, Bhatt, and Gaur define Knowledge-infused Learning (KiL) as "combining various types of explicit knowledge with data-driven deep learning techniques." They identify three infusion levels (shallow, semi-deep, deep) and position KiL as "a sweet spot in neuro-symbolic AI." - -Passepartout's architecture is a specific implementation of KiL at the deepest infusion level: knowledge is not appended to prompts (shallow) or embedded in fine-tuning (semi-deep). It is a first-class data structure — the symbolic index — that the LLM queries through the archivist and the planner. The knowledge is living: it accumulates, is verified, carries provenance, and evolves through ontology versioning. - -Reference: Gaur, M., Gunaratna, K., Bhatt, S., & Sheth, A. (2022). Knowledge-Infused Learning: A Sweet Spot in Neuro-Symbolic AI. /IEEE Internet Computing, 26/(4), 5–11. - -** The Competitive Argument -:PROPERTIES: -:ID: design-competitive -:CREATED: [2026-05-10 Sun] -:END: - -No competitor has this problem because no competitor has a symbolic engine. The 55 systems surveyed in the competitive landscape range from pure chat agents (Claude, ChatGPT) to agent harnesses (Claude Code, OpenCode, Hermes) to platform agents (OpenClaw). None of them encode knowledge as formal facts with provenance. None of them verify extractions against an existing knowledge base. None of them can prove properties about their own rulesets. - -Their safety is heuristic (prompt-based guardrails that consume LLM tokens and can be evaded with clever phrasing). Their memory is flat (JSONL transcripts without content-addressed identity or provenance chains). Their reasoning is entirely neural — when you ask "why did you decide that?", the answer is a regenerated LLM explanation, not a retrieved inference chain. - -Passepartout's architectural bet is that this problem is worth solving — that a system which can surface contradictions with provenance, derive new facts from observations, and verify claims against a provenanced knowledge graph is fundamentally different from a system that can only call an LLM and hope the response is correct. - -The cost is the ontological work that is genuinely difficult. The reward is a system that cannot hallucinate at the reasoning level, whose memory is provable rather than empirical, and whose knowledge accumulates across sessions through deduction rather than through LLM re-prompting. For a life's knowledge stored in a personal memex, this is not a performance advantage. It is a category difference. - -The competitive advantage is not any single feature. It is the architecture's ability to accumulate verified knowledge from four independent sources (gates, deduction, verified LLM proposals, human authoring) and to make that knowledge queryable with provenance. Competitors accumulate chat transcripts. Passepartout accumulates a provenanced, self-verifying knowledge graph. Transcripts become stale and unreliable. The knowledge graph becomes richer and more trustworthy with every session. - -* Open Questions - -** Open Questions -:PROPERTIES: -:ID: design-open-questions -:CREATED: [2026-05-08 Fri] -:END: - -Several design questions are unresolved and should remain unresolved at this stage. They represent research decisions that require experience running the system. - -*** What is the minimum viable fact language? - -Triples — =(:entity :relation :value)= with provenance and grounding — is the current hypothesis. It is simple enough to be parseable, expressive enough to capture the gate stack's implicit claims, and extensible enough that Screamer can operate on it. But it may be too simple. Triples do not naturally express temporal relations ("was X before Y?"), modal claims ("should not do X unless Y"), or counterfactuals — all of which may be essential for a symbolically-aided memex. The right granularity depends on what queries actually need to be made, and that cannot be known in advance. - -*** How does ontology refactoring work? - -This question is settled. See "Ontology Versioning" above. The category hierarchy is Merkle-hashed. Every fact stores its =:ontology-version=. Re-verification is heartbeat-driven. Worldviews are preserved, not overwritten. The shift is the artifact. - -*** What is the appropriate role of the human? - -The human can explicitly declare facts, write constraints, and correct wrong extractions. But how much of the ontology should the human need to maintain? If the human must write a definition for every new category the symbolic engine encounters, the overhead is prohibitive. If the symbolic engine can generalize from instances, the human role becomes supervision rather than authorship — review and approve proposed generalizations. The balance cannot be set without experience. - -*** How much Wikidata is the right amount? - -Query performance and memory costs are now bounded — 5 million entities ≈ 400MB RAM, O(1) hash lookups, domain-scoped Screamer checks. A large Wikidata load is a capital cost, not a recurring bill (see "Performance" above). - -Remaining open: the right N hops from entities referenced in the memex depends on the memex's breadth. A software-engineering memex needs ~1 hop; a literary memex needs 3-4 hops (Nabokov → Kafka → expressionism → modernism → Baudelaire). The right value is empirical, testable, and user-specific — it cannot be set in the architecture. - -*** Can the symbolic engine satisfy queries from the user without LLM involvement? - -The design aims for zero-LLM query answering: the user issues a structured command (=/query=, =/contradictions=, =/audit=), and the symbolic engine responds directly. But natural language questions ("what do I think about monorepos?") still require the LLM as a thin translation layer. Whether the structured command interface is sufficient for daily use, or whether users will demand natural language interaction, determines how much LLM involvement remains in the mature system. - -*** Is the triplestore physically bounded or does it explode? - -A personal memex with years of diary entries, project notes, reading logs, and literary analyses could produce millions of triples. A naive hash table scales linearly but VivaceGraph's Prolog-like queries may not. The performance characteristics of graph queries over a million-triple knowledge base have not been estimated. - -* Relation to Passepartout's Existing Architecture - -The neurosymbolic engine is an extension of the existing probabilistic-deterministic split, not a replacement for it. The current architecture divides cognition into LLM-driven proposals and Lisp-driven verification. The symbolic engine deepens the verification side from "is this action safe?" to "is this claim supported?" — the same architectural pattern applied to a broader domain. - -The self-repair criterion (a file belongs in core only if, when corrupted, the agent cannot fix it without human help) applies to every component of the symbolic engine. Screamer, VivaceGraph, the fact store, the archivist — all are skills, loaded at runtime, hot-reloadable, and recoverable from corruption. A corrupted symbolic engine degrades reasoning capability but does not kill the agent. The eight existing core ASDF files are unchanged. - -The symbolic engine is not v1.0.0 alone. It is the layer that sits between the existing gate stack (which it makes explicit as facts) and the existing skill system (which it extends with deduction, contradiction detection, and provenance tracking). It grows within the current architecture without replacing any existing component. - -See also: -- =ROADMAP.org= — the concrete phased implementation plan (neurosymbolic phases at v0.10.0 through v0.36.0) -- =ARCHITECTURE.org= — the current pipeline architecture -- =docs/DESIGN_DECISIONS.org#validation= — Whitehead analysis (now integrated into this document) -- =notes/passepartout-symbolic-engine-exploration.org= — the original architecture exploration -- =notes/competitive-landscape.org= — 55-system competitive survey - diff --git a/projects/passepartout/architecture/distinguishing-features.org b/projects/passepartout/architecture/distinguishing-features.org index ec9e3ec..d4032ec 100644 --- a/projects/passepartout/architecture/distinguishing-features.org +++ b/projects/passepartout/architecture/distinguishing-features.org @@ -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** diff --git a/projects/passepartout/architecture/faster-theorem-proving.org b/projects/passepartout/architecture/faster-theorem-proving.org index 977a362..311eec4 100644 --- a/projects/passepartout/architecture/faster-theorem-proving.org +++ b/projects/passepartout/architecture/faster-theorem-proving.org @@ -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 diff --git a/projects/passepartout/architecture/knowledge-layers/_index.org b/projects/passepartout/architecture/knowledge-layers/_index.org new file mode 100644 index 0000000..6eb65ff --- /dev/null +++ b/projects/passepartout/architecture/knowledge-layers/_index.org @@ -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 diff --git a/projects/passepartout/architecture/three-pronged/neurological-software-empirical-middle.org b/projects/passepartout/architecture/knowledge-layers/neurological-empirical.org similarity index 98% rename from projects/passepartout/architecture/three-pronged/neurological-software-empirical-middle.org rename to projects/passepartout/architecture/knowledge-layers/neurological-empirical.org index 46fd280..e19491c 100644 --- a/projects/passepartout/architecture/three-pronged/neurological-software-empirical-middle.org +++ b/projects/passepartout/architecture/knowledge-layers/neurological-empirical.org @@ -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. diff --git a/projects/passepartout/architecture/knowledge-layers/practical-implications.org b/projects/passepartout/architecture/knowledge-layers/practical-implications.org new file mode 100644 index 0000000..24e4749 --- /dev/null +++ b/projects/passepartout/architecture/knowledge-layers/practical-implications.org @@ -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 diff --git a/projects/passepartout/architecture/lisp-foundation.org b/projects/passepartout/architecture/lisp-foundation.org new file mode 100644 index 0000000..fc9d3d4 --- /dev/null +++ b/projects/passepartout/architecture/lisp-foundation.org @@ -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 diff --git a/projects/passepartout/architecture/neuro-neuromorphic-symbolic-comparison.org b/projects/passepartout/architecture/neuro-neuromorphic-symbolic-comparison.org index 327f92b..c2c01cb 100644 --- a/projects/passepartout/architecture/neuro-neuromorphic-symbolic-comparison.org +++ b/projects/passepartout/architecture/neuro-neuromorphic-symbolic-comparison.org @@ -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** diff --git a/projects/passepartout/architecture/security.org b/projects/passepartout/architecture/security.org index b46b76a..3d7749f 100644 --- a/projects/passepartout/architecture/security.org +++ b/projects/passepartout/architecture/security.org @@ -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. diff --git a/projects/passepartout/architecture/self-developing.org b/projects/passepartout/architecture/self-developing.org deleted file mode 100644 index 868765b..0000000 --- a/projects/passepartout/architecture/self-developing.org +++ /dev/null @@ -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. diff --git a/projects/passepartout/architecture/stages/stage-0-now.org b/projects/passepartout/architecture/stages/stage-0-now.org index 74eb0bc..9fa48c6 100644 --- a/projects/passepartout/architecture/stages/stage-0-now.org +++ b/projects/passepartout/architecture/stages/stage-0-now.org @@ -1,5 +1,5 @@ --- -title: Stage 0 — Now (Conventional Computing) +title: Stage 0 type: reference tags: :passepartout:roadmap: created: 2026-05-24 diff --git a/projects/passepartout/architecture/stages/stage-1-dependency-map.org b/projects/passepartout/architecture/stages/stage-1-dependency-map.org index a5e7503..412f4a4 100644 --- a/projects/passepartout/architecture/stages/stage-1-dependency-map.org +++ b/projects/passepartout/architecture/stages/stage-1-dependency-map.org @@ -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 diff --git a/projects/passepartout/architecture/stages/stage-2-acl2-integration.org b/projects/passepartout/architecture/stages/stage-2-acl2-integration.org index 69d1f4e..bb6f0d4 100644 --- a/projects/passepartout/architecture/stages/stage-2-acl2-integration.org +++ b/projects/passepartout/architecture/stages/stage-2-acl2-integration.org @@ -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 diff --git a/projects/passepartout/architecture/stages/stage-2-verification.org b/projects/passepartout/architecture/stages/stage-2-verification.org index ffb295b..449b3b0 100644 --- a/projects/passepartout/architecture/stages/stage-2-verification.org +++ b/projects/passepartout/architecture/stages/stage-2-verification.org @@ -1,5 +1,5 @@ --- -title: Stage 2 — Verification Subsystem +title: Stage 2 type: reference tags: :passepartout:roadmap: created: 2026-05-24 diff --git a/projects/passepartout/architecture/stages/stage-3-lisp-machine.org b/projects/passepartout/architecture/stages/stage-3-lisp-machine.org index b89a730..20659ba 100644 --- a/projects/passepartout/architecture/stages/stage-3-lisp-machine.org +++ b/projects/passepartout/architecture/stages/stage-3-lisp-machine.org @@ -1,5 +1,5 @@ --- -title: Stage 3 — Lisp Machine +title: Stage 3 type: reference tags: :passepartout:roadmap: created: 2026-05-24 diff --git a/projects/passepartout/architecture/stages/stage-4-inference.org b/projects/passepartout/architecture/stages/stage-4-inference.org index 0decdc6..d064e3a 100644 --- a/projects/passepartout/architecture/stages/stage-4-inference.org +++ b/projects/passepartout/architecture/stages/stage-4-inference.org @@ -1,5 +1,5 @@ --- -title: Stage 4 — Inference (In-Process LLM) +title: Stage 4 type: reference tags: :passepartout:roadmap: created: 2026-05-24 diff --git a/projects/passepartout/architecture/stages/stage-5-weights.org b/projects/passepartout/architecture/stages/stage-5-weights.org index 27bff45..42e02a8 100644 --- a/projects/passepartout/architecture/stages/stage-5-weights.org +++ b/projects/passepartout/architecture/stages/stage-5-weights.org @@ -1,5 +1,5 @@ --- -title: Stage 5 — Weights (Plist-Native) +title: Stage 5 type: reference tags: :passepartout:roadmap: created: 2026-05-24 diff --git a/projects/passepartout/architecture/stages/stage-6-training.org b/projects/passepartout/architecture/stages/stage-6-training.org index 903a02a..c6de43e 100644 --- a/projects/passepartout/architecture/stages/stage-6-training.org +++ b/projects/passepartout/architecture/stages/stage-6-training.org @@ -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 diff --git a/projects/passepartout/architecture/stages/stage-7-remaining.org b/projects/passepartout/architecture/stages/stage-7-remaining.org index 3bf3002..85f6312 100644 --- a/projects/passepartout/architecture/stages/stage-7-remaining.org +++ b/projects/passepartout/architecture/stages/stage-7-remaining.org @@ -1,5 +1,5 @@ --- -title: Stage 7 — What Remains +title: Stage 7 type: reference tags: :passepartout:roadmap: created: 2026-05-24 diff --git a/projects/passepartout/architecture/systemic-effects.org b/projects/passepartout/architecture/systemic-effects.org index f21a6fe..13c71f7 100644 --- a/projects/passepartout/architecture/systemic-effects.org +++ b/projects/passepartout/architecture/systemic-effects.org @@ -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. diff --git a/projects/passepartout/architecture/three-pronged/_index.org b/projects/passepartout/architecture/three-pronged/_index.org deleted file mode 100644 index c2714dc..0000000 --- a/projects/passepartout/architecture/three-pronged/_index.org +++ /dev/null @@ -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 - diff --git a/projects/passepartout/architecture/three-pronged/architectural-integration-three-pronged.org b/projects/passepartout/architecture/three-pronged/architectural-integration-three-pronged.org deleted file mode 100644 index 73a964c..0000000 --- a/projects/passepartout/architecture/three-pronged/architectural-integration-three-pronged.org +++ /dev/null @@ -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. diff --git a/projects/passepartout/architecture/three-pronged/knowledge-tree-middle.org b/projects/passepartout/architecture/three-pronged/knowledge-tree-middle.org deleted file mode 100644 index 37f688d..0000000 --- a/projects/passepartout/architecture/three-pronged/knowledge-tree-middle.org +++ /dev/null @@ -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 diff --git a/projects/passepartout/architecture/three-pronged/practical-powers-three-pronged.org b/projects/passepartout/architecture/three-pronged/practical-powers-three-pronged.org deleted file mode 100644 index 387dd79..0000000 --- a/projects/passepartout/architecture/three-pronged/practical-powers-three-pronged.org +++ /dev/null @@ -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. diff --git a/projects/passepartout/architecture/three-pronged/wider-implications-three-pronged.org b/projects/passepartout/architecture/three-pronged/wider-implications-three-pronged.org deleted file mode 100644 index 8e7528b..0000000 --- a/projects/passepartout/architecture/three-pronged/wider-implications-three-pronged.org +++ /dev/null @@ -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. diff --git a/projects/passepartout/architecture/three-pronged/world-models-middle-domain.org b/projects/passepartout/architecture/three-pronged/world-models-middle-domain.org deleted file mode 100644 index 51d6766..0000000 --- a/projects/passepartout/architecture/three-pronged/world-models-middle-domain.org +++ /dev/null @@ -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 diff --git a/projects/passepartout/architecture/three-pronged/world-models-plain-language.org b/projects/passepartout/architecture/three-pronged/world-models-plain-language.org deleted file mode 100644 index 02d4d23..0000000 --- a/projects/passepartout/architecture/three-pronged/world-models-plain-language.org +++ /dev/null @@ -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. diff --git a/projects/passepartout/common-logic-iso-24707.org b/projects/passepartout/common-logic-iso-24707.org index 95ac6f0..bdb6fb7 100644 --- a/projects/passepartout/common-logic-iso-24707.org +++ b/projects/passepartout/common-logic-iso-24707.org @@ -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. diff --git a/projects/passepartout/hardware/server-build-bom.org b/projects/passepartout/hardware/server-build-bom.org index 953c86c..4838de2 100644 --- a/projects/passepartout/hardware/server-build-bom.org +++ b/projects/passepartout/hardware/server-build-bom.org @@ -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** diff --git a/projects/passepartout/hardware/server-rack-build.org b/projects/passepartout/hardware/server-rack-build.org index eb30a78..dd553e7 100644 --- a/projects/passepartout/hardware/server-rack-build.org +++ b/projects/passepartout/hardware/server-rack-build.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-00-readme.org b/projects/passepartout/social-protocol/requirements-00-readme.org index 80cd271..681b56e 100644 --- a/projects/passepartout/social-protocol/requirements-00-readme.org +++ b/projects/passepartout/social-protocol/requirements-00-readme.org @@ -1,4 +1,4 @@ -#+title: Social Protocol: Decentralized Social Network +#+title: Social Protocol #+AUTHOR: Amr #+CREATED: [2026-03-17 Tue] #+BEGIN_COMMENT diff --git a/projects/passepartout/social-protocol/requirements-01-overview.org b/projects/passepartout/social-protocol/requirements-01-overview.org index 846d434..945dafd 100644 --- a/projects/passepartout/social-protocol/requirements-01-overview.org +++ b/projects/passepartout/social-protocol/requirements-01-overview.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-02-identity.org b/projects/passepartout/social-protocol/requirements-02-identity.org index 640dfc2..cf249ac 100644 --- a/projects/passepartout/social-protocol/requirements-02-identity.org +++ b/projects/passepartout/social-protocol/requirements-02-identity.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-03-infrastructure.org b/projects/passepartout/social-protocol/requirements-03-infrastructure.org index 0ff852e..d746f94 100644 --- a/projects/passepartout/social-protocol/requirements-03-infrastructure.org +++ b/projects/passepartout/social-protocol/requirements-03-infrastructure.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-04-the-primitive.org b/projects/passepartout/social-protocol/requirements-04-the-primitive.org index beaa7b1..6c4b035 100644 --- a/projects/passepartout/social-protocol/requirements-04-the-primitive.org +++ b/projects/passepartout/social-protocol/requirements-04-the-primitive.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-05-social.org b/projects/passepartout/social-protocol/requirements-05-social.org index d72462c..bac1c57 100644 --- a/projects/passepartout/social-protocol/requirements-05-social.org +++ b/projects/passepartout/social-protocol/requirements-05-social.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-06-exchange-and-contracts.org b/projects/passepartout/social-protocol/requirements-06-exchange-and-contracts.org index 458b052..e8ace3c 100644 --- a/projects/passepartout/social-protocol/requirements-06-exchange-and-contracts.org +++ b/projects/passepartout/social-protocol/requirements-06-exchange-and-contracts.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-07-advanced-integration.org b/projects/passepartout/social-protocol/requirements-07-advanced-integration.org index 01d9560..9843dfa 100644 --- a/projects/passepartout/social-protocol/requirements-07-advanced-integration.org +++ b/projects/passepartout/social-protocol/requirements-07-advanced-integration.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-08-library.org b/projects/passepartout/social-protocol/requirements-08-library.org index d84e144..b0ebf08 100644 --- a/projects/passepartout/social-protocol/requirements-08-library.org +++ b/projects/passepartout/social-protocol/requirements-08-library.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-09-implementation.org b/projects/passepartout/social-protocol/requirements-09-implementation.org index de0ce4e..fc3084e 100644 --- a/projects/passepartout/social-protocol/requirements-09-implementation.org +++ b/projects/passepartout/social-protocol/requirements-09-implementation.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-10-governance-and-assets.org b/projects/passepartout/social-protocol/requirements-10-governance-and-assets.org index 8408906..d6c3d78 100644 --- a/projects/passepartout/social-protocol/requirements-10-governance-and-assets.org +++ b/projects/passepartout/social-protocol/requirements-10-governance-and-assets.org @@ -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 diff --git a/projects/passepartout/social-protocol/requirements-10-user-journey.org b/projects/passepartout/social-protocol/requirements-10-user-journey.org index 23f9aa3..57926c2 100644 --- a/projects/passepartout/social-protocol/requirements-10-user-journey.org +++ b/projects/passepartout/social-protocol/requirements-10-user-journey.org @@ -1,4 +1,4 @@ -#+title: Social Protocol Requirements: User Journey & Product Experience +#+title: Social Protocol Requirements #+AUTHOR: Passepartout Social Protocol #+DATE: 2026-03-26 diff --git a/projects/passepartout/social-protocol/requirements-11-assessment.org b/projects/passepartout/social-protocol/requirements-11-assessment.org index 5ecf856..4c019ac 100644 --- a/projects/passepartout/social-protocol/requirements-11-assessment.org +++ b/projects/passepartout/social-protocol/requirements-11-assessment.org @@ -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 diff --git a/projects/passepartout/strategy/competitors/ai-agents-scoping/aider.org b/projects/passepartout/strategy/competitors/ai-agents-scoping/aider.org index e5d30f9..819060f 100644 --- a/projects/passepartout/strategy/competitors/ai-agents-scoping/aider.org +++ b/projects/passepartout/strategy/competitors/ai-agents-scoping/aider.org @@ -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. diff --git a/projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org b/projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org index 21bb539..801087c 100644 --- a/projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org +++ b/projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org @@ -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. diff --git a/projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org b/projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org index c9ef9c3..836f8e0 100644 --- a/projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org +++ b/projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org @@ -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. diff --git a/projects/passepartout/strategy/competitors/ai-agents-scoping/continue.org b/projects/passepartout/strategy/competitors/ai-agents-scoping/continue.org index eb1a6f8..782e66b 100644 --- a/projects/passepartout/strategy/competitors/ai-agents-scoping/continue.org +++ b/projects/passepartout/strategy/competitors/ai-agents-scoping/continue.org @@ -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. diff --git a/projects/passepartout/strategy/competitors/ai-agents-scoping/gemini-cli.org b/projects/passepartout/strategy/competitors/ai-agents-scoping/gemini-cli.org index 47d2356..faa1877 100644 --- a/projects/passepartout/strategy/competitors/ai-agents-scoping/gemini-cli.org +++ b/projects/passepartout/strategy/competitors/ai-agents-scoping/gemini-cli.org @@ -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. diff --git a/projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org b/projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org index a5fd615..c193512 100644 --- a/projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org +++ b/projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org @@ -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. diff --git a/projects/passepartout/strategy/competitors/ai-agents-scoping/openclaw.org b/projects/passepartout/strategy/competitors/ai-agents-scoping/openclaw.org index e3e3fcd..c84e9e0 100644 --- a/projects/passepartout/strategy/competitors/ai-agents-scoping/openclaw.org +++ b/projects/passepartout/strategy/competitors/ai-agents-scoping/openclaw.org @@ -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. diff --git a/projects/passepartout/strategy/competitors/ai-agents-scoping/opencode.org b/projects/passepartout/strategy/competitors/ai-agents-scoping/opencode.org index 0f6282a..2671279 100644 --- a/projects/passepartout/strategy/competitors/ai-agents-scoping/opencode.org +++ b/projects/passepartout/strategy/competitors/ai-agents-scoping/opencode.org @@ -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. diff --git a/projects/passepartout/strategy/competitors/ai-agents-scoping/thoth.org b/projects/passepartout/strategy/competitors/ai-agents-scoping/thoth.org index 6badb7b..65fda44 100644 --- a/projects/passepartout/strategy/competitors/ai-agents-scoping/thoth.org +++ b/projects/passepartout/strategy/competitors/ai-agents-scoping/thoth.org @@ -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. diff --git a/projects/passepartout/strategy/competitors/competitive-analysis.org b/projects/passepartout/strategy/competitors/competitive-analysis.org index f0190d3..f137f60 100644 --- a/projects/passepartout/strategy/competitors/competitive-analysis.org +++ b/projects/passepartout/strategy/competitors/competitive-analysis.org @@ -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 diff --git a/projects/passepartout/strategy/competitors/rainbird-ai-case-study.org b/projects/passepartout/strategy/competitors/rainbird-ai-case-study.org index 70577ba..fc5080b 100644 --- a/projects/passepartout/strategy/competitors/rainbird-ai-case-study.org +++ b/projects/passepartout/strategy/competitors/rainbird-ai-case-study.org @@ -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 diff --git a/projects/passepartout/strategy/compliance/compliance-regimes/appi.org b/projects/passepartout/strategy/compliance/compliance-regimes/appi.org index 36e5dbb..fbace8a 100644 --- a/projects/passepartout/strategy/compliance/compliance-regimes/appi.org +++ b/projects/passepartout/strategy/compliance/compliance-regimes/appi.org @@ -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: diff --git a/projects/passepartout/strategy/compliance/compliance-regimes/apra-cps-234.org b/projects/passepartout/strategy/compliance/compliance-regimes/apra-cps-234.org index 691f9a3..8024f6c 100644 --- a/projects/passepartout/strategy/compliance/compliance-regimes/apra-cps-234.org +++ b/projects/passepartout/strategy/compliance/compliance-regimes/apra-cps-234.org @@ -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) diff --git a/projects/passepartout/strategy/compliance/compliance-regimes/basel-iii.org b/projects/passepartout/strategy/compliance/compliance-regimes/basel-iii.org index 7ff9236..382d0c8 100644 --- a/projects/passepartout/strategy/compliance/compliance-regimes/basel-iii.org +++ b/projects/passepartout/strategy/compliance/compliance-regimes/basel-iii.org @@ -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) diff --git a/projects/passepartout/strategy/compliance/compliance-regimes/dpdp-act.org b/projects/passepartout/strategy/compliance/compliance-regimes/dpdp-act.org index 9163326..43abac7 100644 --- a/projects/passepartout/strategy/compliance/compliance-regimes/dpdp-act.org +++ b/projects/passepartout/strategy/compliance/compliance-regimes/dpdp-act.org @@ -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: diff --git a/projects/passepartout/strategy/compliance/compliance-regimes/irap.org b/projects/passepartout/strategy/compliance/compliance-regimes/irap.org index 122b94f..5a3eb8d 100644 --- a/projects/passepartout/strategy/compliance/compliance-regimes/irap.org +++ b/projects/passepartout/strategy/compliance/compliance-regimes/irap.org @@ -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: diff --git a/projects/passepartout/strategy/compliance/compliance-regimes/ismap.org b/projects/passepartout/strategy/compliance/compliance-regimes/ismap.org index ca8f0c9..da6056b 100644 --- a/projects/passepartout/strategy/compliance/compliance-regimes/ismap.org +++ b/projects/passepartout/strategy/compliance/compliance-regimes/ismap.org @@ -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 diff --git a/projects/passepartout/strategy/compliance/compliance-regimes/lfp-dppp.org b/projects/passepartout/strategy/compliance/compliance-regimes/lfp-dppp.org index 7c0c134..bc665fe 100644 --- a/projects/passepartout/strategy/compliance/compliance-regimes/lfp-dppp.org +++ b/projects/passepartout/strategy/compliance/compliance-regimes/lfp-dppp.org @@ -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: diff --git a/projects/passepartout/strategy/compliance/compliance-regimes/lgpd.org b/projects/passepartout/strategy/compliance/compliance-regimes/lgpd.org index 7631754..3303cd5 100644 --- a/projects/passepartout/strategy/compliance/compliance-regimes/lgpd.org +++ b/projects/passepartout/strategy/compliance/compliance-regimes/lgpd.org @@ -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: diff --git a/projects/passepartout/strategy/compliance/compliance-regimes/pipa.org b/projects/passepartout/strategy/compliance/compliance-regimes/pipa.org index fcbafa6..2b7ce3e 100644 --- a/projects/passepartout/strategy/compliance/compliance-regimes/pipa.org +++ b/projects/passepartout/strategy/compliance/compliance-regimes/pipa.org @@ -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: diff --git a/projects/passepartout/strategy/domain-sequencing.org b/projects/passepartout/strategy/domain-sequencing.org index 75f03b8..c302af1 100644 --- a/projects/passepartout/strategy/domain-sequencing.org +++ b/projects/passepartout/strategy/domain-sequencing.org @@ -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. diff --git a/projects/passepartout/strategy/hosting-economics.org b/projects/passepartout/strategy/hosting-economics.org index 2e67f42..938ac34 100644 --- a/projects/passepartout/strategy/hosting-economics.org +++ b/projects/passepartout/strategy/hosting-economics.org @@ -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 diff --git a/projects/passepartout/strategy/impact/phase-0-impact.org b/projects/passepartout/strategy/impact/phase-0-impact.org index ee78ec6..b9d041e 100644 --- a/projects/passepartout/strategy/impact/phase-0-impact.org +++ b/projects/passepartout/strategy/impact/phase-0-impact.org @@ -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. diff --git a/projects/passepartout/strategy/impact/phase-1-impact.org b/projects/passepartout/strategy/impact/phase-1-impact.org index 8cdb061..fac4e3a 100644 --- a/projects/passepartout/strategy/impact/phase-1-impact.org +++ b/projects/passepartout/strategy/impact/phase-1-impact.org @@ -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 diff --git a/projects/passepartout/strategy/impact/phase-2-impact.org b/projects/passepartout/strategy/impact/phase-2-impact.org index 3047a2a..d7e95cb 100644 --- a/projects/passepartout/strategy/impact/phase-2-impact.org +++ b/projects/passepartout/strategy/impact/phase-2-impact.org @@ -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 diff --git a/projects/passepartout/strategy/impact/phase-3-impact.org b/projects/passepartout/strategy/impact/phase-3-impact.org index 4d35714..098b83a 100644 --- a/projects/passepartout/strategy/impact/phase-3-impact.org +++ b/projects/passepartout/strategy/impact/phase-3-impact.org @@ -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 diff --git a/projects/passepartout/strategy/impact/phase-4-impact.org b/projects/passepartout/strategy/impact/phase-4-impact.org index fe311b3..e6056af 100644 --- a/projects/passepartout/strategy/impact/phase-4-impact.org +++ b/projects/passepartout/strategy/impact/phase-4-impact.org @@ -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 diff --git a/resources/neurosymbolic.org b/resources/neurosymbolic.org index 6a07d43..4f00a86 100644 --- a/resources/neurosymbolic.org +++ b/resources/neurosymbolic.org @@ -2,7 +2,7 @@ :CREATED: [2026-05-27 Wed] :ID: ee8f3b2a-4c7d-4e1b-9b0a-6d8f2e3c1a5b :END: -#+title: Neurosymbolic AI — Paper Library +#+title: Neurosymbolic AI #+filetags: :resources:neurosymbolic:papers:survey: Local library of recent neurosymbolic AI papers, updated monthly from arXiv. Papers are downloaded in PDF format and cataloged below. diff --git a/resources/worse-is-better.org b/resources/worse-is-better.org index bc8b4b5..429c6a7 100644 --- a/resources/worse-is-better.org +++ b/resources/worse-is-better.org @@ -2,7 +2,7 @@ :CREATED: [2026-05-27 Wed] :ID: 09a03e7f-c3f8-438a-abe3-7a7570957565 :END: -#+title: Worse is Better — Reference Articles +#+title: Worse is Better #+filetags: :resources:worse-is-better:gabriel:graham:lisp: Collection of the canonical articles in the Worse is Better debate, saved as local resources. See [[id:dddd52a7-adb8-470e-a459-614ade5f76af][Closing the Lisp Gap]] for the strategic analysis in context of Passepartout.