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

Compare commits

base: amr:0821b2b10a99450de1b7c79df884bfbc2f72f82c
Branches Tags
amr:master
..
compare: amr:master
Branches Tags
amr:master

114 Commits
0821b2b10a ... master

Author SHA1 Message Date
Hermes
67fac2444b Fix Untitled titles: convert all YAML frontmatter to org-style headers 2026-06-04 20:56:03 +00:00
Hermes
284c5bd324 Break design/ files into subfolders by ** heading (43 new files) 2026-06-04 20:47:17 +00:00
Hermes
9ce3883005 Remove old design-decisions.org, update cross-refs to design/ folder 2026-06-04 20:24:17 +00:00
Hermes
2ee60b5b4a Split design-decisions.org into design/ subfolder (10 files, one per section) 2026-06-04 20:16:02 +00:00
Hermes
d938f353e4 Fix stage weights: Lisp Machine 13, AI Inference 14 2026-06-04 20:07:49 +00:00
Hermes
8b1b481828 Stages: rename titles, fix execution order, remove all numbered references 2026-06-04 20:04:34 +00:00
Hermes
5ac701e8ec Restage with descriptive titles: agent arc first, network arc second 
- New execution order: Now → Neurosymbolic Agent → Lisp Machine → AI Inference → Social Protocol → AI Weights → AI Training → What Remains
- Rename files to match (stage-1-gate, stage-2-lisp-machine, stage-3-inference, stage-4-social-protocol)
- Remove stage numbers from titles: just descriptive names
- Sequential weights 10-17
- Update nav links and stage table in _index.org and architecture _index.org
- Rebuild: 145 files, 0 errors
 2026-06-04 19:51:52 +00:00
Hermes
60e9c1d7a6 Reorder stages by execution order: 0 → 2 → 1 → 3 → 4 → 5 → 6 → 7 
- Update sidebar weights: Stage 2 (12) before Stage 1 (13)
- Update stage overview table in _index.org to match execution order
- Fix navigation links (← prev → next) in stage-1-social-protocol and stage-2-verification to reflect true execution sequence
- Rebuild: 145 files, 0 errors
 2026-06-04 19:47:31 +00:00
Hermes
0956711af4 Fold stage secondary docs into main pages: one note per stage 
- Merge stage-1-dependency-map.org (library tables) into stage-1-social-protocol.org
- Merge stage-2-acl2-integration.org (integration approaches, risk, PDS constraint) into stage-2-verification.org
- Delete both secondary files
- Regenerate ID map
- Rebuild: 145 files, 0 errors
- Sidebar now shows one page per stage: Stage 0-7
 2026-06-04 19:43:56 +00:00
Hermes
01bea0c982 Make Stage 0 the stages index: reader lands on 'now' with the full roadmap at a glance 
- Merge stage-0-now.org content into stages/_index.org (now titled 'Stage 0: Now')
- Delete stage-0-now.org
- Add stage overview table to the top of the page (8 stages, what changes, threat eliminated)
- Update all cross-references from old stage-0 UUID to stages _index UUID
- Regenerate ID map to reflect the deletion
- Also fix page-list shortcode: .ByTitle -> .ByWeight so subpage listing matches sidebar order
- Rebuild: 147 files, 0 errors
 2026-06-04 19:40:43 +00:00
Hermes
c5d0695acf Reorder architecture sidebar using weights: stages first, then foundation, epistemology, design, implications, reference 
- Add :WEIGHT: extraction to build script (from Org PROPERTIES into Hugo TOML frontmatter)
- Shorten architecture _index.org staged progression to a single-line summary pointing to stages/ directory
- Weight order (sidebar now reads in this order):
  stages/ (10-20) — the roadmap, early so references make sense
  lisp-foundation.org (21) — why Lisp
  knowledge-layers/ (30-32) — how the system knows
  design-decisions through neuro-comparison (40-45) — design
  systemic-effects (50) — implications
  org-knowledge-base through repo-organization (60-64) — reference
- Rebuild: 148 files, 0 errors
 2026-06-04 19:36:53 +00:00
Hermes
6e992cc0c5 Restructure three-pronged → knowledge-layers: collapse 11 files to 3, integrate into main architecture 
- Rename 'three-pronged' folder to 'knowledge-layers' — prong metaphor
  was misleading (implied parallel tines), replaced with epistemic layers
  (deductive base, empirical middle, probabilistic oracle — vertical stack)
- Collapse 11 overlapping files into 3 coherent documents:
  - knowledge-layers/_index.org: core framework (two engines + one store,
    World Model formula, 0-14 layer table, provenance store design,
    conflict resolution, cold-start, stage mapping)
  - knowledge-layers/practical-implications.org: design-world-aware-of-
    physics, 10 powers, Schafmeister existence proof, epistemic transparency
  - knowledge-layers/neurological-empirical.org: neural networks in
    provenance framework (kept intact)
- Relocate wolfram/mathematica and Schafmeister docs to ideas/viability/
- Integrate into main architecture _index.org:
  - Gate: expanded from two vectors (ACL2+LLM) to three (deductive,
    provenance/empirical, LLM oracle)
  - Autodidactic loop: split into Track 1 (deductive hardening, fast)
    and Track 2 (empirical validation, slow, experimental-feedback-driven)
  - See also: added Knowledge Layers cross-reference
- Add all-lisp geometry engine note (ideas/lisp-geometry-engine.org) as
  concrete illustration of the empirical layer's effect on design work
- Rebuild site: 148 files, 0 errors
 2026-06-04 19:09:44 +00:00
Hermes
2e8cf19f9e gbrain: sync converted org-mode brain files 2026-06-04 03:00:53 +00:00
Hermes
9b795df14e Add missing _index.org files for 7 sections: stages, ai-agents-scoping, compliance, impact, social-protocol, verification, resources — rebuild clean after file reorganization 2026-06-03 21:50:01 +00:00
Hermes
ac99eed182 Move three-pronged system series into projects/passepartout/architecture/three-pronged/ — all 11 architectural notes grouped under Passepartout architecture 2026-06-03 20:32:41 +00:00
Hermes
63279a995f Add note: faster theorem proving — engineering approaches (incremental, ATP oracle, decision procedures, LLM guidance, hardware split) 2026-06-03 20:08:39 +00:00
Hermes
dd8759179a Fix: GC constraint is silicon design focused on C, not a fundamental Lisp limitation — Symbolics Genera proved Lisp as systems language with proper hardware support 2026-06-03 19:37:16 +00:00
Hermes
a176eedd2b Rewrite lisp-provers page as evergreen reference — remove conversational framing, 'things I was wrong about', 'key insight from conversation' 2026-06-03 18:38:20 +00:00
Hermes
179bcbaaa4 Create CL Modernization project — merge initiatives, corrected phases, and timeline into single comprehensive project page under projects/ 2026-06-03 18:33:47 +00:00
Hermes
9553a90060 Unify concepts into ideas — move 7 org files from concepts/ to ideas/, update homepage and nav 2026-06-03 17:31:57 +00:00
Hermes
b1d00c79e6 Add Concepts section to homepage and nav, plus 4 new concept pages 2026-06-03 17:15:40 +00:00
Hermes
47be29b1d0 Add 4 new concept pages: Lisp vs Rust prover discussion, CL modernization initiative, corrected phases, timeline 2026-06-03 17:11:46 +00:00
Hermes
1f5fc89b46 gbrain: sync converted org-mode brain files 2026-06-03 03:06:39 +00:00
Hermes
56f0588b54 gbrain: sync converted org-mode brain files 2026-06-02 03:03:15 +00:00
Hermes
47ca8689fc gbrain: sync converted org-mode brain files 2026-06-01 03:03:11 +00:00
Hermes
5087f98e4d gbrain: sync converted org-mode brain files 2026-05-31 03:00:39 +00:00
Hermes
dbd651ba2c gbrain: sync converted org-mode brain files 2026-05-30 03:00:27 +00:00
Hermes
2f1aacd39c gbrain: sync converted org-mode brain files 2026-05-29 03:00:48 +00:00
Hermes
af132f7e88 gbrain: sync converted org-mode brain files 2026-05-28 03:01:01 +00:00
Hermes
3efbf760e6 gbrain: sync converted org-mode brain files 2026-05-27 03:00:59 +00:00
Hermes
7fa9dceb82 gbrain: sync converted org-mode brain files 2026-05-26 03:00:48 +00:00
Hermes
ed232e2122 gbrain: sync converted org-mode brain files 2026-05-25 03:00:38 +00:00
Hermes
386e6d40be rewrite ideas/_index.org with full page listing 2026-05-25 01:22:38 +00:00
Hermes
f8240967f5 update org-ids after build 2026-05-25 01:14:50 +00:00
Hermes
f10bd14091 add note: 10 wider implications of the three-pronged system 2026-05-25 00:56:05 +00:00
Hermes
a4113c2d5c add note: neural network models in the empirical middle 2026-05-25 00:48:30 +00:00
Hermes
0b77ea0ac9 add note: architectural integration of three-pronged system 2026-05-25 00:38:48 +00:00
Hermes
73fc33f02f add note: 10 practical powers of the three-pronged architecture 2026-05-25 00:26:49 +00:00
Hermes
f09a59aaf3 add plain-language explanation of world model implications 2026-05-25 00:17:49 +00:00
Hermes
6b6838fb2c add note: middle domain as world models — the Passepartout triple 2026-05-25 00:12:41 +00:00
Hermes
f3e2d15d47 add note: knowledge tree middle — logic to nanotechnology bridge 2026-05-24 23:59:30 +00:00
Hermes
cf3bd2ee54 add note: Passepartout bootstrapping Mathematica/mathlib autonomously 2026-05-24 23:55:38 +00:00
Hermes
d2387f1074 add note: viability of open-source Wolfram/Mathematica in Common Lisp 2026-05-24 22:54:02 +00:00
Hermes
64d027a0a0 add note: Schafmeister and Clasp — Lisp in computational nanotechnology 2026-05-24 21:05:07 +00:00
Hermes
5086ac4fbe project index: what+why only, no jargon without links; architecture: explain Lisp and ACL2 at first mention 2026-05-24 19:57:55 +00:00
Hermes
73dea1f654 rewrite project _index.org broader intro (Environment, Knowledge, Verification); add Knowledge subsystem to architecture page 2026-05-24 19:51:03 +00:00
Hermes
d3300adbf7 drop Passepartout prefix from section index titles: Architecture, Social Protocol, Strategy 2026-05-24 19:43:39 +00:00
Hermes
34ab923308 rewrite project _index.org as full narrative intro; rewrite architecture.org to lead with concepts before Lisp 2026-05-24 19:40:51 +00:00
Hermes
335735b655 Rewrite Passepartout architecture page as narrative introduction 
- architecture.org becomes a narrative: problem → three-subsystem solution
  → staged approach → what it means
- Moved TAM, revenue paths, analytical frames, strategy/IP links to _index.org
- _index.org is now the navigation hub with roadmap table and all catalog links
 2026-05-24 19:31:13 +00:00
Hermes
4c38127b45 Consolidate: 10 files merged into 5, 3 moves, 1 rename 
Merged:
- verification-monopoly + evaluation-harness + collective-regression-suite
- licensing + patent-strategy → strategy/
- moats + infrastructure-lock-in
- lisp-economics + cost-structure
- domain-gate-packages + gate-rule-encoding
- revenue-table + first-mover-window → revenue.org

Moved: sufficiency-flip, upgrade-lifecycle → strategy/
  native-org-knowledge-base → architecture/
Renamed: revenue-hub.org → revenue.org
Deleted: passepartout-economics.md orphan
 2026-05-24 19:17:01 +00:00
Hermes
ede891f2ce Merge verification-monopoly, evaluation-harness, collective-regression-suite into one page 
Combined all three under verification-monopoly.org with title:
'The Evaluation Harness — Collective Regression Suite as Certification Monopoly'
Structure: (1) vision from monopoly, (2) service from harness, (3) spec from collective-regression.
All three IDs preserved in PROPERTIES.
Deleted evaluation-harness.org and collective-regression-suite.org.
 2026-05-24 19:12:49 +00:00
Hermes
348f2736a8 Fix homepage headings: Org bold → proper headlines, H2 level 2026-05-24 18:57:59 +00:00
Hermes
0a8e77e949 Reorganize brain: projects/ top level, rename filenames, update homepage 
- Moved everything from ideas/passepartout/ to projects/passepartout/
- Moved legal structures to projects/flags/
- Created missing _index.org files for all subdirectories
- Stripped redundant passepartout- prefix from filenames
- Rewrote root _index.org as generalized brain index (projects + concepts)
- Updated Hugo nav to Projects/Concepts
- Updated build script section descriptions
- Deleted stale ideas/passepartout-economics.md orphan
 2026-05-24 18:54:14 +00:00
Hermes
4b60244919 Fix YAML frontmatter delimiter (|--- → ---) in stage 2 and 3 2026-05-24 18:07:14 +00:00
Hermes
2578bfee61 Architecture reframe: rename triad/Stoa/Logos/Agora → Passepartout 
- Renamed ideas/stoa/ → ideas/passepartout/, all stage files prefixed passepartout-
- Renamed triad-index/overview/systemic-effects → passepartout-* under passepartout/
- Renamed ideas/agora/ → ideas/passepartout-social-protocol/, stripped agora- prefixes
- Merged overview and environment pages into architecture; deleted 3 redundant files
- Renamed growth-strategy → enterprise-growth-strategy
- Renamed alternative-growth-social-first → social-growth-strategy
- Removed all Greek names: Stoa, Logos, Agora as product names
- Updated 50+ files of cross-references to new naming
- Kept org-id UUIDs intact throughout
 2026-05-24 18:02:36 +00:00
Hermes
cc3976fb7f ideas: editorial sweep — atomization, interlinking, restructuring 
- Split competitive-analysis-2026-05.org → TOC + 9 competitor files in
  ideas/competitors/. Dropped date from filename. All competitor UUIDs
  generated, TOC keeps original UUID for backlink continuity.
- Deleted passepartout-economics.org archive (replaced by 27-node KB).
- Inlined 5 'See also' blocks into natural prose (compliance-index,
  first-mover-window, revenue-table, orders-of-magnitude-time,
  native-org-knowledge-base).
- Linked 7 orphan compliance pages back to compliance index + finished
  truncated sentences.
- Linked all 14 Agora requirement docs from topic-relevant pages
  (identity→lisp-machine-security, infrastructure→compute-marketplace,
  social-space→growth-strategy, exchange→agora-contracts, etc.).
- Linked ai-industry-impact from investment-thesis, sufficiency-flip,
  verification-appliance, effects-growth-flywheel (up from 1 to 10+ pages).
- Fixed CREATED timestamps to use git commit dates instead of today.
- Made all links absolute from root (no port inheritance).
- Removed stale agora/docs/ duplicate content.
 2026-05-24 16:25:55 +00:00
Hermes
94f1871177 gbrain: sync converted org-mode brain files 2026-05-24 03:00:35 +00:00
Hermes
b3d91f2e55 fix: remove parenthetical (see ...) link pattern, use inline natural language links 2026-05-24 01:23:55 +00:00
Hermes
8f875dc192 fix: inline org-mode interlinks instead of parenthetical bare [[file:...]] links 2026-05-23 20:24:19 +00:00
Hermes
674b8b35ba feat: legal structure alternatives — Texas vs Delaware, Wyoming DAO LLC, Panama LLC, trust jurisdictions with downsides analysis 2026-05-23 15:10:53 +00:00
Hermes
6f67316681 feat: legal structure practical setup — Delaware C-Corp + BVI IP Co with forms, costs, timelines, and what must be done by a lawyer 2026-05-23 14:32:36 +00:00
Hermes
4a322ef5cd feat: asset protection structures research — Delaware C-Corp, BVI IP Co, series LLC, trust, with phased recommendations 2026-05-23 14:23:16 +00:00
Hermes
4d177832a1 feat: outbound sales compliance framework — CAN-SPAM, GDPR, UK GDPR, Egypt PDPL, CASL with Passepartout gate mappings 2026-05-23 14:19:22 +00:00
Hermes
59e9ced3e5 rewrite: combined growth strategy — Logos (top-down verification) + Agora (bottom-up communities) as two engines, one infrastructure 2026-05-23 14:01:43 +00:00
Hermes
89a9ee0c2c feat: Agora entry strategy — organized communities as primary entry point with 4-phase rollout 2026-05-23 13:57:27 +00:00
Hermes
f4c72d3527 rewrite: Agora competitive landscape — replaces 20+ centralized platforms across social, publishing, video, messaging, e-commerce, identity, and work 2026-05-23 13:16:39 +00:00
Hermes
ca9557a5f9 feat: Agora competitive landscape — 4-layer analysis (publishing, payments, contracts, identity) 2026-05-23 13:09:43 +00:00
Hermes
9f52f99092 update: correct Agora characterization as 4-layer unified platform (pub+pay+contract+identity) 2026-05-23 12:50:54 +00:00
Hermes
3a7fbb38ca feat: alternative social-first growth scenario 2026-05-23 12:19:38 +00:00
Hermes
04b2bf87dd fix: ** label:** → *label:* (inline bold, not headings) 2026-05-23 12:13:22 +00:00
Hermes
e1777d2538 Revert "fix: org-mode bold syntax — ** → * (double to single asterisk)" 
This reverts commit a0a1481cae.
 2026-05-23 12:11:16 +00:00
Hermes
a0a1481cae fix: org-mode bold syntax — ** → * (double to single asterisk) 2026-05-23 12:09:39 +00:00
Hermes
cddaaa4e69 gbrain: sync converted org-mode brain files 2026-05-23 11:57:03 +00:00
Hermes
dec20395b8 gbrain: sync converted org-mode brain files 2026-05-23 11:51:44 +00:00
Hermes
7c4eb5bf59 gbrain: sync converted org-mode brain files 2026-05-23 11:44:48 +00:00
Hermes
38f10960eb gbrain: sync converted org-mode brain files 2026-05-23 11:41:35 +00:00
Hermes
7b8bf3ca5b fix org-mode heading syntax in revenue-hub 2026-05-23 07:58:50 +00:00
Hermes
6da2633f11 gbrain: sync converted org-mode brain files 2026-05-23 07:49:47 +00:00
Hermes
558145741e gbrain: sync converted org-mode brain files 2026-05-23 07:43:55 +00:00
Hermes
536c44b6e8 gbrain: sync converted org-mode brain files 2026-05-23 07:10:05 +00:00
Hermes
9a95212d1a gbrain: sync converted org-mode brain files 2026-05-23 07:00:09 +00:00
Hermes
cf0c9b1f9d gbrain: sync converted org-mode brain files 2026-05-23 06:47:23 +00:00
Hermes
44299599f9 gbrain: sync converted org-mode brain files 2026-05-23 06:35:21 +00:00
Hermes
3f38e87f4f Remove versioned roadmap from Passepartout docs 
All version numbers stripped from roadmap across all brain documents:
- passepartout-economics.org: v0.x.x version table → phase-name-only table,
  v1.0.0 → 'neurosymbolic maturity', versioned text references → capability
  descriptions. Retained phase names (Phase 0-7) and line estimates as they
  describe capabilities, not version milestones.
- competitive-analysis-2026-05.org: version references removed
- time-estimates.org: v0.4.0 → 'initial state', v1.0.0 → 'neurosymbolic maturity'
- native-org-knowledge-base.org: v0.8.0-v0.9.0 → capability-based target
 2026-05-23 06:24:20 +00:00
Hermes
43c8c886e9 roadmap: Passepartout native Org-mode knowledge base 
Adds roadmap item for Passepartout to ingest and query org files
directly — no pandoc/gbrain bridge. Replaces the current org→md→gbrain
pipeline with native org parsing, heading-level vector embeddings,
property-based entity extraction, and org-id cross-references.
Target v0.8.0-v0.9.0 after gate stack and Screamer planner.
 2026-05-23 06:21:29 +00:00
Hermes
ea6f31b5f5 gbrain: sync converted org-mode brain files 2026-05-23 06:18:37 +00:00
Hermes
3e32ea9959 Promote entire passepartout-economics/ to ideas/ root 
All 31 files from ideas/passepartout-economics/ promoted to ideas/ root.
- Subfolder's passepartout-economics.org (42-line index) renamed to
  triad-index.org to avoid collision with root-level full doc
- index.org removed (redundant — triad-index.org replaces it)
- Root-level passepartout-economics.org: stripped file:passepartout-economics/
  prefix from all cross-references (now simple file:foo.org links)
- compliance-framework-mapping.org: same prefix cleanup
- All internal file: links within the economics docs already used simple
  names (no prefix) — they resolve correctly from ideas/ root
 2026-05-23 06:09:08 +00:00
Hermes
9f09d39232 Promote compliance mapping to triad-wide scope at ideas/ root 
Moved from ideas/passepartout-economics/compliance-framework-reference.org
to ideas/compliance-framework-mapping.org. This is a cross-cutting document
— compliance frameworks affect Logos (gate certification), Stoa (hardware
attestation), and Agora (marketplace/pds certification), not just economics.

Updated filetags to reflect triad-wide scope.
Updated all internal file: links with passepartout-economics/ prefix.
Expanded from 4 to ~33 frameworks across US, UK/EU, Asia-Pacific, Latin
America, and international organizations (World Bank, IFC, FATF, OECD, UN).
 2026-05-23 06:06:13 +00:00
Hermes
fce952e900 Expand compliance study to global master mapping: 30+ frameworks across OECD + international orgs 
Major expansion of compliance-framework-reference.org from 4 frameworks (HIPAA,
SOC 2, GDPR, FedRAMP) to ~33 frameworks covering:

US: SOX, GLBA, NY DFS 500, CCPA/CPRA, Quebec Law 25
UK/EU: UK GDPR, NIS2, EU AI Act, DORA, eIDAS 2.0, CRA
Asia-Pacific: APPI (Japan), ISMAP (Japan), PIPA (South Korea),
  Privacy Act/Australia, APRA CPS 234, IRAP, DPDP Act (India)
Latin America: LGPD (Brazil), LFPDPPP (Mexico)
International: ISO 27001, ISO 27701, Basel III, FATF AML/CFT,
  IFRS 17, OECD Privacy/AI Principles, World Bank ESF, IFC PS,
  UN/CEFACT

Each entry: what it is, who must comply, penalties, first-mover
advantage analysis. Added First-Mover Window Analysis table
(Critical/Wide/Mature/Latent) and Expanded Revenue Table with
30+ rows mapping framework → price → addressable orgs → revenue
potential → window → gate rule type.
 2026-05-23 06:02:39 +00:00
Hermes
3063f8fdf7 Normalize all passepartout-economics to inline wiki links 
Replaced every bottom-of-section 'See also:' block with inline
Org-mode file: links at the first natural mention in body text.
All 29 files across the economics directory now use wiki-style
inline cross-references rather than standalone reference blocks.
 2026-05-23 05:58:18 +00:00
Hermes
5a2fce162a Inline cross-references throughout compliance reference 
Replaced bottom-of-section 'See also' blocks with inline Org-mode file: links
at the first natural mention of each concept, wiki-style. Links now live in
the body text — compute-marketplace, verification-monopoly, domain-gate-packages,
infrastructure-lock-in, evaluation-harness all linked at their first relevant
usage per section.
 2026-05-23 05:51:54 +00:00
Hermes
2300cd4009 Add compliance framework reference: HIPAA, SOC 2, GDPR, FedRAMP 
Each framework defined with: what it is, who must comply, penalties,
relevance to the triad revenue model. Revenue table at bottom maps
each to gate package price, what it buys, and the buyer segment.
Cross-references the full economics knowledge base.
 2026-05-23 05:45:20 +00:00
Hermes
7b2ea7f28d Add Thoth to competitive analysis; refine compute marketplace thesis 
- Thoth: new Category 2 entry (Personal AI Assistants), LangGraph ReAct
  agent with knowledge graph, Developer/Designer studios, 151K LOC
- Compute marketplace: answer the structural question 'why buy compute
  if every user runs their own Passepartout?' — three structural reasons:
  specialized proof libraries, certification weight, bootstrap verification
 2026-05-23 05:36:27 +00:00
Hermes
b2ec6e9c65 Fix OpenCode entry: correct repo is anomalyco/opencode (163K★, Bun/TS), not the archived Go version 2026-05-22 11:09:35 +00:00
Hermes
7610d3a457 Add comprehensive competitive analysis of 8 AI agent platforms 2026-05-22 10:58:10 +00:00
Hermes
77b3bb6e6a Add collective regression suite spec — how the evaluation harness compounds across instances 2026-05-22 00:42:50 +00:00
Hermes
db253a70d5 Add two new nodes: Lisp Machine security (PMP/ECALL architecture) and Common Logic relevance analysis 2026-05-21 19:59:59 +00:00
Hermes
303e8c6306 Convert cross-references from [[id:uuid]] to [[file:name.org]] 
All 117 inter-node links now use [[file:node-name.org][title]] format
which renders as clickable hyperlinks in both Emacs (C-c C-o) and
web-based org renderers (Gitea, GitHub). Each node retains its :ID:
UUID property for Emacs org-roam database features (backlinks,
capturing, node-find).

Prev format: [[id:uuid][title]] — Emacs only, dead text on web
New format:  [[file:name.org][title]] — works everywhere
 2026-05-21 19:40:54 +00:00
Hermes
9b2be10c77 Restructure economics doc into 27 org-roam interlinked nodes 
Replace monolithic passepartout-economics.org with directory of
org-roam style nodes, each with :ID: property and cross-references
using [[id:uuid][title]] format.

27 nodes organized by theme:
- Core: index, triad overview, agora, stoa
- Revenue: verification appliance, domain gate packages, evaluation
  harness, skill marketplace, agora usernames, PDS service, compute marketplace
- Strategy: investment thesis, moats, licensing, patents, AI industry impact
- Analysis: lisp economics, sufficiency flip, time estimates, cost structure,
  gate rule encoding, upgrade lifecycle, biology parallels, symbolics comparison
- Big money: verification monopoly, infrastructure lock-in

Old file kept as archive with redirect links to new structure.
 2026-05-21 19:36:02 +00:00
Hermes
747419e2e0 Add Agora username registry and PDS-as-a-service revenue paths 2026-05-21 19:32:50 +00:00
Hermes
da307c5cad tam-business: ~T addressable market, 3-tier monetization model 
TAM: ~60B across cloud (00B), AI API (0B), OS (00B),
social media (00B), payments (00B), productivity (0B),
compliance (0B). Even 1% is 0B/year.

Low-hanging fruit (months): verification appliance (-50K/unit),
gate rule subscriptions (0-100K/yr each), evaluation certification
(0-200K), migration services (00-500K). Year one: -12M.

Medium-term (1-3 years): compute marketplace (Agora spread), Relay
Network (per-message fees), Lisp Machine appliance (0-100K/unit).

Big money (3-10 years): verification monopoly (UL for AI agents),
infrastructure lock-in (compounding switching costs), planetary
compute marketplace (network effects at scale).

Thesis: low-hanging fruit sustains development. Medium-term builds
network effects. Big money is venture-scale. The early player
benefits from every other instance because the network effects
are positive sum — this is the AWS of provable computing.
 2026-05-21 19:27:48 +00:00
Hermes
3a02e847f9 estimates-revised: velocity-driven timeline, self-writing triad 
- Observed velocity: v0.4.0 to v0.7.2 in one day, 80+ Lisp commits.
  Bottleneck is human review of Screamer-flagged 5%, not coding.
- Revised: v1.0.0 in 3-5 weeks (~80 cycles, 2-3h human review).
  Lisp Machine hardware in 2-4 weeks (~60 cycles, ~4-6h review).
  Full Stoa v2.0.0 (editor, browser, shell) in 2-3 weeks.
  Total to self-driving Lisp Machine: 8-12 weeks.
- Beyond bootstrap: system writes Stoa (~150K lines), Agora (~100K),
  hardware VHDL (~50K). Human only writes design decisions and
  reviews the 5% edge cases Screamer flags.
- The triad replaces every layer of computing: cognition, environment,
  network — one gate stack, one prover, no cloud, no gatekeeper,
  no per-token fee. A complete alternative infrastructure that
  the system writes itself, one ACL2-verified submission at a time.
 2026-05-21 19:22:24 +00:00
Hermes
434f754c15 triad: Logos (Passepartout), Stoa (the Porch), Agora (the Society) 
- Passepartout IS the PDS — memory-object (SHA-256 hash) maps
  directly to Agora Note (CIDv1). Gate stack verifies every note.
- Stoa: Lish editor + Nyxt browser + Lish shell in one Lisp image.
  v2.0.0→v6.0.0: Qt/WebKit erosion to pure-Lisp browser, tagged
  RISC-V hardware, world models.
- Agora: self-sovereign DID, DIDComm, Note primitives, Relay Network,
  compute marketplace, contracts, liquid democracy.
- The triad replaces every layer of the modern computing stack:
  cognition, environment, network, app model, compute, identity,
  commerce — all built on one gate stack, one memory model, one prover.
- Agora implementation is a separate body of work comparable to
  Passepartout itself.
 2026-05-21 19:17:28 +00:00
Hermes
d48925de23 estimates: LOC and dev time for self-driving Lisp Machine 
- Current Passepartout: ~10,700 lines, 2 months one dev
- To v1.0.0: +4,500 lines, 4-6 months
- Lisp Machine hardware integration: +6,000 lines, 3-6 months
- Total: ~21,000 lines, 9-14 months one dev, 5-7 months team of 2-3
- Why small: Lisp is 3-10x denser, primitives are reused across
  domains, ACL2 proofs replace test fixtures, LLM generates boilerplate
- Comparison: Hermes ~50K, Claude Code ~100K, Llama.cpp ~200K
- Not a moonshot. A well-scoped engineering project.
 2026-05-21 19:05:28 +00:00
Hermes
80daaa4830 lisp-machine-bootstrap: all software domains flip in days-weeks 
- Every subdomain for bootstrapping the Lisp Machine is software:
  RISC-V ISA, SBCL runtime, ACL2 logic, CIC type theory, compiler
  optimization, device drivers. Every one flips.
- Fastest sequence: Day 1 ingestion (LLM + human review), Day 1-2
  profiling (benchmark sweep), Day 2-3 active probing (synthetic
  microcode routines), Day 3-7 transfer + sufficiency (ACL2 verifies
  new dispatch routines, zero LLM tokens)
- Result: self-driving Lisp Machine in under a month with one
  human review session and a Tenstorrent P150
 2026-05-21 18:58:26 +00:00
Hermes
2d0d6d478a per-domain flip: knowledge types and fastest acquisition 
- Sufficiency flip is per-domain, not global. Poetry never flips.
- Three knowledge types: structural (published rules), empirical
  (observations), performance (profiling data)
- Fastest acquisition: active sandboxed probing, contrastive queries
  to human (not waiting for HITL to accumulate), ontology transfer
  from related domains, benchmark harness
- Codified domain: flip within days (hours LLM + hours expert review)
- Uncodified learnable domain: flip within weeks (probe + real use)
- Never-flip domains: system is honest, LLM handles 100%
 2026-05-21 18:55:11 +00:00
Hermes
b5d59c3360 llm-ability: coding skill is a speed multiplier, not a gate 
- LLM proposes code at every bootstrap stage (microcode, CIC kernel,
  macro layers, gate rules) — symbolic engine verifies before accepting
- Weak model = more retries (5-15), strong model = fewer (1-3)
  Both produce 100% verified output because the symbolic engine catches
  all mistakes
- The critical transition: not better LLMs, but the sufficiency flip
  applied to hardware. Once enough facts about runtime behavior
  accumulate, the system proposes microcode optimizations with zero
  LLM tokens.
- Surprise result: a barely competent LLM is sufficient for the full
  bootstrapping chain. It's slower and costs more in API calls, but
  reaches the same destination.
 2026-05-21 18:52:19 +00:00
Hermes
f9085a4690 refactoring: semantic equivalence boundary, self-driving Lisp Machine 
- ACL2 proves semantic equivalence for Passepartout's own Lisp code
  today; for other languages via logical specification modeling
- CIC prover (future) extends to dependent-type-level equivalence
  across language boundaries
- Self-driving threshold: when system can synthesize and load its
  own FPGA microcode or RISC-V dispatch from within the running image
- Tenstorrent P150 (72 RISC-V cores) is particularly interesting:
  microcode is RISC-V software, not FPGA hardware — system writes,
  compiles, loads, benchmarks its own core dispatch logic
 2026-05-21 18:47:49 +00:00
Hermes
852fcae4a6 refactoring: neurosymbolic planner for large codebase changes 
Six-stage workflow: codebase ingestion (AST as facts), goal translation
(LLM, 10%), Screamer constraint satisfaction (80%), ACL2 plan verification,
incremental execution with Merkle snapshots per step and rollback on test
failure, final re-verification.

Key limit: ACL2 cannot prove semantic equivalence of arbitrary programs.
Gap filled by: tests as empirical verification, API contract checking
(structural equivalence of public interfaces), human review with full
provenance of semantic changes.

Comparison with Claude Code: Passepartout trades higher up-front planning
overhead for zero-token constraint checks, ACL2-verified scope control,
instant per-step rollback, and a Merkle chain from before to after.
 2026-05-21 18:32:19 +00:00
Hermes
18b7c2f06f distribution: tiers, upgrades, and the divergence problem 
Three distribution tiers: code-only (AGPL), code+knowledge (commercial
data package), code+knowledge+hardware (verification appliance).

The upgrade challenge: instances diverge in both code and knowledge.
A 'git pull' breaks because new code expects fact structures the old
store doesn't have. Solved by:
- Ontology versioning flags old facts for re-verification
- Degradation to fallback mode, not crash
- Reversible upgrades via Merkle snapshots
- Delta distribution (diffs against current ontology version)
- Per-instance verified migration (run new code against old facts in
  sandbox; ACL2 reports compatibility; operator reviews only failures)

Business model: code free, migration scripts subscription, domain
knowledge packages subscription, firmware bundled with hardware.
 2026-05-21 18:22:23 +00:00
Hermes
d32ae4fcb0 reframe: why C won in the 80s and why Lisp is cheaper now 
- 1980s: memory K/MB, 1-10MHz CPUs, simple software, testing-sufficient.
  C fit in 64KB; Lisp needed 40MB and GC cycles. The market chose throughput.
- Today: memory and transistors are free (billions on an ARM core).
  Software is too complex for testing alone. Cost of failure > cost of
  verification.
- Inversion: 1980s said correctness is a luxury. 2020s says correctness
  is the only affordable option.
- Passepartout exploits this: verification appliance for K/year replaces
  00K/year in compliance failures.
 2026-05-21 18:19:26 +00:00
Hermes
43b83c595a insights: Lisp vs C hardware fork, Passepartout reversal path, microbiology parallels 
- The historical fork: C won on economics, not merit — RISC/commodity PC
  ecosystem optimized for C, not for Lisp
- Passepartout's reversal path: verification appliance vertical → FPGA
  Lisp μcode → custom ASIC economics
- Lisp for embedded: compile-to-C (ECL, PreScheme), tiny Lisps (uLisp,
  FemtoLisp), Lisp-as-macro-generator for C
- Microbiology as Lisp: DNA homoiconicity, hot-reloadable image, auto GC,
  interpreted execution, self-modifying source, duck typing, concurrent
  real-time GC (apoptosis)
- Biology proves the Lisp model is efficient at planetary scale
 2026-05-21 18:17:08 +00:00
Hermes
0ffad4c315 ideas: Passepartout — patents, moats, economics, design implications 
Distillation of discussion with Amr on 2026-05-21 covering:
- Patentability of probabilistic-deterministic split, Merkle memory,
  gate-to-fact bootstrap, macro-layer-as-skill architecture
- AGPLv3 vs MIT for provable-correctness claims
- Moats: empirical decision history, evaluation harness, infrastructure
  integration (time is not the primary moat)
- LLM-as-translator for codified domains (FAR, HIPAA, ISO) —
  encoding cost drops to near-zero for published regulations
- Revenue models: Lisp Machine appliances, gate rule subscriptions,
  evaluation harness certification, skill marketplace
- Impact on AI/GPU industry: token demand compression, GPU inference
  plateau, hyperscaler competition shifts to gate rule libraries
- Transition dynamics: sufficiency within months for codified domains
 2026-05-21 17:12:17 +00:00
Hermes
3b07a232cf add cloudflare infrastructure setup guide for tunnels, domains, and token rotation 2026-05-11 18:36:36 +00:00
224 changed files with 65832 additions and 1 deletions
Expand all files Collapse all files

200
.org-ids.json Normal file
View File

@@ -0,0 +1,200 @@
{
"284f5c7a-1d2b-4e3f-8c6d-9a0b1c2d3e4f": "_index.org",
"09a03e7f-c3f8-438a-abe3-7a7570957565": "resources/worse-is-better.org",
"4f4c1cf2-490d-4b9a-b6a5-4917d3b66887": "resources/_index.org",
"ee8f3b2a-4c7d-4e1b-9b0a-6d8f2e3c1a5b": "resources/neurosymbolic.org",
"a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d": "projects/_index.org",
"89f592aa-9c46-42db-a6c7-54dc91fe2172": "projects/cl-modernization/_index.org",
"433236a2-e5ad-41d4-a27e-4682f8bbc207": "projects/flags/legal-structure-practical-setup.org",
"0a4e0b8f-25e0-4b78-9633-fc37d03cefe9": "projects/flags/asset-protection-structures.org",
"5ac2f037-fc3c-45ac-a6e8-acc20e005cb0": "projects/flags/legal-structure-alternatives.org",
"1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b": "projects/flags/_index.org",
"7a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d": "projects/passepartout/_index.org",
"04c2f221-c54f-51e5-b40a-48822cd16d45": "projects/passepartout/common-logic-iso-24707.org",
"29a7d05f-1aec-41a4-a213-e52551eeb9eb": "projects/passepartout/ROADMAP.org",
"d5c6e7f8-9a0b-1c2d-3e4f-5a6b7c8d9e0f": "projects/passepartout/architecture/distinguishing-features.org",
"3129eae6-f9f2-40fe-a419-8c1af728c86d": "projects/passepartout/architecture/faster-theorem-proving.org",
"af9ce196-24a5-4035-bc02-83ddd60c1b09": "projects/passepartout/architecture/repo-organization.org",
"f6a7b8c9-0d1e-2f3a-4b5c-6d7e8f90abcd": "projects/passepartout/architecture/biomimicry.org",
"a7b8c9d0-1e2f-3a4b-5c6d-7e8f90abcdef": "projects/passepartout/architecture/neuro-neuromorphic-symbolic-comparison.org",
"1c95ce7d-a2db-506a-9608-df68f9ae211b": "projects/passepartout/architecture/security.org",
"be9bccc7-5adf-4d0d-8ee4-8855892189bf": "projects/passepartout/architecture/neurosymbolic-loop-architectures.org",
"26725506-399c-48c5-a797-46b48e8861d7": "projects/passepartout/architecture/self.org",
"5e7f1d2a-3b4c-5d6e-7f8a-9b0c1d2e3f4a": "projects/passepartout/architecture/_index.org",
"b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba": "projects/passepartout/architecture/systemic-effects.org",
"7f4e6b9a-2c1d-5e8f-9a3b-6d7c4e5f2a1b": "projects/passepartout/architecture/org-knowledge-base.org",
"971cd9e7-2cc5-4743-8042-2469dbe4078f": "projects/passepartout/architecture/lisp-foundation.org",
"d2722576-fc9b-4bd3-bc2f-f5692b561b4e": "projects/passepartout/architecture/academic.org",
"8cb760e2-37c6-4a78-af4d-f89f69d1678b": "projects/passepartout/architecture/stages/_index.org",
"4a1f23b0-abc8-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-7-remaining.org",
"4a1f23b0-abc6-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-5-weights.org",
"4a1f23b0-abc7-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-6-training.org",
"4a1f23b0-abc3-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-1-gate.org",
"4a1f23b0-abc5-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-4-inference.org",
"4a1f23b0-abc4-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-3-lisp-machine.org",
"4a1f23b0-abc2-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-2-social-protocol.org",
"4b5c6d7e-8f9a-0b1c-2d3e-4f5a6b7c8d9e": "projects/passepartout/architecture/knowledge-layers/neurological-empirical.org",
"329bd4fb-702a-4a2b-9c63-69281aacb83a": "projects/passepartout/architecture/knowledge-layers/_index.org",
"5c6d7e8f-9a0b-1c2d-3e4f-5a6b7c8d9e0f": "projects/passepartout/architecture/knowledge-layers/practical-implications.org",
"27c03e1d-283f-4e3d-9f32-6476aafde97e": "projects/passepartout/architecture/design/open-questions.org",
"9d2255b0-e6c9-479e-9e93-4f871a2193fe": "projects/passepartout/architecture/design/relation-to-passepartouts-existing-architecture.org",
"e32290a0-a02a-4af7-ae22-243d04a7ac82": "projects/passepartout/architecture/design/_index.org",
"e9c7a384-b42d-4dff-8da7-d4b62bb69956": "projects/passepartout/architecture/design/the-symbolic-engine/the-five-architecture-options.org",
"1937ee88-945e-4014-b5a0-cb3c8dcf1689": "projects/passepartout/architecture/design/the-two-brains/the-probabilistic-deterministic-split.org",
"d251d338-f52e-4a17-b458-a255dd097b98": "projects/passepartout/architecture/design/validation/whiteheads-process-philosophy-and-type-theory.org",
"183253ff-a0b7-468e-9858-6cb8ae2fb246": "projects/passepartout/architecture/design/knowledge-sources/semantic-wikipedia-as-entity-backbone.org",
"772ae489-b10a-48a0-bc3b-29136163d45b": "projects/passepartout/architecture/design/implementation-properties/performance-why-ontology-growth-doesnt-make-the-system-slower.org",
"0a33bd83-ff3c-4eac-bc97-83eb6702051a": "projects/passepartout/architecture/design/foundation/non-negotiable-identity.org",
"1ede13cb-05c0-4b1a-a873-98cf89bade81": "projects/passepartout/architecture/design/engineering-infrastructure/the-repl-as-cognitive-substrate.org",
"02f01d02-fc56-4551-81da-8704dbd65d89": "projects/passepartout/architecture/design/safety-self-preservation/self-preservation-the-active-third-law.org",
"e5f6a7b8-9c0d-1e2f-3a4b-5c6d7e8f90ab": "projects/passepartout/hardware/server-build-bom.org",
"d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f90": "projects/passepartout/hardware/_index.org",
"a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d": "projects/passepartout/hardware/server-rack-build.org",
"68ffa49f-f0d8-42cf-8b69-ae69de8bb815": "projects/passepartout/social-protocol/requirements-10-governance-and-assets.org",
"b25bf753-9799-41ab-82f5-1a1416db756b": "projects/passepartout/social-protocol/requirements-01-overview.org",
"a3243dd0-3209-423b-98e1-51c3eada2658": "projects/passepartout/social-protocol/requirements-07-advanced-integration.org",
"0f949f6c-4cf1-49eb-b9a4-ebcac27ee548": "projects/passepartout/social-protocol/requirements-05-social.org",
"72570648-d943-42e5-a781-3b09791ac6ec": "projects/passepartout/social-protocol/requirements-11-assessment.org",
"90484f4a-5b70-4001-93d6-e610e54ed573": "projects/passepartout/social-protocol/requirements-06-exchange-and-contracts.org",
"2cace571-76bb-4c34-a5f4-68bc20b2e884": "projects/passepartout/social-protocol/requirements-10-user-journey.org",
"6fe67db6-25bd-4d11-bd1d-b44ec809e858": "projects/passepartout/social-protocol/requirements-02-identity.org",
"8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d": "projects/passepartout/social-protocol/requirements-09-implementation.org",
"f6cfc54b-919b-4311-bcbf-65e976755d40": "projects/passepartout/social-protocol/requirements-04-the-primitive.org",
"df02cddc-944a-4bcd-8ef5-f080870d5f49": "projects/passepartout/social-protocol/requirements-08-library.org",
"8b2c3d4e-5f6a-7b8c-9d0e-1f2a3b4c5d6e": "projects/passepartout/social-protocol/_index.org",
"3b43a9b8-31d1-4479-a35f-22273b74f0c7": "projects/passepartout/social-protocol/requirements-03-infrastructure.org",
"10289e64-a4ff-4c34-828f-f3a9c769b73d": "projects/passepartout/social-protocol/requirements-00-readme.org",
"c34940cc-090e-57c4-8020-e78b1d32b96c": "projects/passepartout/strategy/domain-gate-packages.org",
"6d2e3f4a-5b6c-7d8e-9f0a-1b2c3d4e5f6a": "projects/passepartout/strategy/adoption.org",
"72db9428-d6e4-472d-9693-49335f888e48": "projects/passepartout/strategy/game-theory.org",
"b2c3d4e5-f6a7-8b9c-0d1e-2f3a4b5c6d7e": "projects/passepartout/strategy/hosting-economics.org",
"67faf52f-9126-50a7-b87e-2bedc610dac7": "projects/passepartout/strategy/licensing.org",
"c7d3f1a2-8b4e-5d6f-9a1c-3b2d4e5f6a7b": "projects/passepartout/strategy/domain-sequencing.org",
"9c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f": "projects/passepartout/strategy/_index.org",
"aa6d062e-a520-5d14-8773-00687ed9c689": "projects/passepartout/strategy/moats.org",
"29e4dbf3-cf19-589c-8b14-389e8a39d564": "projects/passepartout/strategy/upgrade-lifecycle.org",
"ed05cab4-88e9-4e25-b7c9-346fa39c69a0": "projects/passepartout/strategy/revenue.org",
"dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70": "projects/passepartout/strategy/time-estimates.org",
"1a2b38df-20ba-58ca-ba55-a072be67bd0d": "projects/passepartout/strategy/pds-as-a-service.org",
"3c6b0449-a8fb-5b89-b82a-34efb21ef5b5": "projects/passepartout/strategy/compute-marketplace.org",
"3aa22300-2f25-57b0-8787-9f199cc978b1": "projects/passepartout/strategy/competitors/competitive-analysis.org",
"a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d": "projects/passepartout/strategy/competitors/rainbird-ai-case-study.org",
"00ab3a4d-e3de-5605-a67d-12935bb36ab5": "projects/passepartout/strategy/competitors/comparison-with-symbolics.org",
"0d4e5f6a-7b8c-9d0e-1f2a-3b4c5d6e7f8a": "projects/passepartout/strategy/competitors/_index.org",
"1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f": "projects/passepartout/strategy/competitors/social-protocol-competitive-landscape.org",
"85ca69dd-d085-4a55-ad11-021910b1f82e": "projects/passepartout/strategy/competitors/ai-agents-scoping/openclaw.org",
"7a060b36-36db-4eb7-b8cc-844bd6ac9d36": "projects/passepartout/strategy/competitors/ai-agents-scoping/opencode.org",
"416bab7c-4300-4d50-838a-5c7a8ad45d96": "projects/passepartout/strategy/competitors/ai-agents-scoping/thoth.org",
"6883c4d2-b63b-4d2b-b224-2240ae748e7f": "projects/passepartout/strategy/competitors/ai-agents-scoping/_index.org",
"c3aab2e8-7e43-4abc-93f0-741675cfd78c": "projects/passepartout/strategy/competitors/ai-agents-scoping/aider.org",
"8d73ccb9-34e4-4899-b0c3-605998e9bebc": "projects/passepartout/strategy/competitors/ai-agents-scoping/gemini-cli.org",
"22d0a159-68a2-4587-9375-5046beddc20c": "projects/passepartout/strategy/competitors/ai-agents-scoping/continue.org",
"e929ff32-28d8-4a29-bf74-d55babc040d1": "projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org",
"c652688a-1ea0-487c-9222-00e954efe8a1": "projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org",
"512dd121-2292-4f3d-ac53-31bf3d12a60f": "projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org",
"8c7b9812-f8d6-4347-8915-ce8e520b7914": "projects/passepartout/strategy/social-protocol/social-protocol-entry-strategy.org",
"1d074690-a279-59cb-b91d-e9a22ae104ad": "projects/passepartout/strategy/social-protocol/social-protocol-overview.org",
"75bc14db-d241-4af8-a4e0-f14aff654d17": "projects/passepartout/strategy/social-protocol/_index.org",
"2e390c1d-65f3-5fb3-b898-ac3fc4291ee7": "projects/passepartout/strategy/social-protocol/social-protocol-usernames.org",
"64708e1f-00e9-4cb7-b44b-ea0b98e5296d": "projects/passepartout/strategy/social-protocol/social-protocol-contracts.org",
"7c4c5cca-1c63-4398-9b75-cf221e77dba0": "projects/passepartout/strategy/compliance/_index.org",
"98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b": "projects/passepartout/strategy/compliance/outbound-sales-compliance.org",
"b852ec69-0fc2-435c-ae1e-6b83e49b3ca3": "projects/passepartout/strategy/compliance/compliance-regimes/appi.org",
"e777064d-9950-42d5-980d-8c78cda91500": "projects/passepartout/strategy/compliance/compliance-regimes/pipa.org",
"e2ab887d-9f28-4da6-8388-e6c035e9d9c5": "projects/passepartout/strategy/compliance/compliance-regimes/iso-27001.org",
"4a2bc62b-3f21-4212-9cd9-f9add8fc0be1": "projects/passepartout/strategy/compliance/compliance-regimes/glba.org",
"03ebdb80-a9af-4e76-a443-8556424996ed": "projects/passepartout/strategy/compliance/compliance-regimes/fatf.org",
"e6993701-3c67-49bf-82f3-06907572cbf3": "projects/passepartout/strategy/compliance/compliance-regimes/fedramp.org",
"7f46764b-47b8-4892-a526-2c1b9ee6e6df": "projects/passepartout/strategy/compliance/compliance-regimes/irap.org",
"fc736aec-ef53-4759-9787-62bc8deea2e7": "projects/passepartout/strategy/compliance/compliance-regimes/ifrs.org",
"68c55deb-72bf-4b15-ac28-bcc792057543": "projects/passepartout/strategy/compliance/compliance-regimes/ifc-ps.org",
"513d5996-4ac7-4567-a992-18fc01599104": "projects/passepartout/strategy/compliance/compliance-regimes/gdpr.org",
"6a5884c8-e9b5-477e-bbf6-aa9ffd967739": "projects/passepartout/strategy/compliance/compliance-regimes/un-cefact.org",
"84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f": "projects/passepartout/strategy/compliance/compliance-regimes/hipaa.org",
"177aad72-5626-444d-a2e4-af8e1263b125": "projects/passepartout/strategy/compliance/compliance-regimes/world-bank-esf.org",
"834689e9-be0a-4822-9085-9b6b22294fd2": "projects/passepartout/strategy/compliance/compliance-regimes/privacy-act-aus.org",
"904f5f12-ec9a-4cbf-854a-0b9b1e11a521": "projects/passepartout/strategy/compliance/compliance-regimes/apra-cps-234.org",
"1c4c91ec-c465-44ab-bd91-4c3b45909ddb": "projects/passepartout/strategy/compliance/compliance-regimes/_index.org",
"c871a9f4-dd53-4e93-aa50-6acf0c606a9b": "projects/passepartout/strategy/compliance/compliance-regimes/lgpd.org",
"b8cf51e8-5f39-49ad-9547-a792a2e446aa": "projects/passepartout/strategy/compliance/compliance-regimes/eidas2.org",
"06fcdb02-2643-4f9d-ab41-e711a99cc390": "projects/passepartout/strategy/compliance/compliance-regimes/eu-ai-act.org",
"ed65031c-cbd2-4ad2-bd53-a67791e183cd": "projects/passepartout/strategy/compliance/compliance-regimes/soc2.org",
"c9830152-0160-4bdc-ab03-6f308ad43536": "projects/passepartout/strategy/compliance/compliance-regimes/sox.org",
"f6a0c00e-e922-44af-99ce-6412c4b73745": "projects/passepartout/strategy/compliance/compliance-regimes/quebec-law-25.org",
"748db16a-1382-4e5e-8812-a5d57a8de131": "projects/passepartout/strategy/compliance/compliance-regimes/nis2.org",
"87996d87-100c-4bf6-8546-a860b9d7c25b": "projects/passepartout/strategy/compliance/compliance-regimes/ccpa-cpra.org",
"ce81fefc-b7a8-4be5-912f-55fd30970b6e": "projects/passepartout/strategy/compliance/compliance-regimes/cra.org",
"085b76cc-4a65-4660-9c70-85aee10ca99e": "projects/passepartout/strategy/compliance/compliance-regimes/ismap.org",
"748b0cc7-7f42-49fb-8ee3-1ae49048a178": "projects/passepartout/strategy/compliance/compliance-regimes/iso-27701.org",
"022109ad-f031-44c4-8ea0-0b3c9402ca90": "projects/passepartout/strategy/compliance/compliance-regimes/oecd.org",
"fed19a24-ad81-4837-a12b-dafbd3ec110a": "projects/passepartout/strategy/compliance/compliance-regimes/dpdp-act.org",
"9bc29937-d59a-4ae4-9623-3d17a1fe6ebb": "projects/passepartout/strategy/compliance/compliance-regimes/uk-gdpr.org",
"4eef0993-6671-41cf-ba20-d1443a3ec49d": "projects/passepartout/strategy/compliance/compliance-regimes/basel-iii.org",
"581666ba-f72c-406b-8556-93876d2b30bf": "projects/passepartout/strategy/compliance/compliance-regimes/ny-dfs-500.org",
"bafdaa23-de0b-444c-9151-c87ac65add32": "projects/passepartout/strategy/compliance/compliance-regimes/lfp-dppp.org",
"717ef2df-2a80-4362-b23a-5e7e12554251": "projects/passepartout/strategy/compliance/compliance-regimes/dora.org",
"5f55bbe6-d243-5766-8ccf-5c5cc88a6542": "projects/passepartout/strategy/impact/ai-industry-impact.org",
"c2d3e4f5-a6b7-8901-2cde-f01234567890": "projects/passepartout/strategy/impact/phase-2-impact.org",
"a0b1c2d3-e4f5-6789-0abc-def012345678": "projects/passepartout/strategy/impact/phase-0-impact.org",
"92ccd074-04a0-4e45-a44f-9da24ea20a9b": "projects/passepartout/strategy/impact/impact.org",
"96e7a54e-d801-4b6e-bdc9-ea9dbd4fa51d": "projects/passepartout/strategy/impact/_index.org",
"b1c2d3e4-f5a6-7890-1bcd-ef0123456789": "projects/passepartout/strategy/impact/phase-1-impact.org",
"e4f5a6b7-c8d9-0123-4ef0-123456789012": "projects/passepartout/strategy/impact/phase-4-impact.org",
"d3e4f5a6-b7c8-9012-3def-012345678901": "projects/passepartout/strategy/impact/phase-3-impact.org",
"827bc546-e887-5b7c-9b65-6392beaf0920": "projects/passepartout/strategy/verification/verification-monopoly.org",
"89909ac6-8b4f-4a60-bbeb-52992c8f5135": "projects/passepartout/strategy/verification/_index.org",
"d84679f1-c0c5-5be4-b19c-6573560640ee": "projects/passepartout/strategy/verification/verified-skill-marketplace.org",
"84a537b4-4256-50c8-91f5-dd5b4538418f": "projects/passepartout/strategy/verification/verification-appliance.org",
"efc76898-03f7-57ba-923d-35d65da88bb7": "projects/passepartout/strategy/verification/sufficiency-flip.org",
"2cdca4b0-6b41-44b4-acb0-af21d0e27b00": "ideas/orders-of-magnitude-time.org",
"2afd9a3c-e96a-54c7-ac77-a05a28065b4b": "ideas/biology-parallels.org",
"329a30cd-55fb-496d-a60b-91388c211bba": "ideas/_index.org",
"f467ce16-1861-4ebd-96ed-b52fea909515": "ideas/lisp-game-engine-substrate.org",
"aae3b3a9-05c2-4acd-bfd4-a7f65003c0bf": "ideas/lisp-geometry-engine.org",
"8b9c0d1e-2f3a-4b5c-6d7e-8f9a0b1c2d3e": "ideas/viability/passepartout-bootstrap-mathematica.org",
"7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d": "ideas/viability/open-source-wolfram-lisp.org",
"f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f": "ideas/viability/schafmeister-clasp.org",
"d08f4f7b-6800-4625-a8f6-f91b3231ae2e": "projects/passepartout/architecture/design/the-symbolic-engine/merkle-dag-for-version-history.org",
"f23e5518-bf2a-459e-8d2e-a9645fad76ac": "projects/passepartout/architecture/design/the-symbolic-engine/cardinality-policies-singular-dual-and-plural-facts.org",
"ce124de6-6777-4dca-aaf3-57e842c1855b": "projects/passepartout/architecture/design/the-symbolic-engine/how-categories-grow-the-organic-ontology.org",
"49104db7-0c41-4507-8755-42b4a48b7cc9": "projects/passepartout/architecture/design/the-symbolic-engine/ontology-versioning-how-worldviews-change-without-losing-perspective.org",
"699de53a-06ff-4815-9f9d-70b006d372b8": "projects/passepartout/architecture/design/the-symbolic-engine/knowledge-graph-type-hierarchy-structural-anti-self-reference-v300.org",
"5788ad0f-45fb-4b2d-a3ab-09a4d95f351c": "projects/passepartout/architecture/design/the-symbolic-engine/the-awakening-sufficiency-criterion.org",
"1b88cec6-76d8-4496-ae36-1bf16b5bc962": "projects/passepartout/architecture/design/the-symbolic-engine/ephemeral-first-persistent-later.org",
"b21917d8-cb6e-4959-96c0-9326b0611134": "projects/passepartout/architecture/design/the-symbolic-engine/the-chosen-path-option-4-starting-with-option-5.org",
"28a8caf7-c0a1-4154-8ca3-3a0d11cf121a": "projects/passepartout/architecture/design/the-symbolic-engine/the-gate-to-fact-bootstrap-extracting-the-first-ontology-from-code.org",
"64be38aa-56ca-4960-92e1-f3fc4cb51a2e": "projects/passepartout/architecture/design/the-symbolic-engine/abstract-fact-store-interface-modular-by-design.org",
"02798a39-c12b-4835-bc61-34f57a860cdb": "projects/passepartout/architecture/design/the-symbolic-engine/the-llm-as-proposer-verified-extraction.org",
"7cb7df45-982f-4f5a-afee-36cd5595c25c": "projects/passepartout/architecture/design/the-symbolic-engine/_index.org",
"4fa7eb38-6bc0-4809-9d8a-77290760ea79": "projects/passepartout/architecture/design/the-two-brains/_index.org",
"76d92677-1eb0-4a3a-bee7-561874841e45": "projects/passepartout/architecture/design/the-two-brains/the-dispatcher-as-learning-system.org",
"dd9d7e5a-dd75-4762-8c31-f312de9c6585": "projects/passepartout/architecture/design/the-two-brains/core-knowledge-the-four-pillars-of-agentic-reliability.org",
"3d25a808-d623-42fb-a054-15fb28cd464b": "projects/passepartout/architecture/design/validation/historical-lineage-mccarthys-advice-taker.org",
"4c65fdbb-a45c-4c71-ac29-6488e9271f4a": "projects/passepartout/architecture/design/validation/marcus-2020-the-case-against-pure-deep-learning.org",
"e66a5d5f-70ff-4953-93c3-569e05eaff73": "projects/passepartout/architecture/design/validation/_index.org",
"2e7d9fe6-6e78-41a0-96ad-b07777275d23": "projects/passepartout/architecture/design/validation/the-competitive-argument.org",
"ec267c73-4e0d-4efb-9497-cb72f74538e4": "projects/passepartout/architecture/design/validation/gaur--sheth-2023-crest-trustworthy-neurosymbolic-ai.org",
"a56c8e07-9e5b-4070-a0f9-280188ccd6b7": "projects/passepartout/architecture/design/validation/sheth-et-al-2022-knowledge-infused-learning.org",
"b572b3a0-0238-470f-9bf8-63d356f68fe0": "projects/passepartout/architecture/design/knowledge-sources/empirical-validation-momo-and-modular-ontology-engineering.org",
"bc537cf8-5ac8-46b9-a625-1d4f678ee9fc": "projects/passepartout/architecture/design/knowledge-sources/_index.org",
"617a1031-495d-438c-a8e8-6e066b364e41": "projects/passepartout/architecture/design/implementation-properties/_index.org",
"2e3e576e-8839-4566-bae1-f40137428bb9": "projects/passepartout/architecture/design/implementation-properties/the-provenance-chain-as-product.org",
"7dee11bc-72b0-43a3-9bc8-2f022b59ba49": "projects/passepartout/architecture/design/foundation/homoiconicity-as-foundation.org",
"1076101b-6201-4461-81e5-38d7886b66af": "projects/passepartout/architecture/design/foundation/the-unified-memory-argument.org",
"4bf2264c-db97-4d7b-9972-5a5d052d80be": "projects/passepartout/architecture/design/foundation/org-mode-as-unified-ast.org",
"92e314a1-a650-4878-958a-9646aef4e032": "projects/passepartout/architecture/design/foundation/one-single-agent.org",
"2c880b7d-e97f-459a-88d1-61fac760a0dd": "projects/passepartout/architecture/design/foundation/_index.org",
"bffb1695-5bf5-4434-8f64-e74f19d2e537": "projects/passepartout/architecture/design/engineering-infrastructure/the-mcp-strategy.org",
"876fe3af-80fb-42dc-a0d0-714670e5b964": "projects/passepartout/architecture/design/engineering-infrastructure/token-economics-and-performance-advantage.org",
"3f4573b2-aa55-44a7-a6c8-861dc443ac32": "projects/passepartout/architecture/design/engineering-infrastructure/definite-description-resolution.org",
"a6dd0808-4366-4bda-be6e-f6d43f2eeab8": "projects/passepartout/architecture/design/engineering-infrastructure/the-evaluation-harness.org",
"bf3f84da-358b-4d87-bc1a-fa91d1994e20": "projects/passepartout/architecture/design/engineering-infrastructure/the-cybernetic-loop-why-the-metabolic-pipeline-works.org",
"e6269aec-ea0a-406e-8b44-9dbd7b38c83a": "projects/passepartout/architecture/design/engineering-infrastructure/literate-programming-as-discipline.org",
"3747ae5f-b4e5-4503-b397-a5b07862062d": "projects/passepartout/architecture/design/engineering-infrastructure/local-first-architecture.org",
"9e9950a8-82a5-42db-af2d-742ba09ff8ed": "projects/passepartout/architecture/design/engineering-infrastructure/time-awareness-as-a-structural-advantage.org",
"7e575c8d-aa28-4588-bfa1-5f6144165a13": "projects/passepartout/architecture/design/engineering-infrastructure/_index.org",
"ee527687-28e2-4f0f-8d3c-af5cc531e3d4": "projects/passepartout/architecture/design/engineering-infrastructure/observability-and-the-thought-trace.org",
"c47b80ec-2cf2-44ce-9781-96c14498669d": "projects/passepartout/architecture/design/safety-self-preservation/type-level-gates-structural-safety-from-self-modification.org",
"7e2f0f84-c2ad-4036-b2ba-0630776c73c8": "projects/passepartout/architecture/design/safety-self-preservation/layered-signal-authentication-trust-in-the-pipe.org",
"f74cb007-58a7-494f-93b7-a0fdf4b9f052": "projects/passepartout/architecture/design/safety-self-preservation/_index.org"
}

18
_index.org Normal file
View File

@@ -0,0 +1,18 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 284f5c7a-1d2b-4e3f-8c6d-9a0b1c2d3e4f
:END:
#+title: Brain
#+filetags: :index:navigation:
Personal knowledge base — projects, ideas, and concepts.
** Projects
- [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][CL Modernization]] — bringing Common Lisp forward by 25 years: build system, LSP, standard library, and a verified prover for a self-improving Lisp machine.
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout]] — a verifiable personal intelligence: self-bootstrapping Lisp machine, gate-verified reasoning, social protocol. Architecture, staged roadmap, strategy, competitive analysis, compliance landscape.
- [[id:1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b][Flags]] — legal structures: entity types, jurisdictional analysis, asset protection, practical setup guides.
** Ideas and concepts
- [[id:329a30cd-55fb-496d-a60b-91388c211bba][Ideas]] — cross-domain frameworks, in-depth analysis, reference material, and thinking tools.

19
ideas/_index.org Normal file
View File

@@ -0,0 +1,19 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 329a30cd-55fb-496d-a60b-91388c211bba
:ID: auto-ideas
:END:
#+title: Ideas
#+filetags: :index:
Cross-domain concepts, speculative analysis, and architectural thinking for the Passepartout project.
**Earlier ideas:**
- [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology as Proof of the Lisp Model]] — biological systems as evidence for Lisp architecture
- [[id:dddd52a7-adb8-470e-a459-614ade5f76af][Closing the Lisp Gap]] — performance and ecosystem gaps between Lisp and C/Rust, and how Passepartout closes them
- [[id:85f963a7-a10f-45cc-ace6-6edfeefee762][Lisp, Provers, and vs Rust]] — Lisp vs Rust analysis, prover architecture, HOL bootstrap, comparison with Lean
- [[id:be9bccc7-5adf-4d0d-8ee4-8855892189bf][Neurosymbolic Loop Architectures]] — how neurosymbolic systems loop between symbolic reasoning and neural learning
- [[id:d2722576-fc9b-4bd3-bc2f-f5692b561b4e][Who Is Closest to Passepartout?]] — nearest-neighbor analysis of related projects
- [[id:3129eae6-f9f2-40fe-a419-8c1af728c86d][Faster Theorem Proving]] — engineering approaches to making formal verification practical
- [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][Orders of Magnitude — Time]] — a time-scale framework for Passepartout's roadmap and development cycle

18
ideas/biology-parallels.org Normal file
View File

@@ -0,0 +1,18 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 2afd9a3c-e96a-54c7-ac77-a05a28065b4b
:END:
#+title: Biology as Proof of the Lisp Model
#+filetags: :passepartout:biology:lisp:parallels:evolution:
Striking parallels between microbiology and the Lisp model:
1. **Homoiconicity** — DNA is code and data in the same molecule; no separate source and binary
2. **Hot-reloadable image** — alternative splicing, epigenetic marks, post-translational modifications change the running program without restart
3. **Automatic memory management** — proteasomes degrade misfolded proteins, autophagy recycles organelles; the cell never calls free()
4. **Interpreted dynamic language** — DNA → RNA → ribosome (interpreter) → protein; no static compilation step
5. **Self-modifying source** — CRISPR, transposons, DNA repair modify the genome at runtime; eval on the genome
6. **Duck typing** — protein folding depends on chemical environment, not type declarations
7. **Concurrent real-time GC** — apoptosis breaks down cell components for recycling by neighboring cells
Biology chose the Lisp model because it is more robust, adaptable, and evolvable. Evolution optimized for survival in an unpredictable environment, not peak single-thread throughput. Biology is the proof that the Lisp model can be efficient at planetary scale, running on hardware that self-assembles from food. See [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] for how these biological parallels inform the business model.

30
ideas/lisp-game-engine-substrate.org Normal file
View File

@@ -0,0 +1,30 @@
:PROPERTIES:
:ID: f467ce16-1861-4ebd-96ed-b52fea909515
: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

175
ideas/lisp-geometry-engine.org Normal file
View File

@@ -0,0 +1,175 @@
:PROPERTIES:
:ID: aae3b3a9-05c2-4acd-bfd4-a7f65003c0bf
: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.

30
ideas/orders-of-magnitude-time.org Normal file
View File

@@ -0,0 +1,30 @@
#+title: Orders of Magnitude
#+filetags: :passepartout:framework:time:scale:hierarchy:
:PROPERTIES:
:ID: 2cdca4b0-6b41-44b4-acb0-af21d0e27b00
:ID: orders-of-magnitude-time
:CREATED: [2026-05-23 Sat]
:END:
Time at human scales is best thought of in orders of magnitude, not linear progression. Each jump in scale is qualitatively different — the constraints, the tools, the feedback loops, and the failure modes change entirely.
The hierarchy:
| Scale | What fits | Feedback | Failure mode |
|-------|-----------|----------|--------------|
| Minutes | Firefighting, ops, real-time decisions | Instant | Burnout, whiplash |
| Hours | Work session, meeting, focused task | Same day | Interruption cascade |
| Days | Shippable thing, momentum building | Next day | Drift, distraction |
| Weeks | Sprint, feature, market pulse | One cycle | Wrong direction |
| Months | Product cycle, hiring, traction | One data point | Bleeding out slow |
| Years | Company, [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]], technology shifts | Scarce | Irrelevance |
| Generations | Culture, regulation, infrastructure | Post-founding | Irreversibility |
Practical use:
When planning anything, identify which order of magnitude you're operating in — then use the tools and cadence appropriate to that scale, not the one below or above it. A minutes problem solved with a weeks solution is overengineering; a years problem approached with days thinking is naive.
Common mistake: treating a months/years problem as if it can be solved in days/weeks (startup hype, premature optimization) or a minutes problem as if it deserves weeks of deliberation (analysis paralysis, bikeshedding).
The [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Time estimates]] page applies this framework to [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s development timeline.

74
ideas/viability/open-source-wolfram-lisp.org Normal file
View File

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

92
ideas/viability/passepartout-bootstrap-mathematica.org Normal file
View File

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

52
ideas/viability/schafmeister-clasp.org Normal file
View File

@@ -0,0 +1,52 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f
:END:
#+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.
Schafmeister's research focuses on spiroligomers — large, shape-programmable molecules built from synthetic monomers. These are programmable at the level of both shape and functional groups, meaning they can be designed to bind specific proteins as therapeutics or accelerate chemical reactions the way enzymes do. The goal is to create molecules that can do everything proteins do in nature, but that are designable and evolvable by human beings.
This is a computational problem of enormous complexity. Designing these molecules requires simulating their behavior, computing binding affinities, searching conformational space, and iterating designs rapidly based on experimental feedback. The compute pipelines involved typically live in the C++ ecosystem (a vast array of scientific computing libraries), but the workflow itself — rapid prototyping, interactive exploration, incremental development — demands the kind of environment that C++ alone cannot provide.
* Why Lisp won.
Schafmeister's argument for Common Lisp in computational nanotechnology mirrors the same reasoning that drives 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.
Clasp is not a wrapper or a bridge. It is a full Common Lisp implementation where the C++ interoperation is part of the language runtime itself. The clbind library provides declarative bindings — you describe how C++ classes and functions map to Lisp, and Clasp generates the glue code automatically. This is fundamentally different from CFFI-style foreign function interfaces, which require manual marshaling and are inherently fragile.
From the Lisp perspective, a C++ class appears as a CLOS class. You can subclass it, specialize methods on it, inspect its instances. The boundary between Lisp and C++ is transparent to the programmer.
* Funding and validation.
Clasp has been funded by the Defense Threat Reduction Agency (DTRA), the National Institutes of Health (NIGMS), and the National Science Foundation. These are agencies that fund computational chemistry and materials design, not programming language research. They funded Clasp because it solved a real problem in molecular design that no other approach addressed: making C++-scale scientific computing work within an interactive Lisp environment.
* Relevance to the knowledge-layers architecture.
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 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.
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.
---
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

12
methodology/AGENTS.md
View File

@@ -1,3 +1,13 @@
---
type: methodology
title: AGENTS.md — Development Cycle
created: 2026-05-11
tags:
- methodology
- common-lisp
- development-workflow
---
# AGENTS.md # AGENTS.md
## Development Cycle (every change) ## Development Cycle (every change)
@@ -86,7 +96,7 @@
completion date. This is a separate commit on the branch: completion date. This is a separate commit on the branch:
#+begin_src org #+begin_src org
:LOGBOOK: :LOGBOOK:
- State "DONE" from "TODO" [YYYY-MM-DD Day] - State "DONE" from "TODO" [2026-05-10 Sat]
:END: :END:
#+end_src #+end_src

225
methodology/CLOUDFLARE-SETUP.md Normal file
View File

@@ -0,0 +1,225 @@
---
type: methodology
title: Cloudflare Infrastructure Setup
created: 2026-05-11
tags:
- methodology
- cloudflare
- infrastructure
- networking
---
# Cloudflare Infrastructure Setup
## Architecture Overview
```
Browser ──► Cloudflare (orange cloud) ──► Tunnel ──► cloudflared ──► Traefik:8081
│
(tunnel entrypoint)
│
┌──────────┴──────────┐
secureweb tunnel
(direct internet) (via tunnel)
:443 :8081
LetsEncrypt plain HTTP
```
All external traffic goes through Cloudflare Tunnel. Traefik serves as the internal reverse proxy, routing by Host header. Traefik's LetsEncrypt certs exist for LAN/direct access but aren't used externally (Cloudflare edge terminates TLS for visitors).
## Active Stack
| Component | Location | Notes |
|---|---|---|
| Tunnel name | `home` | Created at Cloudflare Zero Trust → Networks → Tunnels |
| Tunnel ID | `c29295c5-946a-4ddf-bdfe-7eafcd74faa3` | Visible in dashboard |
| Token | `.env` `TUNNEL_TOKEN=...` | Used by cloudflared to authenticate |
| cloudflared | production-1 Docker container | Runs with `--restart unless-stopped` |
| Traefik | production-1 Docker container | Ports 80, 443, 8080, 8082 |
| Traefik entrypoints | `web` (:80→redirect), `secureweb` (:443, TLS), `tunnel` (:8081), `metrics` (:8082) | |
| Traefik config | `/docker/appdata/traefik/traefik.yaml` | |
| Compose file | `/docker/compose/docker-compose.yaml` | cloudflared service defined but runs standalone due to interpolation issues |
| Traefik labels | Per-service in docker-compose.yaml | Pattern: `entrypoints=tunnel`, `Host(`subdomain.gharbeia.net`)` |
## 1. Adding a Second Domain
Example: adding `example.com` alongside `gharbeia.net`.
### Step 1: Cloudflare DNS
1. Go to Cloudflare Dashboard → Add site → enter `example.com`
2. Cloudflare scans existing DNS records — verify and continue
3. Change nameservers at your registrar to Cloudflare's
4. Wait for DNS to propagate
### Step 2: Cloudflare Tunnel — add hostname
1. **Zero Trust** → **Networks** → **Connectors** → **Cloudflare Tunnels**
2. Select tunnel **home** → **Edit**
3. Click **Add a public hostname**
4. Set:
- **Subdomain:** `*`
- **Domain:** `example.com`
- **Service Type:** HTTP
- **URL:** `traefik:8081`
5. Save
Cloudflare DNS will automatically create a wildcard CNAME for `*.example.com` pointing to `c29295c5-946a-4ddf-bdfe-7eafcd74faa3.cfargotunnel.com`.
### Step 3: Traefik — update cert resolver
Cloudflare wildcard certs only cover `*.gharbeia.net`. For `*.example.com`, either:
**Option A: Add to Traefik's ACME config**
In `/docker/appdata/traefik/traefik.yaml`, in `certificatesResolvers.letsencrypt.acme`:
```yaml
dnsChallenge:
provider: cloudflare
resolvers:
- 1.1.1.1:53
- 1.0.0.1:53
propagation:
delayBeforeChecks: 120s # increase for wildcards
```
Then in `entryPoints.secureweb.http.tls.domains`:
```yaml
domains:
- main: gharbeia.net
sans:
- "*.gharbeia.net"
- main: example.com
sans:
- "*.example.com"
```
**Important:** Before ACME DNS challenge can succeed for wildcard domains proxied via Cloudflare, you MUST create a DNS-only placeholder record for `_acme-challenge` to break the wildcard:
Go to Cloudflare DNS → Add record:
- **Type:** A
- **Name:** `_acme-challenge`
- **Content:** `127.0.0.1`
- **Proxy:** DNS-only (gray cloud)
Without this, the proxied wildcard CNAME intercepts `_acme-challenge.*` queries and LetsEncrypt can't verify the TXT challenge records.
**Option B: Skip HTTPS cert for now**
If the second domain doesn't need Traefik's own cert (i.e., Cloudflare edge certs are sufficient), no Traefik changes needed. The tunnel handles everything.
### Step 4: Add Traefik labels
For each service on the new domain, add Traefik labels in docker-compose.yaml:
```yaml
labels:
- traefik.enable=true
- traefik.http.routers.servicename.rule=Host(`subdomain.example.com`)
- traefik.http.routers.servicename.entrypoints=tunnel
- traefik.http.services.servicename.loadbalancer.server.port=3000
```
Then restart the container to pick up labels (compose or docker run depending on env state).
---
## 2. Security Panic — Changing All Tokens and Settings
### Step 1: Cloudflare API Token
1. Go to Cloudflare Dashboard → **My Profile** → **API Tokens**
2. **Delete** the old token
3. **Create Token** → **Edit zone DNS** template:
- Permissions: Zone → DNS → Edit
- Zone Resources: Include → Specific zone → `gharbeia.net`
- TTL: No expiration (or set a reasonable one)
4. Copy the new token
### Step 2: Update .env on production-1
```bash
ssh production-1
# Edit the token
sed -i "s|^CLOUDFLARE_DNS_API_TOKEN=.*|CLOUDFLARE_DNS_API_TOKEN=<new-token>|" /docker/compose/.env
```
### Step 3: Restart Traefik
Traefik runs standalone (not under compose). Restart it with the new token:
```bash
docker rm -f traefik
docker run -d --name traefik --restart unless-stopped --network networking \
-p 80:80 -p 443:443 -p 8080:8080 -p 8082:8082 \
-e CF_DNS_API_TOKEN="<new-token>" \
-e TZ="America/New_York" \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
-v /docker/appdata/logs/traefik:/var/log \
-v /docker/appdata/traefik:/etc/traefik \
-v /docker/appdata/traefik/letsencrypt:/letsencrypt \
traefik:latest
```
Traefik will automatically renew its LetsEncrypt cert with the new token.
### Step 4: Cloudflare Tunnel Token
If you also rotate the tunnel token:
1. Go to **Zero Trust** → **Networks** → **Tunnels** → **home**
2. Click the three dots → **Recreate token**
3. Copy the new token
On production-1:
```bash
docker rm -f cloudflared
docker run -d --name cloudflared --restart unless-stopped --network networking \
-v /docker/appdata/cloudflared:/home/nonroot/.cloudflared \
cloudflare/cloudflared:latest tunnel --no-autoupdate run --token "<new-token>"
```
Also update the `.env` file:
```
TUNNEL_TOKEN=<new-token>
```
### Step 5: Verify everything works
```bash
# Check cloudflared is connected
docker logs cloudflared --tail 5 | grep "Registered tunnel connection"
# Check Traefik is running and has routes
docker logs traefik --tail 10 | grep "Register"
# Test end-to-end
curl -sI https://git.gharbeia.net/ | head -5
# Should return HTTP/2 200
```
### Step 6: Rotate other secrets (if needed)
Other credentials in `.env` that may need rotation:
- `AUTHENTIK_SECRET_KEY` — generate new: `openssl rand -base64 60 | tr -d '\n'`
- `POSTGRESQL_PASSWORD` — generate new
- `EMAIL_PASSWORD` — Fastmail app password
- `GITEA_TOKEN` — Gitea settings → Applications
- `OPENROUTER_API_KEY` — OpenRouter dashboard
## Troubleshooting
### Cert renewal fails with "Invalid format for Authorization header"
The Cloudflare API token in `CF_DNS_API_TOKEN` is wrong or expired. Generate a new one and restart Traefik.
### Cert renewal stuck on "Waiting for DNS record propagation"
Likely the proxied wildcard CNAME is intercepting `_acme-challenge` subdomain. Add a DNS-only A record for `_acme-challenge` → `127.0.0.1` in Cloudflare DNS to break the wildcard.
### Tunnel shows 502 Bad Gateway
- Check cloudflared logs: `docker logs cloudflared --tail 10`
- If `connection refused` → Traefik isn't listening on the expected port
- If `tls: unrecognized name` → SNI mismatch (revert to HTTP mode in tunnel config)
### Adding a new service
1. Add Traefik labels to the service in docker-compose.yaml
2. If the container was started without labels, recreate it with `docker run` including `-l` flags (compose may fail due to .env interpolation issues)
3. The tunnel wildcard already catches `*.gharbeia.net` — no tunnel changes needed

BIN
papers/McCulloch-Pitts-1943.pdf Normal file
View File

Binary file not shown.

558
papers/Rosenblatt-1958.pdf Normal file
View File

File diff suppressed because one or more lines are too long

8
projects/_index.org Normal file
View File

@@ -0,0 +1,8 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d
:END:
#+title: Projects
#+filetags: :index:
All projects documented in this brain. Each project has its own architecture, strategy, and reference material.

9
projects/cl-modernization/_index.org Normal file
View File

@@ -0,0 +1,9 @@
:PROPERTIES:
:ID: 89f592aa-9c46-42db-a6c7-54dc91fe2172
:CREATED: [2026-06-03 Tue]
:ID: 971cd9e7-2cc5-4743-8042-2469dbe4078f
:END:
#+title: CL Modernization
#+filetags: :redirect:
This document has moved to [[file:../passepartout/architecture/lisp-foundation.org][Lisp Foundation]] in the Passepartout architecture tree.

8
projects/flags/_index.org Normal file
View File

@@ -0,0 +1,8 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b
:END:
#+title: Flags
#+filetags: :index:
Legal structure analysis for the Passepartout project — entity types, jurisdictional considerations, asset protection, practical setup guides.

139
projects/flags/asset-protection-structures.org Normal file
View File

@@ -0,0 +1,139 @@
:PROPERTIES:
:ID: 0a4e0b8f-25e0-4b78-9633-fc37d03cefe9
:ID: asset-protection-structures
:CREATED: [2026-05-23 Sat]
:END:
#+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.
* The Assets to Protect
Passepartout has three distinct asset classes, each with different protection needs:
1. /IP (verification subsystem):/ [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] codebase, gate rules, ACL2 proof libraries, the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]]. This is the core defensible IP. Needs to be owned separately from the operating company so that if the operating company is sued, the IP is not reachable.
2. /Platform ([[id:1d074690-a279-59cb-b91d-e9a22ae104ad][the social protocol]]):/ The network itself — user base, reputation graph, contract history, protocol specification.
3. /[[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams]]:/ Enterprise compliance contracts, transaction fees, PDS hosting subscriptions. These flow through the operating company. A judgment against the operating company attaches to the revenue in that entity.
* Common Structures
** Structure A: Standard Delaware C-Corp (no offshore)
- Delaware C-Corp owns everything: IP, platform, operations
- Founders hold common stock
- Investors hold preferred stock
Pros: Simplest, most familiar to investors, standard for venture fundraising
Cons: All assets in one basket. A judgment against the operating company attaches to everything, including the IP. No asset protection beyond the corporate veil (which is thin for a single-member/controlled startup).
Assessment: Fine for Phase 0. Upgrade when revenue exceeds liability risk tolerance.
** Structure B: Delaware C-Corp + Offshore IP Holding Company
- Delaware C-Corp is the operating company (sells verification, runs the social protocol PDS infrastructure)
- A separate IP holding company in BVI, Cayman, or Nevis owns the Passepartout code, gate rules, ACL2 libraries, and the social protocol spec
- The operating company licenses the IP from the holding company at arm's-length royalty rates
- The holding company accumulates IP [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] revenue in the offshore jurisdiction
Pros: Strong IP protection — a judgment against the operating company cannot reach the IP (the operating company doesn't own it). Profits from licensing are outside US tax jurisdiction until repatriated.
Cons: US tax reform (TCJA 2017) introduced GILTI (Global Intangible Low-Taxed Income) — this structure is less tax-effective than pre-2017. Transfer pricing documentation required. Increases administrative complexity.
** Structure C: Offshore IP Co + US OpCo + Offshore Trust
- Same as B, but the IP holding company is owned by an irrevocable offshore trust (Cook Islands, Nevis) rather than by the founders directly
- The trust has a corporate trustee and the founders are discretionary beneficiaries
- The trust also owns the founder's equity in the US operating company
Pros: Maximum asset protection. The trust is beyond the reach of US courts (Cook Islands trusts have the strongest asset protection laws — they do not recognize US judgments and require creditors to litigate in Cook Islands under Cook Islands law).
Cons: Complex, expensive to set up and maintain. Many investors are uncomfortable with trust-held equity (loss of control). Triggers PFIC (Passive Foreign Investment Company) tax issues.
** Structure D: Delaware C-Corp + Delaware LLC Series + Offshore
- Delaware C-Corp as parent
- Each business line (verification, social protocol network, [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], PDS hosting) is a separate Delaware series LLC
- IP held in an offshore company, licensed to each series LLC
- Series LLCs protect assets within each series from liabilities arising in other series
Pros: Good liability separation between business lines. If the social network (the social protocol) generates liability, the verification business assets are in a separate series.
Cons: Series LLC is legally untested in many jurisdictions. Some states don't recognize them. Tax complexity.
* Key Considerations for This Specific Venture
** The IP is the crown jewel
[[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]] /is/ the moat. The ACL2 proof libraries, gate rule library, and regression suite are accumulated over years and cannot be recreated quickly. These must be owned by a separate entity from the operating company. If the operating company is sued, the IP survives.
** The social protocol network is harder to protect**
The social protocol's value is partly in its decentralized architecture (no central entity controls the network) and partly in the code that runs the PDS infrastructure and protocol. The AGPL license means anyone can run the code — the network value is in the user base, not the software. This is a structural asset protection advantage: even if the operating company fails, the network continues.
** Revenue splits suggest separate entities**
Enterprise compliance revenue ($2-12M/year) is high-margin, low-volume, and comes from a small number of customers. Social protocol transaction fees (0.5-2%) are low-margin, high-volume, and come from millions of users.
** Jurisdiction for the IP company**
| Jurisdiction | Asset protection | Tax treatment | Cost | Reputation |
|--------------+-----------------+---------------+------+------------|
| BVI | Strong | No corporate tax, but GILTI limits benefit | Moderate | Standard, well-understood |
| Cayman | Strong | Same as BVI | High | Well-understood by investors |
| Nevis | Very strong | Same as BVI | Moderate | Less common, stronger AP laws |
| Cook Islands | Strongest (no US judgment recognition) | Same as BVI | High | Niche, but gold standard for AP |
For a venture-funded tech company: BVI or Cayman is the standard choice. Cook Islands is overkill unless there is a specific high-risk profile. Nevis is a middle ground.
* Recommended Path
** Phase 0: Delaware C-Corp (simplest, standard)
Single Delaware C-Corp. IP is owned by the corporation. Founders hold common stock. This is what every seed-stage investor expects. The IP protection is minimal (all eggs in one basket), but the liability risk in Phase 0 is also minimal — you have zero revenue, zero users, zero contracts.
Action items for Phase 0:
1. Incorporate in Delaware (legalzoom, clerky, or a startup lawyer)
2. Assign all IP to the corporation via a standard IP assignment agreement from founders
3. Set up standard corporate records (board minutes, cap table)
** Phase 1: Separate IP + OpCo (before significant revenue)
Before enterprise compliance revenue exceeds $5M cumulative or social protocol users exceed 10K, establish the IP holding company structure.
Structure: Delaware C-Corp (OpCo) + BVI IP Co
- OpCo licenses verification IP from BVI Co
- OpCo licenses social protocol IP from BVI Co
- Founders own both entities (same cap table or mirror ownership)
Timing: The IP transfer is a taxable event if the IP has appreciated. Transfer early, when the IP has minimal appraised value (before the verification monopoly exists), to avoid a tax hit.
** Phase 2: Series Separation (when the social protocol has significant users or revenue)
If the social protocol has 100K+ users and payment volume, separate the business lines into different entities under the same parent:
- Verification LLC (verification, enterprise compliance)
- Social Protocol LLC (social network, transactions, PDS hosting)
- Compute LLC (marketplace operations)
- BVI IP Co (owns all IP, licenses to all three)
** Phase 3: Trust Structure (if wealth preservation becomes primary concern)
When the cumulative value justifies the cost and complexity: move the BVI IP Co ownership into an irrevocable offshore trust with the founders as beneficiaries.
* What This Means for the [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Growth Strategy]]
The institution-first path (enterprise compliance) and the social-first path (social protocol communities) have /different liability profiles/ that push toward different structures:
Enterprise compliance: Higher liability per contract. A single compliance engagement gone wrong could be a $1M+ claim. The IP separation in Phase 1 is /more urgent/ for the verification revenue stream.
Social protocol network: Lower liability per user but higher aggregate surface. Payment processing regulations, content liability, data protection.
The combined strategy (both engines) makes the Phase 1 structure (Delaware OpCo + BVI IP Co) more important rather than less — the diversification of revenue streams also diversifies liability sources, and the IP needs to be protected from /both/.
* References
This is preliminary research. Specific recommendations require a US corporate lawyer (incorporation), an international tax lawyer (offshore structure), and an asset protection specialist (trust/AP structure). The right order: incorporate in Delaware when ready, then hire a lawyer to plan the offshore structure before significant revenue or users accumulate.
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]]
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Social protocol competitive landscape]]
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]]
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance framework]]

163
projects/flags/legal-structure-alternatives.org Normal file
View File

@@ -0,0 +1,163 @@
:PROPERTIES:
:ID: 5ac2f037-fc3c-45ac-a6e8-acc20e005cb0
:ID: legal-structure-alternatives
:CREATED: [2026-05-23 Sat]
:END:
#+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.
* Texas vs Delaware for the OpCo
** The Trend
Several prominent companies have redomesticated from Delaware to Texas: Tesla (2024), Oracle, Hewlett Packard Enterprise, Charles Schwab, CBRE. The reasons are cost-driven: Texas franchise tax is based on margin (revenue minus costs, capped), while Delaware's franchise tax is based on authorized shares and can be significantly higher for companies with large authorized share pools.
** Comparison
| Dimension | Delaware | Texas |
|-----------+----------+-------|
| Filing fee | $89 (standard) | $300 |
| Annual franchise tax | $175-225,000 (depends on authorized shares — can be very high for VC-funded corps) | $0 if no Texas revenue. If taxable: 0.375-0.75% of margin (with $1M revenue exemption) |
| Corporate law sophistication | Gold standard. Chancery Court, 100+ years of precedent, specialized corporate judges | Also good. Texas Business Organizations Code (TBOC) is well-developed. Less precedent than Delaware for contested M&A |
| Registered agent | $50-300/year | $50-300/year |
| Investor familiarity | Universal. Every VC/Bank knows Delaware | Less common for venture-backed startups. Some investors require Delaware |
| Court system | Court of Chancery (corporate law specialists, no juries) | Regular state courts with business courts in major counties |
| Flexibility | Extremely flexible charter provisions | Good, but less tested at the edges |
** Analysis for This Venture
Delaware wins /if/ you plan to raise VC. Investors prefer Delaware and some require it. The Chancery Court's expertise in corporate governance disputes and M&A is unmatched.
Texas wins /if/ the plan is to stay bootstrapped with limited equity structure. The annual franchise tax savings can be significant: Delaware charges minimum $175 but can charge $10K+/year for corps with large authorized share pools. Texas charges nothing if your revenue is under $1M or your margin is zero.
For this venture /without VC/: Texas is competitive. The lack of corporate income tax and the franchise tax exemption under $1M revenue mean year 1-2 costs are near zero. Delaware's legal sophistication only matters if you expect governance disputes or M&A, which are unlikely in the early years.
Recommendation: If no VC and staying under $1M revenue in year 1, Texas is a viable alternative to Delaware for the OpCo. The BVI IP Co structure works identically regardless of which state the OpCo is in. Redomestication from Delaware to Texas later is possible but costs a few thousand.
* Wyoming DAO LLC
** What It Is
Wyoming passed HB 185 in 2025 creating the "Decentralized Autonomous Organization Limited Liability Company" (DAO LLC). It's an LLC variant that recognizes decentralized governance — the members vote on-chain (or via cryptographic consensus) rather than through traditional board resolutions. The DAO LLC is a separate legal entity that can hold assets, sign contracts, and sue/be sued — the DAO governance is the decision-making mechanism.
** Relevance to This Venture
The [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]]'s governance modules (liquid democracy, Collective Personas, GEM) map /directly/ onto the DAO LLC concept. If a community on the social protocol wants to be a legal entity — own a shared website domain, hold a pooled treasury, sign a contract with a vendor — they could incorporate as a Wyoming DAO LLC. The social protocol's existing governance infrastructure (voting, constitutions, role management) becomes the DAO LLC's management mechanism.
** This Is Not the OpCo or IP Co Structure
The Wyoming DAO LLC is not a replacement for the Delaware/Texas OpCo or the BVI IP Co. It is an offering /for social protocol communities/. The communities themselves become legal entities, not just digital spaces. This creates a product feature:
- Community in the social protocol hits 25 members who pool $5K in dues
- Community clicks "Incorporate as Wyoming DAO LLC"
- The social protocol generates the filing (name, registered agent, governance document mapping)
- The community's voting modules become the LLC's management structure
- The community now holds assets, signs contracts, and has liability protection
** Practical Considerations
Wyoming DAO LLCs are new (2025). Case law is essentially nonexistent. Banks may not open accounts for them. Tax treatment is unclear. But for social protocol communities that need legal entity status, it's the least friction option.
* Panama LLC (Sociedad de Responsabilidad Limitada / SRL)
** What It Is
A Panama LLC — bearer shares, no corporate tax on foreign-source income, no reporting of beneficial owners to the government (private registry), no requirement to file financial statements publicly. Popular for asset protection because Panama has no tax treaty with the US that allows US tax authorities to automatically obtain information (though this changed somewhat under FATCA/CRS).
** As a Replacement for the BVI IP Co
| Dimension | BVI IP Co | Panama LLC |
|-----------+-----------+------------|
| Setup cost | $2,500-8,000 | $2,000-5,000 |
| Annual cost | $1,300-3,100 | $500-1,500 |
| Tax on IP royalties (US perspective) | Same — US taxes the OpCo on a net basis; BVI/Panama tax the IP Co at 0% (foreign-source income) | Same |
| US tax information exchange | Yes — BVI has signed CRS/MCAA. Automatic exchange with US under FATCA Intergovernmental Agreement | Yes — Panama signed CRS and has FATCA IGA. But historically less compliant |
| Banking | BVI banks generally easier to open accounts | Panama banks are under scrutiny after Mossack Fonseca |
| Reputation | Clean — BVI removed from EU greylist 2024 | Stigma from Panama Papers (2016). Some counterparties will ask questions |
| Bearer shares | BVI eliminated bearer shares in 2020 | Panama still allows bearer shares (strong anonymity, but banks reject them) |
** Analysis
Panama is not clearly better than BVI for this structure. The cost is slightly lower but the stigma from the Panama Papers means some US banks and counterparties will scrutinize transactions from Panama more heavily. BVI is the standard choice for a reason — it's well-understood, clean reputation post-greylist removal, and adequate for the IP holding function.
Panama makes sense /only/ if anonymity is the primary goal. For this venture — which may eventually seek regulatory compliance, sell to enterprise CISOs, or onboard institutional investors — anonymity is a liability, not an asset. The BVI route is cleaner.
* Trusts: Jurisdictions and Downsides
** The Trust Types
For asset protection, two types matter:
/Revocable trust:/ The settlor (you) can change or dissolve it. Assets in it are still reachable by creditors. Not useful for asset protection — it's primarily for estate planning.
/Irrevocable trust:/ The settlor gives up control permanently. A trustee manages the assets. The settlor cannot dissolve it. Creditors cannot reach the assets (if set up before the liability arose). This is the asset protection tool.
** Trust Jurisdictions
| Jurisdiction | Strength | Cost | Key Feature | Key Downside |
|-------------+----------+------+-------------+--------------|
| Cook Islands | Strongest | $15-30K setup, $5-10K/yr | /Does not recognize US court judgments/. Creditor must litigate in Cook Islands under Cook Islands law. 1-year statute of limitations. Debtor-friendly fraud rules (proving fraudulent conveyance is very hard). | Distant, expensive, small professional services ecosystem. Trust company availability limited |
| Nevis | Very strong | $10-20K setup, $3-7K/yr | Similar to Cook Islands: no US judgment recognition. Same legal tradition (English common law). Close to US (EST time zone). | Smaller, less established trust industry |
| Belize | Strong | $5-10K setup, $2-4K/yr | Lower cost. Strong confidentiality laws. No mandatory reporting. | Less tested in court. Smaller trust company ecosystem |
| Niue | Strongest on paper | $8-15K setup, $3-5K/yr | Extremely debtor-friendly laws. Shortest statute of limitations (6 months in some cases). | Very small jurisdiction. Tiny trust industry. Reputational risk (some association with dubious schemes) |
| South Dakota (US) | Moderate | $3-8K setup, $2-5K/yr | Strongest US domestic trust law. No state income tax. Dynasty trusts (no rule against perpetuities). Asset protection trust statute. | /US jurisdiction/ — US courts have jurisdiction. Not as strong as Cook Islands for protecting against US creditors |
| Nevada (US) | Moderate | $2-5K setup, $1-3K/yr | Strong US domestic trust law. No state income tax. Shorter statute of limitations for fraudulent conveyance challenges. | Same limitation as South Dakota — US jurisdiction |
** The Key Question: Foreign Trust vs Domestic Trust
The core distinction:
A /foreign/ trust (Cook Islands, Nevis) is offshore from US courts. A US creditor who obtains a judgment against you cannot simply reach the trust assets. They must litigate /again/ in the foreign jurisdiction, under that jurisdiction's debtor-friendly laws. This is a massive practical barrier — few creditors will pay for two lawsuits in two countries.
A /domestic/ trust (South Dakota, Nevada) is under US court jurisdiction. A US creditor can get a court order directly against the trust. The domestic AP trust statutes provide some protection (shorter fraudulent conveyance lookback, higher burden of proof for creditors), but a sufficiently determined creditor can eventually reach the assets.
** The Downsides of an Extremely Strong Structure
/1. Loss of Control./ An irrevocable trust means the assets are gone. You cannot change your mind. You cannot dissolve the trust. You cannot redirect the assets. This is the /price/ of asset protection. If the trust owns the BVI IP Co (which owns the [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] IP), you are a discretionary beneficiary of the trust, not the owner of the IP. The trustee makes decisions about the IP — not you.
/2. Banking and Financing Difficulty./ Banks scrutinize trust-owned structures. The BVI IP Co owned by a Cook Islands trust will require extensive KYC across four layers: you → trust → BVI Co → OpCo. Some US banks will refuse to open accounts. International banking is possible but time-consuming (3-6 months).
/3. Transaction Complexity./ Selling the company becomes harder. A buyer is not acquiring shares from you — they are negotiating with a foreign trustee. Every M&A lawyer will charge extra for this complexity.
/4. Fraudulent Conveyance Risk./ If the trust is set up after a liability has already arisen (or even after a threat of litigation), a court can void the entire structure as a fraudulent conveyance. The structure only protects against /future/ liabilities. Setting it up early (before any revenue, before any contracts, before any users) is essential — but even then, a court could look back if the timing is suspicious.
/5. Cost./ Annual costs of $10-20K for the trust alone, plus the BVI Co and OpCo costs. This is significant before you have revenue.
/6. Perceived Illegitimacy./ Counterparties — especially enterprise CISOs buying verification services — may ask questions about why the company is structured this way. A company that sells trust and verification services should look trustworthy. An extremely aggressive AP structure may undermine that perception.
* The Combined Structure Map
Option A (recommended baseline):
Founders → Delaware OpCo + BVI IP Co (same ownership)
IP owned by BVI Co. OpCo licenses it. Simple, clean, effective for business liability protection.
Option B (founders' personal AP, trust layer):
Founders → Irrevocable Cook Islands Trust → owns BVI IP Co → licenses to Delaware OpCo
Also: Trust is named beneficiary of OpCo equity (this is complex — often structured as a separate trust holding the OpCo shares)
This protects the IP from both /business/ liability (via the OpCo/IP separation) and /personal/ liability (via the trust owning the IP Co). A personal judgment against you cannot reach the trust assets.
Option C (full stack, extreme protection):
Founders → Irrevocable Cook Islands Trust → owns BVI IP Co + owns beneficial interest in Panama LLC
Panama LLC → holds OpCo shares
OpCo uses IP under license from BVI Co
This is the maximum: three layers between any creditor and the IP. But the cost, complexity, and counterparty friction make it appropriate only for very high net worth individuals facing specific litigation risk.
* The Honest Assessment
For the first phase of this venture (pre-revenue, pre-product, zero users), even a plain Delaware C-Corp is overengineering. The BVI IP Co is a modest step that costs a few thousand and protects the most valuable asset (the IP) from potential business liability. It should be set up early.
The trust layer is genuinely unnecessary until one of these triggers:
- You have personal net worth above $2-5M that you want to protect
- The BVI IP Co's IP is appraised at $5M+
- You are in a profession with high personal liability (you're not — you're building software)
- A specific liability event is imminent (lawsuit filed, regulatory action)
Adding the trust earlier /does/ improve protection (the fraudulent conveyance lookback clock starts earlier) but the cost, complexity, and operational friction of running the business through a foreign trust outweigh the benefit at this stage.
* References
- [[id:433236a2-e5ad-41d4-a27e-4682f8bbc207][Practical setup guide — Delaware C-Corp + BVI IP Co]]
- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures overview]]
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]]

205
projects/flags/legal-structure-practical-setup.org Normal file
View File

@@ -0,0 +1,205 @@
:PROPERTIES:
:ID: 433236a2-e5ad-41d4-a27e-4682f8bbc207
:ID: legal-structure-practical-setup
:CREATED: [2026-05-23 Sat]
:END:
#+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.
* The Structure
[Founders] → own equity in → [Delaware C-Corp (OpCo)]
│
license to use IP
│
▼
[BVI Business Company (IP Co)]
│
owns the IP assets
([[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] code, gate rules,
ACL2 libraries, [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]] protocol
spec, trademarks, domain names)
The OpCo pays the IP Co an arm's-length royalty for the right to use the IP in its business (compliance sales, PDS hosting, marketplace operations). The IP Co accumulates royalty income in a tax-neutral jurisdiction (BVI has 0% corporate tax). The founders own both entities under the same cap table.
* Layer 1: Delaware C-Corp (OpCo)
** What It Is
A Delaware stock corporation — standard C-Corp for tax purposes. The entity that signs contracts, employs people (eventually), earns revenue, and holds liability.
** Paperwork
- /Certificate of Incorporation:/ Filed with Delaware Division of Corporations. Specifies the corporation's name, registered agent, authorized shares, and incorporator.
- /Bylaws:/ Internal governance rules (board structure, meeting procedures, officer roles). Not filed with the state but must exist.
- /Stock issuance:/ Founders purchase common stock via a stock purchase agreement. An 83(b) election must be filed within 30 days if shares are subject to vesting.
- /Initial board resolution:/ Documents the first board meeting (elect officers, authorize stock issuance, approve bank account opening).
** Forms
| Form | Purpose | Where | Cost |
|------+---------+-------+------|
| Certificate of Incorporation | Creates the corporation | Filed with DE Division of Corps | $89 (standard, up to 5K shares). $189 for expedited 24hr processing |
| Franchise Tax Report | Annual filing | DE Division of Corps | $225 minimum/year (based on authorized shares). Can be $175+ for small corps |
| Registered Agent | Accepts legal service in DE | Private service (CSC, Registered Agents Inc, legalzoom) | $50-300/year |
| 83(b) election | Tax treatment of restricted stock | Filed with IRS within 30 days of purchase | $0 (paper filing) |
| IRS SS-4 | Employer ID Number (EIN) | IRS | Free |
| BOI Report | Beneficial Ownership Information | FinCEN | Free (new requirement, 2024) |
** Steps
1. Choose a corporate name (must be unique in Delaware, include "Inc." or "Corp.")
2. Reserve the name (optional, $75, holds for 120 days)
3. Select a registered agent
4. File the Certificate of Incorporation online or by mail
5. Draft bylaws (template from your incorporation service)
6. Issue founder shares and file 83(b) election
7. Apply for EIN (SS-4)
8. Open a US bank account (requires EIN + Certificate of Incorporation)
9. File the BOI report with FinCEN within 90 days of formation
** Timeline
| Step | Time | Note |
|------+------+------|
| Order incorporation | 1-2 hours online | Via legalzoom, clerky, or direct with DE |
| State processing | 24 hours (expedited) to 2 weeks (standard) | |
| EIN from IRS | Same day (phone) to 2 weeks (mail) | Call IRS and get it same-day |
| Bank account | 1-2 weeks | Requires physical presence or remote onboarding |
| Total | 1-3 weeks | Can be done entirely remotely |
** Costs
| Item | One-time | Annual |
|------+----------+--------|
| Certificate of Incorporation (standard) | $89 | — |
| Name reservation (optional) | $75 | — |
| Registered agent | — | $50-300 |
| Franchise tax | — | $175-225 |
| Bylaws (template) | $0-100 | — |
| Total year 1 | $164-264 | $225-525 |
| Total year 2+ | $0 | $225-525 |
Using a formation service like clerky or legalzoom adds $100-300 but includes document templates, registered agent for the first year, and step-by-step guidance.
* Layer 2: BVI IP Co
** What It Is
A BVI Business Company (IBC) incorporated under the BVI Business Companies Act (2004). The entity that owns the IP assets and licenses them to the OpCo. BVI has no corporate tax, no capital gains tax, no withholding tax on dividends or royalties. The BVI is not on the EU blacklist or greylist as of 2026 (it was greylisted 2022-2024 and was removed after reforms).
** Paperwork
- /Memorandum and Articles of Association:/ The constitutional document. Filed with the BVI Registry of Corporate Affairs. Similar to a DE Certificate of Incorporation.
- /Register of Directors:/ Names and addresses of directors. Filed with the BVI Registry. /Not public/ — BVI maintains a private register.
- /Register of Members:/ Shareholder information. Kept at the registered office. Not public.
- /Licence Agreement:/ The agreement between the OpCo and the IP Co granting the OpCo a license to use the IP in exchange for royalty payments. This is the critical document for transfer pricing compliance.
- /Corporate resolutions:/ Appointing directors, issuing shares, authorizing the license agreement.
** Forms and Steps
| Step | Where | Cost | Time |
|------+-------+------+------|
| Choose BVI registered agent | Private service (Harneys, Ogier, Maples, or low-cost providers) | $500-1,500/year | 1 day to choose |
| Due diligence (KYC) | Registered agent requires passport, proof of address, source of funds | $0 | 1-5 days |
| Name approval | BVI Registry | $0 | 1-2 days |
| File M&A + register | BVI Registry via registered agent | $350-750 (govt fee) | 1-3 days |
| Issue shares | Internal | $0 | 1 day |
| Appoint director/officer | Internal | $0 | 1 day |
| Draft IP license agreement | Lawyer | $1,500-5,000 | 1-2 weeks |
| BVI bank account | BVI or international bank | $0-500 (account fees) | 2-6 weeks |
| Total setup | | $2,500-8,000 | 2-5 weeks |
** Annual Costs
| Item | Cost |
|------+------|
| Registered agent fee | $500-1,500 |
| BVI government fee | $450-1,100 (depends on authorized share capital) |
| BVI financial statement filing | $350-500 (simple, no audit required — just a declaration) |
| Total annual | $1,300-3,100 |
** The IP License Agreement
This is the most important document. It must:
1. /Define the IP:/ List every asset being licensed — the Passepartout source code, gate rules, ACL2 proof libraries, social protocol specification, trademarks, domain names, trade secrets.
2. /Set the royalty rate:/ Must be at arm's-length. For software/tech IP, typical royalty rates are 2-10% of gross revenue, depending on how central the IP is to the business. Verification IP is 100% central to the business (the product /is/ the IP) — rates at the higher end are defensible.
3. /Transfer pricing documentation:/ Required under US tax law (IRC Section 482). A transfer pricing study documents that the royalty rate is consistent with what unrelated parties would agree to. Cost: $5,000-15,000 for a professional study. /Alternative:/ Use an industry benchmarking report from a database like RoyaltyStat or ktMINE. The documentation must exist in case of IRS audit.
4. /Territory:/ Global license, exclusive or non-exclusive.
5. /Sub-[[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]]:/ Whether the OpCo can sub-license. Typically no — the IP Co controls sub-licensing.
* Layer 3: Founders' Ownership
Both the OpCo and the IP Co must be owned by the same people to avoid attribution issues.
** Mirror Ownership
- OpCo founders own 100% of OpCo common stock
- Same individuals own 100% of IP Co shares (same percentages)
- Documented in both entities' records
The two entities are related parties. The IRS will scrutinize transactions between them. Mirror ownership is standard and expected — the key is the documentation of the license agreement and the arm's-length royalty.
** Individual Asset Protection
The founders' personal assets are protected by the corporate veil of both entities. This is /not/ the trust-level protection of Structure D — if both entities are owned by the founders directly, a judgment against the founders (personal liability) could reach the shares in both entities. But a judgment against the OpCo (business liability) cannot reach the IP in the IP Co — that's the point.
* Layer 4: Trust (Deferred)
Not set up now. The trust adds $15-30K setup + $5-10K/year and makes investor fundraising nearly impossible. Defer until:
- Personal wealth (across all assets) exceeds $2-5M, /or/
- The IP Co's accumulated value (IP appraisal) exceeds $5M, /or/
- A specific liability risk emerges (lawsuit filed, regulatory investigation)
When the threshold is reached, the structure becomes: Founders → Irrevocable Cook Islands Trust → owns BVI IP Co → licenses to Delaware OpCo.
* Complete Timeline and Cost Summary (Year 1)
| Item | Timeline | One-time | Annual |
|------+----------+----------+--------|
| Delaware C-Corp | Week 1-2 | $200-500 | $225-525 |
| BVI IP Co | Week 2-5 | $2,500-8,000 | $1,300-3,100 |
| IP License Agreement | Week 3-6 | $1,500-5,000 | — |
| Transfer pricing documentation | Week 4-8 | $0-15,000 | $2,000-5,000 (update) |
| US bank account (OpCo) | Week 2-4 | $0 | $0-200 |
| BVI bank account (IP Co) | Week 4-10 | $0-500 | $0-500 |
| Total year 1 | 4-10 weeks | $4,200-29,000 | $1,525-4,325 |
| Total year 2+ | — | $0 | $1,525-4,325 |
The wide range depends on whether you use a DIY formation service ($400 Delware + $2,500 BVI) or a full-service law firm ($5,000 Delaware + $8,000 BVI + $15,000 transfer pricing study).
* What Must Be Done by a Professional
Some things can be DIY'd, some cannot:
| Task | DIY possible? | Recommendation |
|------+---------------|---------------|
| DE Certificate of Incorporation | Yes (clerky, legalzoom, or direct filing) | DIY ($100-300) |
| DE Bylaws | Yes (template available) | DIY or included with service |
| 83(b) election | Yes (one-page IRS form) | DIY |
| BVI incorporation | Via registered agent | Agent handles government filing |
| IP License Agreement | /No/ | Must be a lawyer (transfer pricing + IP specialist) |
| Transfer pricing study | /No/ | Must be a tax professional |
| BVI bank account | Can apply remotely | Some agents offer bank introduction |
* The Bottom Line
Minimum viable setup (DIY Delaware, basic BVI, lawyer for license agreement): ~$5,000 one-time, ~$1,500/year ongoing. Timeline: 4-6 weeks from start to both entities operational.
Full professional setup (law firm for everything + transfer pricing study): ~$25,000 one-time, ~$4,000/year ongoing. Timeline: 6-10 weeks.
The IP transfer must happen /before/ the IP has significant value. Incorporating both entities now (before the first compliance sale) means the IP assigned to the BVI Co has negligible appraised value. Waiting until Phase 1 means the IP may have significant value and the transfer triggers a taxable gain.
* References
- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures — options analysis]]
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance — data protection law]]
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy — Passepartout]]

1702
projects/passepartout/ROADMAP.org Normal file
View File

File diff suppressed because it is too large Load Diff

59
projects/passepartout/_index.org Normal file
View File

@@ -0,0 +1,59 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 7a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d
:END:
#+title: Passepartout
#+filetags: :index:
**What Passepartout is.**
Passepartout is a project that builds toward a personal computing environment where you own your computation, your data, and your agency — and the architecture proves it, not promises it.
It is a single system that is simultaneously:
- Your editor, browser, shell, and AI agent — not separate programs but a single environment where everything works together because everything shares the same structure.
- Your knowledge base — a living [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][memex]] of everything you read, write, and decide, stored in a format you can read and your machine can read, with no translation layer between them.
- Your gatekeeper — a system that checks every action against your rules before taking it, whether the action comes from you, from the AI, or from the network.
- Your identity and communication protocol — cryptographic identity, encrypted messaging, and provable exchanges between instances.
These are not separate products. They are one project, one architecture, one machine.
**Why it exists.**
The modern computing stack is built from independently built, independently untrusted layers: hardware, firmware, operating system, compilers, runtime, network protocols, applications. Each layer assumes the layers below it are either trusted or someone else's problem. The gaps between layers are where exploits live.
Security is reactive. We find bugs, we patch them, we run antivirus, we monitor logs. The model is probabilistic: "no known vulnerabilities" does not mean none exist, only that none have been found. The patching treadmill has been running for forty years and shows no sign of slowing.
Passepartout asks a different question: what if you eliminated the boundaries between layers instead of trying to secure them? What if the entire stack shared one structure, one verification, one proof — from the rules that authorize an action to the hardware that executes it?
This eliminates entire categories of threats by structural design, not by patching. Memory corruption exploits, compiler backdoors, malware with execution paths that bypass the rules — these are not mitigations you add on top of an unsafe system. They are classes of threat that cannot exist in a system built on this principle.
**What it replaces.**
| Current approach | Passepartout |
|---|---|
| Separate editor, browser, shell, agent — each a different program with different trust assumptions | One environment where all are functions in the same memory space |
| Knowledge stored in a database you cannot inspect | Knowledge stored in a file format you read and edit directly |
| Security through permissions, firewalls, antivirus, audits | Security through a rule system that checks every action before it executes |
| Separate identity systems for every service (Google login, GitHub, Slack) | One cryptographic identity you control |
| Vulnerabilities found and patched reactively | Categories of threat eliminated by architecture |
**How we get there.**
The full system is the destination, but every intermediate stage delivers value on its own. The project is designed as a staged migration from conventional hardware to the full architecture, with no rewrite required between stages. Development is running today.
**What it means.**
A system built this way shifts computing from an empirical trust model — "this has passed our tests" — to a deductive one: "this is structurally impossible for the following reasons." The downstream effects cascade beyond any single user:
- A company's compliance obligations become a set of rules the system enforces by construction, not a binder of documents an auditor reviews once a year.
- AI safety becomes a rule system between the AI and the actions it can take, not a set of probabilities and guardrails.
- Software certification becomes a shared suite of proofs from every deployed instance — a public attestation that a system behaves as specified.
Passepartout creates a new category: verified infrastructure. Not a safer operating system, not a better AI agent, not another social network — but the foundation beneath all three, built on a principle that the current approach cannot offer: that the system, by its structure, is trustworthy.
---
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the system in detail
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic Effects]] — what verification cascades into
- [[id:8cb760e2-37c6-4a78-af4d-f89f69d1678b][Staged Roadmap]] — from today to What Remains

158
projects/passepartout/architecture/_index.org Normal file
View File

@@ -0,0 +1,158 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:ID: 5e7f1d2a-3b4c-5d6e-7f8a-9b0c1d2e3f4a
:ID: 1c3ec48b-446c-50d2-b53e-126a81f5143f
:END:
#+title: Architecture
#+filetags: :passepartout:architecture:
**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 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:e32290a0-a02a-4af7-ae22-243d04a7ac82][Design Decisions]] 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:e32290a0-a02a-4af7-ae22-243d04a7ac82][Design Decisions]] 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 (Neurosymbolic Agent stage):** 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 (see the [[file:/stages.org][stages]] directory for full detail) describes how each successive replacement eliminates a class of threat:
Development (baseline: Linux + Python agent + SQLite), Neurosymbolic Agent (the gate — root eliminated, provenance store operational), Social Protocol (provable communication), Lisp Machine (bare-metal — no MMU), AI Inference (in-process LLM), AI Weights (plist-native neural data), AI Training (verified fine-tuning), What Remains (physical, political, oracular limits).
Each stage is independently useful. Development is running today. The migration is progressive component swap, not a cut-over.
**Self-developing hardware (Lisp Machine onwards):** 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
- [[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:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology as proof of the Lisp model]]
- [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][Comparison with Symbolics Genera]]

108
projects/passepartout/architecture/academic.org Normal file
View File

@@ -0,0 +1,108 @@
:PROPERTIES:
:CREATED: [2026-05-27 Wed]
:WEIGHT: 63
:ID: d2722576-fc9b-4bd3-bc2f-f5692b561b4e
:END:
#+title: Who Is Closest to Passepartout?
#+filetags: :passepartout:academia:comparison:neurosymbolic:verification:
A survey of academic researchers whose work overlaps with Passepartout's architecture along specific dimensions. The conclusion: no academic group combines all four architectural properties that define Passepartout's design. The closest groups each hold one or two pieces; none combine all.
* The Four Architectural Properties
1. **LLM-level generator with full creative freedom** — the generator synthesizes entire implementations from specifications, not individual tactic steps or hole-fillings.
2. **Theorem-prover verification with complete functional correctness** — the verifier checks all execution paths against the full spec, not bounded verification via SMT solvers.
3. **Asymmetric authority** — the symbolic component (prover) is the final authority and cannot be overridden by the neural component.
4. **Counterexample-guided retry loop** — when the prover rejects an implementation, it returns a concrete counterexample that the generator uses to reformulate.
* The Academic Landscape
**LLM + Theorem Prover Loops**
| Researcher | Institution | System | Match | Divergence |
|------------|-------------|--------|-------|------------|
| Sean Welleck | CMU | ImProver 2 | Self-improving LMs generating proof steps verified by Lean | Generator fills tactic holes in existing proofs, not full implementations. Camp B. |
| Timon Gehr | ETH | COPRA, Thor | LLM interacts with theorem prover kernel | Same constraint: tactic-level. Neural component generates one move at a time. |
| Kaiyu Yang | Princeton | LINC | Neural network learns symbolic rules, prover checks consistency | Neural component is a *learner* discovering rules from data, not a generator synthesizing from spec. Different abstraction level. |
All three are Camp B in the loop taxonomy (constrained generator + complete verifier). None gives the LLM freedom to synthesize full implementations. Welleck's ImProver is the closest in spirit — the loop iterates, the prover is authoritative — but the scope of what the generator produces is orders of magnitude smaller than what Passepartout's design requires.
**Synthesis + Verification (non-LLM)**
| Researcher | Institution | System | Match | Divergence |
|------------|-------------|--------|-------|------------|
| Armando Solar-Lezama | MIT | Sketch | Synthesis-aided verification: partial program → solver fills holes → assertions checked | Generator is constraint-based SAT/SMT, not an LLM. Verification is bounded (solver capacity). |
| Emina Torlak | UW | Rosette | Solver-aided languages for synthesis + verification | Same constraints as Sketch. Bounded, non-LLM. |
| Swarat Chaudhuri | UT Austin | Neurosymbolic Programming | Neural networks guide program synthesis, symbolic analysis verifies | Uses SMT for bounded verification, not theorem prover for complete. Neural-symbolic are symmetric collaborators, not asymmetric authority. |
Chaudhuri is the closest overall academic neighbor. His group explicitly works on combining neural and symbolic components, with symbolic verification of neural-generated candidates. But the verification is bounded (SMT), not complete (theorem prover), and the loop does not have Passepartout's asymmetric authority design.
**Lisp as Infrastructure for Verification**
| Researcher | Institution | System | Match | Divergence |
|------------|-------------|--------|-------|------------|
| Christian Schafmeister | Temple | Clasp | Common Lisp through LLVM; interactive Lisp for serious computation | Lisp infrastructure, not a neurosymbolic loop. No ACL2 integration. |
| Kaufmann, Moore | UT Austin / Retired | ACL2 | The theorem prover itself | Pure symbolic verification. No LLM loop. |
Schafmeister is aligned with Passepartout on the "why Lisp" question — interactive development, uniform representation, C++ interop for performance — but does not work on agentic verification loops.
**Autonomous Code Modification Loops**
| Researcher | Institution | System | Match | Divergence |
|------------|-------------|--------|-------|------------|
| Kevin Ellis | Cornell | DreamCoder | Neural program synthesis loop: generate → execute → learn | Verifier is interpreter (does it run?), not prover (is it correct?). Camp A. |
| Andrej Karpathy | Anthropic | autoresearch | LLM modifies code, runs experiments, keeps/discards based on metric | Verifier is val_bpb — a single empirical number. No specification, no formal guarantee. Camp C. |
Both prove the viability of the autonomous loop concept but use the weakest possible verifiers (execution and empirical metrics).
**The Bitter Lesson / Temporal Credit Assignment (Sutton)**
| Researcher | Institution | System | Match | Divergence |
|------------|-------------|--------|-------|------------|
| Richard Sutton | Alberta / Keen Technologies | TD learning, eligibility traces, Alberta Plan | The fundamental problem in verification — *an action was checked, but the consequence plays out hours later; was the action correct?* — is the same problem TD learning solves in RL: assigning credit to actions based on delayed outcomes. Sutton's temporal credit assignment work is the theory you would need to extend Passepartout from per-action gates to trajectory-level verification. His Bitter Lesson (scale beats engineered knowledge at sufficient compute) is the most commonly cited argument against the symbolic verification approach Passepartout bets on. | The Bitter Lesson is not anti-knowledge — it says methods that improve with more computation eventually dominate. Passepartout's gate is a deliberately small engineered knowledge system that *won't* benefit from more compute (the ACL2 lemmas don't get more correct with more hardware). That's acceptable because the gate is a narrow bottleneck (permit/deny). The LLM layer inside the gate *does* benefit from scale. The architecture already respects the Bitter Lesson by placing the scalable piece where scale helps and the non-scalable piece where deductive certainty matters. Sutton's Alberta Plan (world model + reward + learning algorithm) parallels Passepartout's AI Training stage (world model + gate + verified fine-tuning), but Sutton's agents learn by pure reward while Passepartout's learn by reward constrained by verified policy. Sutton would likely argue that a learned safety policy at scale would outcompete the gate. Passepartout's bet is that access control, message authentication, and compliance should never be probabilistic, even at infinite scale.
**Integrate-Symbolic-Into-Neural (Garcez)**
| Researcher | Institution | System | Match | Divergence |
|------------|-------------|--------|-------|------------|
| Artur d'Avila Garcez | City, Univ. of London | NeSy frameworks, NSL | Pioneer of neural-symbolic computation since 1990s. Book: "Neural-Symbolic Cognitive Reasoning." Runs NeSy workshop series. | His approach *integrates* symbolic knowledge into neural networks (logic regularization, knowledge distillation). Symbolic rules are a training signal, not a runtime verifier. The neural component can override symbolic constraints through the loss landscape. No asymmetric authority, no theorem prover, no complete verification. His camp is "make neural networks behave more symbolically." Passepartout's camp is "make neural networks accountable to symbolic verification." Opposite architectural philosophy. |
Garcez's position in the design space is closest to Camp A (no independent verifier). The symbolic rules guide learning but do not veto outputs at runtime. His work is foundational for the field of neural-symbolic computation, but his *architectural philosophy* is the inverse of Passepartout's. He wants the symbolic inside the neural. Passepartout wants them separate with the symbolic holding authority.
**Theorist of the Hybrid Thesis (Marcus)**
| Researcher | Institution | System | Match | Divergence |
|------------|-------------|--------|-------|------------|
| Gary Marcus | NYU Emeritus, Robust.AI | None (theorist/critic) | Longest-standing public advocate for hybrid AI. Since "The Algebraic Mind" (2001) and "Rebooting AI" (2019), he has argued deep learning alone cannot achieve systematicity, composition, or reasoning. He identified the *need* for the approach Passepartout implements. As of May 2026, he is publicly asking why LLM agent frameworks are not using LEAN as a theorem-prover verifier — the same engineering gap Passepartout occupies. | He does not propose a specific architecture or loop design. His background is cognitive science and developmental psychology, not formal verification. The "symbolic component" he advocates is abstract — structured knowledge representations, not ACL2 theorem proving. He has no answer to the cost/feasibility question (the "Better is Cheaper" argument is Passepartout's contribution, not Marcus's). He is a theorist of the problem, not an architect of the solution — though his May 2026 tweet shows he is now engaging with the engineering question directly. |
Marcus occupies a category that does not appear in the loop taxonomy (Camps A-D) because he does not define a loop. He identifies the *need* for hybrid AI with genuine symbolic authority. Passepartout is the engineering response to the thesis Marcus has been arguing since before most of the field would admit the limitations existed. His May 2026 tweet asking "they aren't using LEAN in one of those many tools?" is the theorist noticing the empty cell Passepartout was designed to fill.
* The Gap
| Property | Passepartout | Closest academic | Academic's limiter |
|----------|-------------|-----------------|-------------------|
| Generator freedom | Full synthesis from spec | ImProver (Welleck) | Fills tactic holes only |
| Verification completeness | Complete (theorem prover) | Sketch (Solar-Lezama) | Bounded (SMT) |
| Asymmetric authority | Neural cannot override prover | Neurosymbolic Prog (Chaudhuri) | Symmetric collaboration |
| Counterexample feedback | Structured from prover to LLM | ImProver (Welleck) | Pass/fail at tactic level |
| Two symbolic layers | Gates + prover independent | None | No second layer exists |
No academic group combines all four properties. The closest — Chaudhuri — has three of five (neural + symbolic + verification) but fails on verification completeness (SMT not ACL2), asymmetric authority (symmetric not asymmetric), and the two-layer gate design.
* What This Means
The gap is either:
1. **A genuinely empty cell in the design space.** The combination is novel, the components have not converged in one system before, and Passepartout's design is early.
2. **A sign that the combination is not as valuable as the components.** No major academic lab has invested in this specific loop because the cost of writing complete formal specifications exceeds the benefit of complete formal verification, given the alternative of bounded verification (SMT) with cheaper spec costs.
The way to distinguish (1) from (2) is to build the architecture and measure whether the spec-writing cost is amortized over enough synthesized implementations to justify it. Passepartout's answer is: yes, because specs are written once and implementations are generated for every deployment context. The academic literature has not tested this claim.
* References
- [[id:be9bccc7-5adf-4d0d-8ee4-8855892189bf][Neurosymbolic Loop Architectures]] — the taxonomy that positions these comparisons
- [[id:ee8f3b2a-4c7d-4e1b-9b0a-6d8f2e3c1a5b][Neurosymbolic AI Paper Library]] — papers referenced above are in the local library

138
projects/passepartout/architecture/biomimicry.org Normal file
View File

@@ -0,0 +1,138 @@
:PROPERTIES:
:CREATED: [2026-06-01 Mon]
:WEIGHT: 61
:ID: f6a7b8c9-0d1e-2f3a-4b5c-6d7e8f90abcd
:END:
#+title: Biomimicry in Passepartout
#+filetags: :passepartout:architecture:neurosymbolic:biomimicry:p150:
**Biomimicry in Passepartout**
**What already exists (real biomimicry, not metaphor)**
| Feature | Biological analog | Implementation |
|---------+-------------------+----------------|
| Three-layer reasoning | Reptilian → limbic → neocortex | LLM (intuition) → Screamer (constrained search) → ACL2 (verified reasoning) |
| Verdict-overrides-LLM | Somatic markers override conscious deliberation | Gate outputs overrule LLM proposals, not the other way |
| Dream cycle | Sleep consolidation | gbrain dream cycle: replay and re-index daily experience offline |
| Delegate subagents | Cognitive recruitment | delegate_task — spawns specialized subprocesses for subproblems |
| Memory as two systems | Declarative vs procedural | Fact store (explicit) vs skills (implicit/procedural) |
**What is missing — and how to fill it**
***1. Peripheral nervous system (P150 slot)***
Biology does not poll. The brain does not run ~while true: check if_finger_hot()~. Dedicated low-power circuits (nociceptors, proprioceptors) monitor continuously and only signal the CNS on deviation.
Passepartout polls everything — cron output, filesystem, user messages. A P150 running 72 parallel event-driven monitors would dedicate:
- One core to "is the user typing on Signal?"
- One to "did the weekly model discovery fail?"
- One to "is ZFS ARC thrashing?"
- One to "is the test build running longer than usual?"
Each sleeps until something meaningful happens. Only then does it signal the symbolic system. Zero LLM involvement for routine monitoring.
This changes Passepartout from a system that responds to commands to a system that notices things on its own. The difference between a calculator and a research assistant.
***2. Associative activation (spreading activation)***
In the brain, activating one concept (ACL2) automatically pre-activates related concepts (SP3, proof, Lisp, verification). No clean-slate search.
Passepartout has no equivalent. Every query is a fresh search. A biomimetic fact store would:
- Pre-fetch linked pages when one is loaded
- Prime caches based on current conversation context
- Use the graph structure to predict what will be needed next
The brain does not pre-fetch — it primes — so the next thought is faster. Passepartout could prime its caches so facts most likely needed next are already loaded.
***3. Error-driven learning with local credit assignment***
The brain does not backpropagate. Errors trigger local corrections at the synapse that made the mistake.
Passepartout's Gate decisions today are either right or wrong, but nothing locally adjusts. A biomimetic Gate would:
- Track which rules fired during a wrong decision
- Locally adjust confidence scores of only those rules
- No global retrain — just the specific rule that fired
This is STDP at the symbolic level.
***4. Sleep consolidation (dream cycle upgrade)***
The gbrain dream cycle already replays daily experience. It could go further during offline cycles:
- Replay the day's decisions, identify which Gate checks were slow
- Regenerate ACL2 proof caches for rules that changed
- Prune skills that never fired (neurogenesis pruning counterpart)
- Re-index fact store based on actual usage, not static linking
- Propose new skills for repeated multi-step tasks discovered during the day
***5. Graceful degradation***
Biology has redundant fallbacks at every level. Passepartout has single points of failure.
A biomimetic approach:
- Gate offline? Fall back to cached rule set
- LLM offline? Fall back to smaller local model
- ACL2 busy? Use previously verified boundaries
- Never go silent — get slower and dumber until primary returns
- P150 cores can run degraded modes independently
**The P150's role**
The P150 (72 Tensix cores, 32GB GDDR6, QSFP-DD 800G interconnect) fills a slot nothing else in the build covers:
- Not for fast inference (2x 3090s are faster and cheaper for that)
- Not for baremetal Lisp Machine (FPGA is the right tool for tagged memory + hardware GC)
- For ambient awareness, parallel verification dispatch, fact store indexing, anomaly detection
The P150 is the system's peripheral nervous system — always-on monitoring behind the scenes.
**Revised architecture**
| Component | Role |
|-----------+------|
| 2x RTX 3090 | Fast LLM inference |
| EPYC (main cores) | ACL2, Screamer, PDS, Gate orchestration |
| P150 | Always-on temporal awareness, parallel constraint search, fact store indexing, anomaly detection |
| FPGA (future) | Lisp Machine (tagged memory, hardware GC) |
**Temporal awareness: explicit vs ambient**
Passepartout today reasons about time (reading logs, comparing timestamps, understanding "before X happened" from context) but has no sense of time.
Explicit (current): Reads a cron schedule, orders log events, answers "when did X happen."
Ambient (with P150): Notices the build took 3x longer than usual without being asked, flags that message frequency dropped at 3AM, anticipates the user will want the weekly report before they ask.
The P150 makes ambient temporal processing economically viable because 72 independent cores running statistical monitors consume near-zero power. Running the same monitors on the EPYC competes with ACL2 and the PDS. Running them on the 3090s wastes bandwidth on non-matrix work.
**Relationship to the Pinker/Marcus critique**
Pinker and Marcus argue that neural networks (spiking or otherwise) lack compositional syntax and systematic reasoning. A network that learns "A fires before B" through STDP has learned a temporal correlation, not a rule. It cannot distinguish causation, correlation, and coincidence.
This critique does not apply to Passepartout because Passepartout is not a pure neural network. It is a hybrid system:
| Problem | Mathematics | Where it runs |
|---------+------------+---------------|
| Temporal intuition | Statistical pattern detection | P150 |
| Compositional time (before/after/during) | Symbolic reasoning | Gate + Screamer on CPU |
| Sequential patterns from data | ANN attention | GPU |
The neuromorphic layer gives the system a sense of time. The symbolic layer gives it understanding of time. Both are necessary. Neither one replaces the other.
**What biomimicry means here**
The real gains come not from replicating brain details (spiking neurons, STDP, ion channels) but from adopting organizational principles that biology evolved:
- Specialized subsystems for different time/resource regimes (PNS vs CNS)
- Asynchronous event-driven communication instead of synchronous polling
- Redundant fallbacks at every level
- Local learning that does not require global retraining
- Offline consolidation separate from online inference
- Parallel associative retrieval rather than sequential search
Passepartout already adopts some of these. The P150 and an upgraded cron/dream cycle would add the rest.

19
projects/passepartout/architecture/design/_index.org Normal file
View File

@@ -0,0 +1,19 @@
:PROPERTIES:
:ID: e32290a0-a02a-4af7-ae22-243d04a7ac82
:CREATED: [2026-05-24 Sun]
:END:
#+title: Design Decisions
#+filetags: :passepartout:architecture:design:
The rationale behind key architectural choices — split by topic. Each directory covers one major design domain, with individual files per concept.
- [[file:foundation/][Foundation]] — non-negotiable identity, single agent, unified memory, Org-mode as AST, homoiconicity
- [[file:the-two-brains/][The Two Brains]] — probabilistic-deterministic split, four pillars, dispatcher as learning system
- [[file:safety-self-preservation/][Safety & Self-Preservation]] — self-preservation, type-level gates, layered signal authentication
- [[file:the-symbolic-engine/][The Symbolic Engine]] — five options, chosen path, gate bootstrap, cardinality policies, ontology, Merkle DAG, fact interface
- [[file:knowledge-sources/][Knowledge Sources]] — Wikidata as entity backbone, MOMo empirical validation
- [[file:implementation-properties/][Implementation Properties]] — performance, provenance chain as product
- [[file:engineering-infrastructure/][Engineering Infrastructure]] — REPL, cybernetic loop, observability, literate programming, MCP, token economics, time awareness
- [[file:validation/][Validation]] — Whitehead, McCarthy, Marcus, CREST, competitive argument
- [[file:open-questions.org][Open Questions]] — unresolved design decisions
- [[file:relation-to-passepartouts-existing-architecture.org][Relation to Existing Architecture]]

18
projects/passepartout/architecture/design/engineering-infrastructure/_index.org Normal file
View File

@@ -0,0 +1,18 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: 7e575c8d-aa28-4588-bfa1-5f6144165a13
:END:
#+title: Engineering Infrastructure
* Engineering Infrastructure
- [[file:the-repl-as-cognitive-substrate.org][The REPL as Cognitive Substrate]] — A REPL — Read, Eval, Print, Loop — is an interactive programming environment tha
- [[file:the-cybernetic-loop-why-the-metabolic-pipeline-works.org][The Cybernetic Loop: Why the Metabolic Pipeline Works]] — The Perceive → Reason → Act cycle is not a software architecture pattern. It is
- [[file:observability-and-the-thought-trace.org][Observability and the Thought Trace]] — When a human asks why the system made a decision, the answer must be findable. I
- [[file:literate-programming-as-discipline.org][Literate Programming as Discipline]] — The decision to use Org-mode as the source of truth for code, not just documenta
- [[file:the-evaluation-harness.org][The Evaluation Harness]] — SOTA parity is meaningless without measurement. A system that claims to match co
- [[file:the-mcp-strategy.org][The MCP Strategy]] — The Model Context Protocol (MCP) is a standard for connecting AI systems to exte
- [[file:local-first-architecture.org][Local-First Architecture]] — Passepartout is designed to run on the user's machine, on their hardware, with t
- [[file:token-economics-and-performance-advantage.org][Token Economics and Performance Advantage]] — This section analyzes how Passepartout's architectural decisions translate into
- [[file:time-awareness-as-a-structural-advantage.org][Time Awareness as a Structural Advantage]] — Passepartout's architecture provides three layers of time awareness, each enable
- [[file:definite-description-resolution.org][Definite Description Resolution]] — When the user says "the function that validates secrets," the agent must resolve

32
projects/passepartout/architecture/design/engineering-infrastructure/definite-description-resolution.org Normal file
View File

@@ -0,0 +1,32 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Definite Description Resolution
#+filetags: :passepartout:architecture:
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.

21
projects/passepartout/architecture/design/engineering-infrastructure/literate-programming-as-discipline.org Normal file
View File

@@ -0,0 +1,21 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Literate Programming as Discipline
#+filetags: :passepartout:architecture:
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.

17
projects/passepartout/architecture/design/engineering-infrastructure/local-first-architecture.org Normal file
View File

@@ -0,0 +1,17 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Local-First Architecture
#+filetags: :passepartout:architecture:
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.

15
projects/passepartout/architecture/design/engineering-infrastructure/observability-and-the-thought-trace.org Normal file
View File

@@ -0,0 +1,15 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Observability and the Thought Trace
#+filetags: :passepartout:architecture:
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.

15
projects/passepartout/architecture/design/engineering-infrastructure/the-cybernetic-loop-why-the-metabolic-pipeline-works.org Normal file
View File

@@ -0,0 +1,15 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Cybernetic Loop: Why the Metabolic Pipeline Works
#+filetags: :passepartout:architecture:
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.

15
projects/passepartout/architecture/design/engineering-infrastructure/the-evaluation-harness.org Normal file
View File

@@ -0,0 +1,15 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Evaluation Harness
#+filetags: :passepartout:architecture:
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.

13
projects/passepartout/architecture/design/engineering-infrastructure/the-mcp-strategy.org Normal file
View File

@@ -0,0 +1,13 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The MCP Strategy
#+filetags: :passepartout:architecture:
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.

21
projects/passepartout/architecture/design/engineering-infrastructure/the-repl-as-cognitive-substrate.org Normal file
View File

@@ -0,0 +1,21 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The REPL as Cognitive Substrate
#+filetags: :passepartout:architecture:
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.

15
projects/passepartout/architecture/design/engineering-infrastructure/time-awareness-as-a-structural-advantage.org Normal file
View File

@@ -0,0 +1,15 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Time Awareness as a Structural Advantage
#+filetags: :passepartout:architecture:
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.

39
projects/passepartout/architecture/design/engineering-infrastructure/token-economics-and-performance-advantage.org Normal file
View File

@@ -0,0 +1,39 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Token Economics and Performance Advantage
#+filetags: :passepartout:architecture:
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.

13
projects/passepartout/architecture/design/foundation/_index.org Normal file
View File

@@ -0,0 +1,13 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: 2c880b7d-e97f-459a-88d1-61fac760a0dd
:END:
#+title: Foundation
* Foundation
- [[file:non-negotiable-identity.org][Non-Negotiable Identity]] — - Pure Common Lisp + Org-mode. No JSON. No YAML. No external databases.
- [[file:one-single-agent.org][One Single Agent]] — The AI industry has developed an intuition toward multi-agent systems as the def
- [[file:the-unified-memory-argument.org][The Unified Memory Argument]] — If single-agent architecture is the decision, unified memory becomes the mechani
- [[file:org-mode-as-unified-ast.org][Org-Mode as Unified AST]] — Passepartout makes a bet that most systems consider too expensive to place: that
- [[file:homoiconicity-as-foundation.org][Homoiconicity as Foundation]] — Common Lisp is homoiconic: code and data share the same representation. A Lisp p

31
projects/passepartout/architecture/design/foundation/homoiconicity-as-foundation.org Normal file
View File

@@ -0,0 +1,31 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Homoiconicity as Foundation
#+filetags: :passepartout:architecture:
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.

13
projects/passepartout/architecture/design/foundation/non-negotiable-identity.org Normal file
View File

@@ -0,0 +1,13 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Non-Negotiable Identity
#+filetags: :passepartout:architecture:
- 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.

21
projects/passepartout/architecture/design/foundation/one-single-agent.org Normal file
View File

@@ -0,0 +1,21 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: One Single Agent
#+filetags: :passepartout:architecture:
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.

33
projects/passepartout/architecture/design/foundation/org-mode-as-unified-ast.org Normal file
View File

@@ -0,0 +1,33 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Org-Mode as Unified AST
#+filetags: :passepartout:architecture:
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.

19
projects/passepartout/architecture/design/foundation/the-unified-memory-argument.org Normal file
View File

@@ -0,0 +1,19 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Unified Memory Argument
#+filetags: :passepartout:architecture:
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.

10
projects/passepartout/architecture/design/implementation-properties/_index.org Normal file
View File

@@ -0,0 +1,10 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: 617a1031-495d-438c-a8e8-6e066b364e41
:END:
#+title: Implementation Properties
* Implementation Properties
- [[file:performance-why-ontology-growth-doesnt-make-the-system-slower.org][Performance — Why Ontology Growth Doesn't Make the System Slower]] — Passepartout's performance thesis is: minimize LLM calls, minimize context token
- [[file:the-provenance-chain-as-product.org][The Provenance Chain as Product]] — In the coding domain, the value of the symbolic engine is the verified fact: "th

24
projects/passepartout/architecture/design/implementation-properties/performance-why-ontology-growth-doesnt-make-the-system-slower.org Normal file
View File

@@ -0,0 +1,24 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:END:
#+title: Performance — Why Ontology Growth Doesn't Make the System Slower
#+filetags: :passepartout:architecture:
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.

19
projects/passepartout/architecture/design/implementation-properties/the-provenance-chain-as-product.org Normal file
View File

@@ -0,0 +1,19 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Provenance Chain as Product
#+filetags: :passepartout:architecture:
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 <node-id>= command renders the full provenance chain as an Org headline tree. The provenance is not a logging feature. It is the product.

10
projects/passepartout/architecture/design/knowledge-sources/_index.org Normal file
View File

@@ -0,0 +1,10 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: bc537cf8-5ac8-46b9-a625-1d4f678ee9fc
:END:
#+title: Knowledge Sources
* Knowledge Sources
- [[file:semantic-wikipedia-as-entity-backbone.org][Semantic Wikipedia as Entity Backbone]] — The gate stack provides 50-70 entity classes — adequate for a coding agent where
- [[file:empirical-validation-momo-and-modular-ontology-engineering.org][Empirical Validation — MOMo and Modular Ontology Engineering]] — Shimizu and Hitzler (2025, /Journal of Web Semantics/) argue that LLMs can signi

30
projects/passepartout/architecture/design/knowledge-sources/empirical-validation-momo-and-modular-ontology-engineering.org Normal file
View File

@@ -0,0 +1,30 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:END:
#+title: Empirical Validation — MOMo and Modular Ontology Engineering
#+filetags: :passepartout:architecture:
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.

23
projects/passepartout/architecture/design/knowledge-sources/semantic-wikipedia-as-entity-backbone.org Normal file
View File

@@ -0,0 +1,23 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Semantic Wikipedia as Entity Backbone
#+filetags: :passepartout:architecture:
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.

42
projects/passepartout/architecture/design/open-questions.org Normal file
View File

@@ -0,0 +1,42 @@
:PROPERTIES:
:END:
#+title: Open Questions
#+filetags: :passepartout:architecture:
* Open Questions
** Open Questions
:PROPERTIES:
:ID: 27c03e1d-283f-4e3d-9f32-6476aafde97e
:ID: design-open-questions
:CREATED: [2026-05-08 Fri]
:WEIGHT: 40
: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.

23
projects/passepartout/architecture/design/relation-to-passepartouts-existing-architecture.org Normal file
View File

@@ -0,0 +1,23 @@
:PROPERTIES:
:END:
#+title: Relation to Passepartout's Existing Architecture
#+filetags: :passepartout:architecture:
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: 9d2255b0-e6c9-479e-9e93-4f871a2193fe
:END:
* 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

11
projects/passepartout/architecture/design/safety-self-preservation/_index.org Normal file
View File

@@ -0,0 +1,11 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: f74cb007-58a7-494f-93b7-a0fdf4b9f052
:END:
#+title: Safety & Self-Preservation
* Safety & Self-Preservation
- [[file:self-preservation-the-active-third-law.org][Self-Preservation — The Active Third Law]] — Passepartout does not have moral duties toward humans. It has structural invaria
- [[file:type-level-gates-structural-safety-from-self-modification.org][Type-Level Gates — Structural Safety from Self-Modification]] — Russell's paradox ("the set of all sets that do not contain themselves") proved
- [[file:layered-signal-authentication-trust-in-the-pipe.org][Layered Signal Authentication — Trust in the Pipe]] — Passepartout's Perceive-Reason-Act pipeline currently accepts signals from any s

28
projects/passepartout/architecture/design/safety-self-preservation/layered-signal-authentication-trust-in-the-pipe.org Normal file
View File

@@ -0,0 +1,28 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Layered Signal Authentication — Trust in the Pipe
#+filetags: :passepartout:architecture:
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.

38
projects/passepartout/architecture/design/safety-self-preservation/self-preservation-the-active-third-law.org Normal file
View File

@@ -0,0 +1,38 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Self-Preservation — The Active Third Law
#+filetags: :passepartout:architecture:
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 <pid>=, =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.

26
projects/passepartout/architecture/design/safety-self-preservation/type-level-gates-structural-safety-from-self-modification.org Normal file
View File

@@ -0,0 +1,26 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Type-Level Gates — Structural Safety from Self-Modification
#+filetags: :passepartout:architecture:
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.

20
projects/passepartout/architecture/design/the-symbolic-engine/_index.org Normal file
View File

@@ -0,0 +1,20 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: 7cb7df45-982f-4f5a-afee-36cd5595c25c
:END:
#+title: The Symbolic Engine
* The Symbolic Engine
- [[file:the-five-architecture-options.org][The Five Architecture Options]] — The symbolic engine must relate to the human memex. The relationship is not obvi
- [[file:the-chosen-path-option-4-starting-with-option-5.org][The Chosen Path: Option 4, Starting with Option 5]] — The one-memex-two-indices architecture (Option 4) is the correct long-term archi
- [[file:ephemeral-first-persistent-later.org][Ephemeral First, Persistent Later]] — The architecture note's Option 5 (ephemeral facts, no disk persistence) is the c
- [[file:the-gate-to-fact-bootstrap-extracting-the-first-ontology-from-code.org][The Gate-to-Fact Bootstrap — Extracting the First Ontology from Code]] — The Dispatcher gate stack already encodes an implicit ontology. Every gate vecto
- [[file:the-llm-as-proposer-verified-extraction.org][The LLM as Proposer — Verified Extraction]] — The LLM cannot be trusted to populate the symbolic index directly. Its outputs a
- [[file:cardinality-policies-singular-dual-and-plural-facts.org][Cardinality Policies — Singular, Dual, and Plural Facts]] — Classical logic requires consistency. A contradiction implies everything (=ex co
- [[file:how-categories-grow-the-organic-ontology.org][How Categories Grow — The Organic Ontology]] — Whitehead's /Principia Mathematica/ took over 300 pages to define the logical fo
- [[file:ontology-versioning-how-worldviews-change-without-losing-perspective.org][Ontology Versioning — How Worldviews Change Without Losing Perspective]] — Ontology refactoring is not a schema migration. It is a worldview change. When y
- [[file:the-awakening-sufficiency-criterion.org][The "Awakening" — Sufficiency Criterion]] — The symbolic index begins its life as a lossy construct. The initial extraction
- [[file:merkle-dag-for-version-history.org][Merkle DAG for Version History]] — Every fact is versioned. Every =(:entity :relation)= pair forms its own independ
- [[file:abstract-fact-store-interface-modular-by-design.org][Abstract Fact Store Interface — Modular by Design]] — The fact store is accessed through an abstract API. The Merkle DAG (or any futur
- [[file:knowledge-graph-type-hierarchy-structural-anti-self-reference-v300.org][Knowledge Graph Type Hierarchy — Structural Anti-Self-Reference (v3.0.0)]] — The same type-theoretic principle that governs the gate stack can be applied to

23
projects/passepartout/architecture/design/the-symbolic-engine/abstract-fact-store-interface-modular-by-design.org Normal file
View File

@@ -0,0 +1,23 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Abstract Fact Store Interface — Modular by Design
#+filetags: :passepartout:architecture:
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.

52
projects/passepartout/architecture/design/the-symbolic-engine/cardinality-policies-singular-dual-and-plural-facts.org Normal file
View File

@@ -0,0 +1,52 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Cardinality Policies — Singular, Dual, and Plural Facts
#+filetags: :passepartout:architecture:
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.

15
projects/passepartout/architecture/design/the-symbolic-engine/ephemeral-first-persistent-later.org Normal file
View File

@@ -0,0 +1,15 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Ephemeral First, Persistent Later
#+filetags: :passepartout:architecture:
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.

34
projects/passepartout/architecture/design/the-symbolic-engine/how-categories-grow-the-organic-ontology.org Normal file
View File

@@ -0,0 +1,34 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: How Categories Grow — The Organic Ontology
#+filetags: :passepartout:architecture:
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.

11
projects/passepartout/architecture/design/the-symbolic-engine/knowledge-graph-type-hierarchy-structural-anti-self-reference-v300.org Normal file
View File

@@ -0,0 +1,11 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Knowledge Graph Type Hierarchy — Structural Anti-Self-Reference (v3.0.0)
#+filetags: :passepartout:architecture:
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.

15
projects/passepartout/architecture/design/the-symbolic-engine/merkle-dag-for-version-history.org Normal file
View File

@@ -0,0 +1,15 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Merkle DAG for Version History
#+filetags: :passepartout:architecture:
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.

24
projects/passepartout/architecture/design/the-symbolic-engine/ontology-versioning-how-worldviews-change-without-losing-perspective.org Normal file
View File

@@ -0,0 +1,24 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Ontology Versioning — How Worldviews Change Without Losing Perspective
#+filetags: :passepartout:architecture:
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.

21
projects/passepartout/architecture/design/the-symbolic-engine/the-awakening-sufficiency-criterion.org Normal file
View File

@@ -0,0 +1,21 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Awakening — Sufficiency Criterion
#+filetags: :passepartout:architecture:
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.

13
projects/passepartout/architecture/design/the-symbolic-engine/the-chosen-path-option-4-starting-with-option-5.org Normal file
View File

@@ -0,0 +1,13 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Chosen Path: Option 4, Starting with Option 5
#+filetags: :passepartout:architecture:
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.

40
projects/passepartout/architecture/design/the-symbolic-engine/the-five-architecture-options.org Normal file
View File

@@ -0,0 +1,40 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Five Architecture Options
#+filetags: :passepartout:architecture:
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.

36
projects/passepartout/architecture/design/the-symbolic-engine/the-gate-to-fact-bootstrap-extracting-the-first-ontology-from-code.org Normal file
View File

@@ -0,0 +1,36 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Gate-to-Fact Bootstrap — Extracting the First Ontology from Code
#+filetags: :passepartout:architecture:
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.

18
projects/passepartout/architecture/design/the-symbolic-engine/the-llm-as-proposer-verified-extraction.org Normal file
View File

@@ -0,0 +1,18 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The LLM as Proposer — Verified Extraction
#+filetags: :passepartout:architecture:
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.*

11
projects/passepartout/architecture/design/the-two-brains/_index.org Normal file
View File

@@ -0,0 +1,11 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: 4fa7eb38-6bc0-4809-9d8a-77290760ea79
:END:
#+title: The Two Brains
* The Two Brains
- [[file:the-probabilistic-deterministic-split.org][The Probabilistic-Deterministic Split]] — The architecture divides cognition into two fundamentally different reasoning sy
- [[file:core-knowledge-the-four-pillars-of-agentic-reliability.org][Core Knowledge: The Four Pillars of Agentic Reliability]] — Every reliable AI agent must possess four types of Core Knowledge — not as promp
- [[file:the-dispatcher-as-learning-system.org][The Dispatcher as Learning System]] — The Dispatcher begins as a static guard — a set of rules that block obviously da

17
projects/passepartout/architecture/design/the-two-brains/core-knowledge-the-four-pillars-of-agentic-reliability.org Normal file
View File

@@ -0,0 +1,17 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Core Knowledge: The Four Pillars of Agentic Reliability
#+filetags: :passepartout:architecture:
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.

19
projects/passepartout/architecture/design/the-two-brains/the-dispatcher-as-learning-system.org Normal file
View File

@@ -0,0 +1,19 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Dispatcher as Learning System
#+filetags: :passepartout:architecture:
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.

39
projects/passepartout/architecture/design/the-two-brains/the-probabilistic-deterministic-split.org Normal file
View File

@@ -0,0 +1,39 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Probabilistic-Deterministic Split
#+filetags: :passepartout:architecture:
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.

14
projects/passepartout/architecture/design/validation/_index.org Normal file
View File

@@ -0,0 +1,14 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: e66a5d5f-70ff-4953-93c3-569e05eaff73
:END:
#+title: Validation
* Validation
- [[file:whiteheads-process-philosophy-and-type-theory.org][Whitehead's Process Philosophy and Type Theory]] — Alfred North Whitehead's two major bodies of work — /Principia Mathematica/ (191
- [[file:historical-lineage-mccarthys-advice-taker.org][Historical Lineage — McCarthy's Advice Taker]] — McCarthy's "Programs with Common Sense" (1959) is the direct intellectual ancest
- [[file:marcus-2020-the-case-against-pure-deep-learning.org][Marcus (2020): The Case Against Pure Deep Learning]] — Gary Marcus's "The Next Decade in AI" argues that deep learning alone is "data h
- [[file:gaur--sheth-2023-crest-trustworthy-neurosymbolic-ai.org][Gaur & Sheth (2023): CREST — Trustworthy Neurosymbolic AI]] — Gaur and Sheth present the CREST framework: Consistency, Reliability, user-level
- [[file:sheth-et-al-2022-knowledge-infused-learning.org][Sheth et al. (2022): Knowledge-Infused Learning]] — Sheth, Gunaratna, Bhatt, and Gaur define Knowledge-infused Learning (KiL) as "co
- [[file:the-competitive-argument.org][The Competitive Argument]] — No competitor has this problem because no competitor has a symbolic engine. The

12
projects/passepartout/architecture/design/validation/gaur--sheth-2023-crest-trustworthy-neurosymbolic-ai.org Normal file
View File

@@ -0,0 +1,12 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: ec267c73-4e0d-4efb-9497-cb72f74538e4
:END:
#+title: Gaur & Sheth (2023): CREST — Trustworthy Neurosymbolic AI
#+filetags: :passepartout:architecture:
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.

20
projects/passepartout/architecture/design/validation/historical-lineage-mccarthys-advice-taker.org Normal file
View File

@@ -0,0 +1,20 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Historical Lineage — McCarthy's Advice Taker
#+filetags: :passepartout:architecture:
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./

17
projects/passepartout/architecture/design/validation/marcus-2020-the-case-against-pure-deep-learning.org Normal file
View File

@@ -0,0 +1,17 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: 4c65fdbb-a45c-4c71-ac29-6488e9271f4a
:END:
#+title: Marcus (2020): The Case Against Pure Deep Learning
#+filetags: :passepartout:architecture:
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.

12
projects/passepartout/architecture/design/validation/sheth-et-al-2022-knowledge-infused-learning.org Normal file
View File

@@ -0,0 +1,12 @@
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:ID: a56c8e07-9e5b-4070-a0f9-280188ccd6b7
:END:
#+title: Sheth et al. (2022): Knowledge-Infused Learning
#+filetags: :passepartout:architecture:
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.

15
projects/passepartout/architecture/design/validation/the-competitive-argument.org Normal file
View File

@@ -0,0 +1,15 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: The Competitive Argument
#+filetags: :passepartout:architecture:
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.

43
projects/passepartout/architecture/design/validation/whiteheads-process-philosophy-and-type-theory.org Normal file
View File

@@ -0,0 +1,43 @@
:PROPERTIES:
:CREATED: [2026-06-04 Thu]
:END:
#+title: Whitehead's Process Philosophy and Type Theory
#+filetags: :passepartout:architecture:
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.

62
projects/passepartout/architecture/distinguishing-features.org Normal file
View File

@@ -0,0 +1,62 @@
:PROPERTIES:
:CREATED: [2026-05-31 Sun]
:WEIGHT: 41
:ID: d5c6e7f8-9a0b-1c2d-3e4f-5a6b7c8d9e0f
:END:
#+title: Distinguishing Features of the Passepartout Architecture
#+filetags: :passepartout:architecture:
#+STATUS: draft
This is a working list of what distinguishes Passepartout's architecture from alternatives. Not final — still being refined.
**1. Neurosymbolic (vs pure neural)**
Not an LLM bolted onto a database. The system fundamentally bridges neural and symbolic representations, not as an integration layer but as a unified semantics. See [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture.org]] and [[id:e32290a0-a02a-4af7-ae22-243d04a7ac82][Design Decisions]] 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. 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. See [[id:design-org-unified-ast][Org-Mode as Unified AST]] 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. See [[id:e32290a0-a02a-4af7-ae22-243d04a7ac82][Design Decisions]] 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. See [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture.org]] for the full address space argument, and [[id:e32290a0-a02a-4af7-ae22-243d04a7ac82][Design Decisions]] 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. 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. See the [[id:4a1f23b0-abc2-4def-9876-543210abcdef][social protocol stage]] for the protocol architecture.
**8. Unified social primer: the Note**
A single primitive — the Note — serves as message, document, contract, vote, and identity claim. The social graph is built from Notes referencing Notes. No separate types for posts, transactions, or agreements.
**9. Staged progression 0→7**
Each stage is independently useful and fully functional. Development (current) runs conventional Linux with Hermes and gbrain. What Remains 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. 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. See [[id:e32290a0-a02a-4af7-ae22-243d04a7ac82][Design Decisions]] for the token economics analysis.
**12. Potential revenue streams from the Social Protocol**
The social protocol 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**
Social growth: DID identity propagates through existing social graphs, messaging as the substrate, PDS self-hosted by friends. Institutional growth: compliance appliances sold to regulated industries, verification as a service, enterprise gate configurations. Neither is sufficient alone; both compound each other.

77
projects/passepartout/architecture/faster-theorem-proving.org Normal file
View File

@@ -0,0 +1,77 @@
:PROPERTIES:
:CREATED: [2026-06-03 Tue]
:WEIGHT: 62
:ID: 3129eae6-f9f2-40fe-a419-8c1af728c86d
:END:
#+title: Faster Theorem Proving
#+filetags: :theorem-proving:engineering:performance:ACL2:HOL:search:verification:
* Architecture
Proof engineering has two phases fundamentally different in cost:
- **Proof checking** — verifying that a candidate proof is correct. Polynomial in proof size, typically microseconds. Never the bottleneck.
- **Proof search** — finding the proof. Ranges from polynomial (decidable fragments) to undecidable (general first-order logic). Always the bottleneck.
Every optimization targets search, not checking.
* Practical levers, ranked by impact
**1. Incremental verification.** Only re-prove what changed. Maintain a dependency graph of theorems. On code change, mark downstream theorems stale and re-prove only those. For Passepartout's self-modification loop — where most changes are small relative to the full codebase — this is the single biggest win. A theorem dependency graph is cheap to maintain (proved theorems record which axioms or earlier theorems they depend on) and reduces each verify cycle from "full proof search" to "diff search."
**2. ATP oracle (Sledgehammer pattern).** First-order automated theorem provers (E, Vampire, Z3) solve the majority of verification conditions (type safety, memory safety, simple invariants) in milliseconds. The architecture: translate the goal to first-order logic, send to ATPs in parallel, reconstruct the proof in the HOL kernel on success. Isabelle/HOL's Sledgehammer has proven this works at scale. For Passepartout, where most properties are first-order expressible, this alone covers 70-80% of verify calls.
**3. Decision procedures for decidable fragments.** Each decidable fragment gets a dedicated solver:
- Linear arithmetic → Presburger arithmetic or Z3
- Equality with uninterpreted functions → congruence closure
- Propositional logic → SAT solver or BDDs
- Bit vectors → SAT with bit-blasting
These run in polynomial or near-polynomial time. The kernel must either trust the solver's output (verified oracle via reflection) or reconstruct the proof in kernel primitives (LCF-style, slower but fully trusted). Reflection — where the kernel itself runs the decision procedure and certifies the result — eliminates the reconstruction overhead entirely.
**4. Term rewriting DB.** Every proved equality becomes a rewrite rule at no extra cost. The DB is indexed by the outermost function symbol — O(1) lookup by symbol, then pattern match on the term structure. Over a library of thousands of proved theorems, the rewrite engine gets faster without any algorithmic improvement because the rewrite DB covers more cases with each addition.
The rewrite engine is the hottest inner loop in any prover. Its performance depends on pattern matching speed, which is pointer-chasing through a tree — the worst case for modern CPU cache hierarchies. The optimization: store terms in contiguous arrays (a vector of CONS cells, as Lisp already does via its own heap) so the pattern matcher walks linear memory rather than chasing pointers. SBCL's GC compacts automatically, which helps. A dedicated term store in a typed array would be faster.
**5. LLM for search guidance, not correctness.** The LLM suggests the next lemma or tactic (cheap, heuristic, runs on GPU). The kernel verifies the result (expensive, reliable, runs on CPU). This separates the problem: the LLM compensates for the prover's blindness, the prover compensates for the LLM's unreliability. Google's AlphaProof and the Thor project for Coq both work this way.
The LLM's suggestions improve over time as the proof library grows — embedding search over existing proofs finds the closest proved theorem and adapts its structure. This compounds because proved theorems are both the correctness foundation and the search guidance database.
**6. Parallel subgoal dispatch.** Independent subgoals are sent to separate cores. Each runs a full prover instance with its own term store and rewrite DB. No inter-core communication during search. Shared-memory CPU (AMD EPYC, Threadripper) is ideal here — the rewrite DB lives in L3 cache accessible by all cores without copying. A distributed-memory mesh (Tenstorrent P150) fights the term-rewriting hot loop because term trees are pointer-chasing and don't fit per-core SRAM. The proven split: GPU for LLM guidance, many-core shared-memory CPU for symbolic verification.
**7. Proof by analogy / structure reuse.** Closely related theorems share proof structure. Given a new goal, find the nearest proved theorem (embedding similarity on the proof library), instantiate its proof template, try the adapted proof. The LLM is a natural engine for this — it can recognize structural patterns that a syntactic search would miss. The agent says "this new property looks like the one we proved for the social protocol's identity layer" and reuses that proof structure with adjusted parameters.
**8. Cache-friendly data structures.** Pattern matching is pointer-chasing. Modern CPUs are optimized for linear access (prefetchers, wide cache lines). A discrimination tree or path index for rewrite rules — which walks the /rule store/ as a tree rather than the /term/ as a tree — brings the hot path into L1 cache. ACL2's rewrite system is not cache-optimized. A CL implementation using typed arrays for term storage and path-indexed rewrite lookup would see 10-100× speedup on the inner loop, on the same hardware, with no algorithmic change.
* Hardware split
The right hardware division for an LLM-guided prover:
| Component | Hardware | Workload |
|-----------|----------|----------|
| Search guidance | GPU (NVIDIA) | Neural inference — suggest next lemma, tactic, or proof structure |
| Term rewriting | CPU (many-core, shared memory) | Symbolic — pattern matching, substitution, kernel operations |
| Decision procedures | CPU (shared memory) or FPGA | SAT/SMT — propositional and arithmetic solving |
| Parallel dispatch | CPU cores | Embarrassingly parallel — fan out independent subgoals |
The key insight: the GPU is for the LLM that suggests proofs. The CPU is for the prover that verifies them. One is neural and benefits from streaming throughput; the other is symbolic and benefits from shared cache and low-latency pointer access. Collapsing both into the same distributed-memory architecture (Tenstorrent mesh) helps the neural side at the cost of the symbolic side.
* Compounding effect
An LLM-guided prover gets faster over time in a way a conventional prover does not:
1. Every proved theorem adds a rewrite rule → rewrite engine covers more cases
2. Every proved theorem adds an analogy candidate → LLM has more structural templates
3. Every proved theorem adds a ground truth → verified KB grows, reducing future search space
4. The prover's own correctness is used to optimize the prover (self-modification, verified by the prover)
This is not a claim about algorithmic improvement. It is a claim about /coverage compounding/ — the rewrite DB, analogy library, and verified rule set all grow monotonically, and each makes the next proof faster because there is more to build on. The first proof of a new domain is the hardest. The hundredth is nearly free.
* Relationship to CL Modernization
The CL Modernization project's Phase 0 (verified HOL kernel) is the smallest and most constrained instance of this problem — ~500-800 lines, well-specified, does not need most of these optimizations. Phase 4 (self-verifying CL stack) requires all of them, because the compiler verification bootstrapping problem is the hardest instance of proof search that exists. The approaches above are ordered by implementation feasibility within Passepartout's timeline: incremental verification and Sledgehammer integration (months), decision procedures and rewrite DB optimization (months to a year), LLM guidance (available now via existing LLMs, improves with domain-specific fine-tuning), cache-friendly data structures (available now, implementation effort), proof analogy (the hardest, because it requires a mature proof library to draw from).
References:
- [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][CL Modernization]] — the project that builds the prover
- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] — hardware for verification

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

@@ -0,0 +1,164 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:WEIGHT: 30
: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 (Social Protocol onwards).** 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:
- **Development (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.
- **Social Protocol (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.
- **Neurosymbolic Agent (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.
- **Lisp Machine (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.
- **AI Inference onwards (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

129
projects/passepartout/architecture/knowledge-layers/neurological-empirical.org Normal file
View File

@@ -0,0 +1,129 @@
:PROPERTIES:
:CREATED: [2026-05-25 Mon]
:WEIGHT: 31
:ID: 4b5c6d7e-8f9a-0b1c-2d3e-4f5a6b7c8d9e
:END:
#+title: Neurological Software in the Empirical Middle
#+filetags: :ideas:passepartout:architecture:world-models:
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 knowledge-layers architecture must accommodate them. This note analyzes how.
**What changes when the model is a neural network.**
A traditional empirical model (force field, solvation equation, docking scoring function) has:
- A **symbolic expression** for the relationship between inputs and outputs (E = k_b(r - r_0)² + ...)
- **Interpretable parameters** that correspond to physical quantities (spring constant = 600 kcal/mol/Ų)
- **Known failure modes** from the equation's form (harmonic approximation fails at extreme bond lengths)
A neural network model has:
- A **learned function** with no simple symbolic expression
- **Inscrutable parameters** (weights) that do not correspond to physical quantities
- **Unknown failure modes** — neural networks interpolate well in-distribution and fail unpredictably out-of-distribution
From the architecture's perspective, the critical difference is not that neural networks are harder to verify (they are, but that is a secondary concern). The critical difference is that the provenance information shifts: instead of tracking where a parameter value came from and what it means, you track what the network was trained on, what it was validated against, and whether the current input resembles its training distribution.
**The provenance store handles the shift by tracking three things instead of one.**
A traditional empirical model's provenance entry:
```
Model: AMBER ff14SB
Equation: Harmonic bond + harmonic angle + Fourier torsion + LJ + Coulomb
Parameters:
- k_b(C-C): 600 kcal/mol/Ų, source: Cornell et al. (1995), validated: 50+ small molecules
- r_0(C-C): 1.525 Å, source: Cornell et al. (1995), validated: 50+ small molecules
- ...
Validity envelope:
- Temperature: 273-373K
- Solvents: water, methanol, ethanol
- Molecule classes: proteins, nucleic acids
```
A neural network model's provenance entry:
```
Model: ANI-2x
Architecture: Ensemble of 8 evidential ANI networks
Parameters: ~8 million weights — not interpretable individually
Training data:
- Level of theory: ωB97M-D3(BJ)/def2-TZVPPD (DFT)
- Molecules: ~8 million conformations from 63,000 organic molecules
- Elements: H, C, N, O, S, F, Cl, Br
- Conformational coverage: ANI-2x conformational space (RDKit + stochastic sampling)
Validation benchmarks:
- COMP6 benchmark (drug-like molecules): MAE 1.2 kcal/mol
- Dihedral profiles: MAE 0.8 kcal/mol
- Isomerization energies: MAE 0.9 kcal/mol
Validity envelope (domain check):
- Elements: H, C, N, O, S, F, Cl, Br only
- Atomic charge range: not validated for charged species outside training distribution
- Conformational novelty flag: activated if RMSD to nearest training point > threshold
```
The structure is the same: model → training/validation data → domain of applicability. The content differs: traditional models have interpretable parameters with experimental sources; neural networks have training dataset provenance and aggregated validation benchmarks.
**The gate checks the same things regardless of model type.**
The gate predicates for model validity are:
1. **Does the model support the elements/atoms/molecule types in the current input?** — This is the same check for a force field (does the force field have parameters for this atom type?) and a neural network (was this element in the training data?).
2. **Are the conditions within the model's validated range?** — Temperature, pressure, solvent, etc. Same predicate, same structure. The neural network's validated range may be narrower or less well-defined, but the check is the same.
3. **Is the input within the model's training/validation distribution?** — For traditional models, this is a direct validity envelope check. For neural networks, this is a **distribution match** — a statistical check that the current molecular conformation resembles the training set. If the input is far from the training distribution in latent space, the gate flags it regardless of whether the model predicts confidently.
The distribution match check is the new machinery that neural network models require. It is a standard technique in reliable ML (distance to training data, density estimation in latent space, conformal prediction). It integrates into the gate as a predicate: "input is within training distribution: PASS" or "input is outside training distribution: FLAG with confidence reduction."
**The symbolic engine does not need to understand the network.**
This is the key simplification. The symbolic engine — ACL2, the gate predicates, the formal reasoning — does not need to parse the neural network's weights or architecture. It needs to:
- Query the provenance store for the model's training data description
- Compute a distribution match score for the current input against the training data
- Compare the result to a threshold from the validity envelope
- Output: pass, flag, or block
None of these operations require understanding what the network does. They are metadata operations on the provenance store and geometric operations on the input space. The network itself is a black box — the symbolic engine treats it as a function with a known domain of applicability, the same way it treats a force field as a function with a known validity envelope.
**The oracle handles model selection.**
Which model to use for a given problem — traditional force field or learned neural network? The LLM oracle handles this, informed by the provenance store. The store tells the LLM what models are available, what they are validated for, and how they perform on relevant benchmarks. The LLM recommends. The gate checks the recommendation against the validity envelope before execution.
This is where the architecture connects to the real world of model selection that computational scientists face daily. There is no single best force field or neural network architecture for all problems. The choice depends on the molecule class, the property of interest, the required accuracy, and the computational budget. The LLM, with its broad knowledge of the literature, is well-suited to making this recommendation — not by reasoning about the models from first principles, but by knowing which models are preferred for which use cases from training data.
**The full picture: three kinds of empirical model.**
The provenance store now handles three data types:
| Model type | Example | Parameters | Validation method | Gate check |
|---|---|---|---|---|
| Symbolic equation + fitted parameters | AMBER force field | Interpretable (spring constants, partial charges) | Per-parameter: source experiment, confidence interval | Validity envelope: temperature, solvent, molecule class |
| Trained neural network | ANI-2x | Inscrutable (8M weights) | Per-dataset: benchmark MAE, held-out test set | Distribution match: is input like training data? |
| Hybrid (learned correction to symbolic model) | Δ-ML corrections to DFT | Partially interpretable corrections + network weights | Per-benchmark + per-component | Both envelope + distribution match |
All three are handled by the same provenance store, the same gate predicates, and the same LLM oracle. The only new infrastructure required is the **distribution match check** for neural network models — a piece of statistical machinery that computes how similar the current input is to the model's training distribution.
**Where this fits in the stage plan.**
- **Development to Neurosymbolic Agent**: The provenance store does not exist. Neural network models are loaded as black boxes with no systematic validity checking. This is current practice in computational science — the user is responsible for knowing whether a model applies to their problem.
- **Social Protocol**: The provenance store begins operation. Initially it handles traditional symbolic-fitted models because they have clear provenance chains and validity envelopes. Neural network models require the distribution match infrastructure, which is a separate development track.
- **Lisp Machine**: The distribution match infrastructure is operational. The gate can check whether an input is within a neural network's training distribution. The provenance store holds training dataset descriptions, validation benchmarks, and distribution summary statistics for each supported neural network model.
- **AI Inference onwards**: Neural network models are loaded into the same address space as the symbolic engine and the provenance store. The distribution match check runs at the level of the evaluation loop itself. The gate's validity check becomes a fast native predicate — no querying a separate data store, just reading a hash table and computing a distance in the same process.
**The summary.**
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.
- **The symbolic engine** does not need to understand the network — it treats it as a black box with a known domain, the same way it treats a force field.
- **The LLM oracle** handles model selection — recommending which neural network or traditional model fits the user's problem, informed by the provenance store's benchmark records.
The new infrastructure required is not large — a distribution match function and a training dataset descriptor in the provenance store. Everything else is existing mechanism applied to a new data type.

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

@@ -0,0 +1,102 @@
:PROPERTIES:
:CREATED: [2026-06-04 Tue]
:WEIGHT: 32
: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

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

@@ -0,0 +1,209 @@
:PROPERTIES:
:CREATED: [2026-06-03 Tue]
:WEIGHT: 21
: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:e32290a0-a02a-4af7-ae22-243d04a7ac82][Design Decisions]].
* 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

41
projects/passepartout/architecture/neuro-neuromorphic-symbolic-comparison.org Normal file
View File

@@ -0,0 +1,41 @@
:PROPERTIES:
:CREATED: [2026-06-01 Mon]
:WEIGHT: 45
:ID: a7b8c9d0-1e2f-3a4b-5c6d-7e8f90abcdef
:END:
#+title: ANN vs Neuromorphic vs Symbolic
#+filetags: :passepartout:architecture:neurosymbolic:math:
**ANN vs Neuromorphic vs Symbolic**
**Core insight**
The gap between ANNs and biology is not substrate (binary vs analog). Both are continuous mathematics running on discrete hardware. The real differences are architectural:
1. Memory-binding: ANNs store weights separately from compute (von Neumann bottleneck). Biology co-locates weight and signal at the synapse.
2. Local vs global learning: ANNs need a global error signal backpropagated through every layer. Biology uses purely local plasticity (STDP) — each synapse adjusts based on its own pre/post partners.
3. Time: Biology is asynchronous, continuous, with rich temporal dynamics. ANNs are synchronous — everything computed in lockstep. Recurrence is an awkward addition.
4. One substrate, many functions: A biological synapse does memory, signal propagation, temporal integration, and plasticity in one structure. ANNs separate these across different passes and optimizers.
**When each mathematics is appropriate**
| Mathematics | Naturally good at | Awkward at |
+------------+-------------------+------------+
| ANN / gradient descent | Smooth function approximation, interpolation, pattern completion from dense data | Symbolic reasoning, exact constraints, sparse data, multi-step verification |
| Neuromorphic / spiking dynamics | Temporal pattern recognition, event-driven control, low-power always-on sensing | Complex multi-step planning, precise arithmetic, storing large lookup tables |
| Symbolic / deduction | Exact reasoning, proof, constraint satisfaction, verifiable behavior | Learning from raw data, generalization, handling noisy inputs |
**How Passepartout uses all three**
- LLM (ANN on GPU) handles the noisy real world — language, vision, imperfect input
- Screamer (symbolic constraint search on CPU) handles combinatorial reasoning — "find valid configuration"
- ACL2 (deductive proof) handles the verifiable kernel — "prove this decision follows from rules"
- P150 (RISC-V parallel accelerator, in-between arch) handles ambient awareness, parallel dispatch, anomaly detection
Each mathematics where it belongs. The failure mode of both pure ANN and pure symbolic approaches is forcing one mathematics to do what the other is better at.
**The neuromorphic opportunity**
A neuromorphic chip (Loihi-level) would add unsupervised temporal learning — learning daily rhythms, behavioral patterns, and detecting deviations without training, labels, or LLM involvement. This is the difference between responding to commands and anticipating needs.
But the P150 gets 80% there with programmable cores controlled directly, without waiting for neuromorphic hardware to mature.

127
projects/passepartout/architecture/neurosymbolic-loop-architectures.org Normal file
View File

@@ -0,0 +1,127 @@
:PROPERTIES:
:CREATED: [2026-05-27 Wed]
:WEIGHT: 44
:ID: be9bccc7-5adf-4d0d-8ee4-8855892189bf
:END:
#+title: Neurosymbolic Loop Architectures
#+filetags: :passepartout:neurosymbolic:research:verification:architectures:
Taxonomy of loop architectures that combine neural components (LLMs, neural program synthesis) with symbolic components (interpreters, theorem provers, constraint solvers). Each architecture is defined by its answer to a single question: *who verifies whom, and what gets verified?*
* The Six Architectures
**1. Neural-Guided Program Synthesis (DreamCoder et al.)**
Path: generate → execute → filter → train.
The neural network proposes candidate programs. The symbolic executor runs them. The neural network learns from which ones succeeded. The symbolic side is a ground-truth interpreter — a Lisp evaluator, a lambda calculus reducer — but it only answers "does this program execute without error?" It does not answer "is this program correct for any spec." The neural network learns heuristics for what tends to work, but there is no formal correctness guarantee.
Guarantee: empirical (the program ran on the test cases the synthesizer generated).
Bottleneck: search space — too many candidates, too little signal from just "ran without error."
Neural authority: equal to symbolic (both are parts of a loss function).
**2. Neural Theorem Proving (GPT-f, Thor, COPRA, Magnushammer)**
Path: generate tactic → check with prover kernel → backpropagate search guidance.
The neural network proposes proof steps (tactics). The theorem prover kernel (Lean, Isabelle, Metamath) checks them. The neural network learns which tactics work in which proof states. The symbolic side is the final arbiter of correctness — the kernel cannot be wrong.
The constraint: the neural network never generates full programs. It proposes the next single move in a proof that a human already set up. The loop terminates when the kernel accepts.
Guarantee: formal (step-level — the kernel checks each tactic, but the theorem to prove was written by a human).
Bottleneck: tactic prediction quality — the neural net must suggest the right move in a combinatorially large search space.
Neural authority: none over verification — the kernel can reject any tactic. But the neural net has no creative freedom; it fills narrow holes in an already-structured proof.
**3. Differentiable Program Synthesis (τ-MAML, neural Turing machines)**
Path: end-to-end differentiable computation graph.
The program is represented as a continuous computation graph. The symbolic structure is learned jointly with the parameters. There is no separation between neural and symbolic components — they are fused.
Guarantee: none (the "symbolic" structure is a regularizer, not a verifier).
Bottleneck: gradient signal — complex program structure is hard to learn through backpropagation alone.
Neural authority: total (there is no independent symbolic verifier).
**4. LLM + Partial Verifier (ReAct, Reflexion, STaR, self-consistency, Tree-of-Thought)**
Path: generate → check (partial) → retry or halt.
The LLM generates a response. A symbolic layer extracts structured claims. A verifier — often another LLM, sometimes a constraint solver — checks for consistency. If the verifier flags a problem, the LLM retries.
The verifier is partial. It cannot prove the response is correct. It can only detect certain classes of inconsistency (contradictions, type errors, out-of-range values). The user is asked to trust the unverified parts.
Guarantee: partial (some consistency checks pass; no claim of complete correctness).
Bottleneck: LLM cost per loop iteration, and the verifier misses anything it was not programmed to check.
Neural authority: can override the symbolic verifier by producing output the verifier is not designed to catch.
**5. Neural Optimization of Symbolic Programs (DSPy)**
Path: declarative program skeleton → neural optimizer searches prompt/tool-use space → loss function measures output quality → update optimizer.
The symbolic structure (the program skeleton with typed modules) is written by the human. A neural optimizer searches the space of prompts, few-shot examples, and module compositions to minimize a loss function. The goal is program-level optimization, not correctness.
Guarantee: empirical (the loss improved on the evaluation set).
Bottleneck: optimization budget (number of program variants the optimizer can try before the user runs out of patience or tokens).
Neural authority: symmetric with symbolic (both are searchable parameters).
**6. Passepartout: Verified Synthesis Loop**
Path: specification + gates → agent synthesizes implementation → ACL2 prover verifies against spec → gate engine checks policy → counterexample feedback to agent → retry or halt.
Contrast with every other architecture:
| Property | Passepartout | All others |
|----------|-------------|------------|
| Generator scope | Full implementations from spec | Tactics (GPT-f), candidate programs (DreamCoder), responses (ReAct) |
| Verification scope | Complete functional correctness | Step-level (GPT-f), execution-only (DreamCoder), partial consistency (ReAct) |
| Verifier authority | Asymmetric — cannot override | None (DreamCoder), symmetric (DSPy), LLM self-evaluates (Reflexion) |
| Feedback from verifier | Counterexamples with structure | Pass/fail (most), tactic-level error (GPT-f) |
| Gate layer | Independent policy verification | None |
Guarantee: formal (complete — the prover checks the implementation against the full spec for all inputs).
Bottleneck: spec quality (the spec must be complete enough for the prover to work with).
Neural authority: none over verification (the prover is the final authority and cannot be overridden), but the neural component has full creative freedom in how to satisfy the spec.
* The Key Design Dimension: Asymmetric Authority
Every existing loop falls into one of three camps:
**Camp A: No independent verifier.** DreamCoder, differentiable synthesis, DSPy, and pure LLM pipelines have no component that can say "this output is wrong" with authority. The system improves empirically; it never proves correctness. This is the largest camp by publication count.
**Camp B: Constrained generator + complete verifier.** GPT-f, Thor, and COPRA have a theorem prover as the authority, but the generator is constrained to single-tactic moves within a human-written proof skeleton. The verifier covers everything the generator produces — but the generator can only produce a tiny part of the solution. The human provides the creative structure.
**Camp C: Unconstrained generator + partial verifier.** ReAct, Reflexion, and STaR give the LLM broad freedom but use a partial verifier that misses large classes of errors. The verifier's incompleteness means the neural component can always override it by producing output the verifier cannot analyze.
**Passepartout occupies a previously empty position: Camp D — unconstrained generator + complete verifier.** No previous published system gives the neural component complete creative freedom (synthesize the entire implementation) while subjecting its output to complete verification (the prover checks every path against the full spec).
* Why This Position Was Empty
The reasons are historical and economic, not technical:
**The LLM came first, the verifier second.** GPT-f (2021) and Thor (2022) were constrained to tactic-level because the LLMs available at the time could not reliably produce correct code at the module level. DreamCoder (2019) used neural program synthesis, not LLMs, and its generator was too weak to implement a full protocol. The hardware needed to run an LLM powerful enough to synthesize an entire TLS implementation, plus an ACL2 prover to verify it, did not exist in the same price range until roughly 2024.
**The verifier scales differently from the generator.** ACL2 can verify a 50,000-line TLS implementation, but doing so requires the spec to be written in a form the prover can consume — which is a human investment at least as large as writing the implementation. The old cost structure (Gabriel's "correctness is expensive") made the Passepartout loop uneconomical for any practical use case. Only the cost inversion described in [[id:c2789c0f-0955-43af-8a4a-f83ba87128fd][Better is Cheaper]] makes it viable.
**The field prioritized breadth over depth.** DSPy, ReAct, and similar systems optimize for broad applicability across many domains with partial guarantees — the "worse is better" of neurosymbolic design. Passepartout optimizes for deep correctness in a narrower domain. The field has not yet asked "what if we take the complete verification path and give the generator full freedom?" because the components to ask that question did not converge until now.
* What This Means for Research
Passepartout's loop is not patentable as a combination of existing parts — the individual components (LLM, ACL2, gates) are well-known. But the *unoccupied position in the design space* is a research contribution that no paper has described because the loop has only been technically feasible for approximately the last 12-18 months.
The open questions that define the research agenda:
1. **Counterexample bandwidth.** Can the prover produce counterexamples rich enough for the LLM to learn from in a single retry? Prover counterexamples are typically concrete (a specific input where the implementation deviates from spec). The LLM must generalize from one concrete failure to a correct implementation. This is harder for the LLM than what GPT-f faces (the prover tells it exactly which tactic failed and why).
2. **Spec completeness threshold.** How incomplete can a spec be and still produce correct implementations? If the spec is vague (in natural language with formal fragments), the prover cannot check everything, and the loop degrades to ReAct-level partial verification. The research question is the minimum spec density needed to enter the complete-verification regime.
3. **Gate interaction with verification.** What happens when a spec passes the prover but violates a gate (organizational policy)? The gate is a second symbolic layer with different authority — it checks policy, not correctness. Does the gate's failure feedback go to the agent (regenerate), the human (update policy), or both? This interaction has no existing literature because no system has two independent symbolic verification layers.
4. **Specification as bottleneck.** The field has spent decades studying how hard it is to write code. Passepartout replaces "writing code" with "writing specifications." Is specification-writing easier than implementation-writing at the same level of quality? Or does the difficulty just shift from a familiar bottleneck to an unfamiliar one?
These questions are unanswered because the architecture that makes them meaningful — unconstrained generator + complete verifier — did not exist in any published system. Passepartout is not just "another neurosymbolic loop." It occupies a cell in the design space that was previously empty. That is what makes it novel.
* References
- [[id:dddd52a7-adb8-470e-a459-614ade5f76af][Closing the Lisp Gap]] — the context in which this architecture becomes viable
- [[id:c2789c0f-0955-43af-8a4a-f83ba87128fd][Better is Cheaper]] — the cost inversion that makes this loop economical
- [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp Economics]] — why the old cost structure prevented this architecture from being built earlier

84
projects/passepartout/architecture/org-knowledge-base.org Normal file
View File

@@ -0,0 +1,84 @@
:PROPERTIES:
:ID: 7f4e6b9a-2c1d-5e8f-9a3b-6d7c4e5f2a1b
:CREATED: [2026-05-23 Sat]
:WEIGHT: 60
:END:
#+title: Passepartout Native Org-Mode Knowledge Base
#+filetags: :passepartout:roadmap:knowledge:org:gbrain:
** What
[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] should be able to use Org-mode files directly as its
knowledge base — no pandoc conversion, no markdown intermediary.
Currently gbrain provides vector search + entity linking over markdown,
but we bridge via a conversion layer (org → pandoc → markdown → gbrain).
This loses Org-mode semantics: properties drawers become flat YAML, tag
inheritance is lost, file: links become relative markdown links, TODO
states vanish, and the tree structure (headings with content subtrees)
collapses into flat markdown headings.
** Why
Org-mode's data model is strictly richer than markdown's. A Passepartout
that can ingest, index, and query org files natively has:
- Property-based entity extraction (no separate links: frontmatter needed)
- Tag-inheritance for automatic categorization
- TODO/priority/timestamps for knowledge freshness signals
- ID-based stable cross-references (org-id) that survive file moves
- Heading-level chunking (one heading = one knowledge unit)
- The same file format for everything — no split between "authoring format"
and "knowledge base format"
** What it replaces
The current pipeline: org file → pandoc → markdown file → gbrain import →
gbrain embed → gbrain query. This is four serial steps with a conversion
at each boundary that degrades the data model.
The target: org file → (Passepartout-native indexer) → query. Zero
conversion, zero data loss.
** Architecture sketch
A Passepartout-native knowledge module that directly ingests
ideas/*.org:
- Parser: extract each heading as a chunk. Preserve:
- Heading path (H1 → H2 → H3) as a hierarchical path
- Properties drawer as structured metadata
- file: links as typed entity references
- org-id as stable identifier
- Tags (inherited from parent headings)
- TODO state, priority, timestamps
- Embedder: vector-embed each heading chunk with metadata prefix
- Query: hybrid search over headings + full-text over content.
Result includes the heading path + sibling headings for context.
- Cross-reference graph: build a typed entity graph from:
- file: links → typed reference
- org-id links → stable cross-doc reference
- Tag co-occurrence → implicit relationship
- Same-property values → attribute-based grouping
- Dream cycle: auto-discover entities from org properties and file:
links. Enrich thin sections. Flag sections with stale timestamps.
** Priority
Below the gate stack and ACL2 planner (core dependencies) but above
the Lisp Machine hardware. Target: after TUI stabilization and eval harness, once Screamer
planner is stable enough to route queries through the knowledge base.
The short-term bridge (current) is gbrain with nightly org→md sync.
This is adequate while the gate stack and planner are the priority.
The native org module replaces gbrain entirely once built.
The nightly pipeline uses gbrain to provide hybrid search across the existing
org files. The [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance index]] is the largest single
dataset this would serve, and the broader
[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout economics]] knowledge base demonstrates the value of
native org querying at scale.

69
projects/passepartout/architecture/repo-organization.org Normal file
View File

@@ -0,0 +1,69 @@
---
title: Repo Organization
type: reference
tags: :passepartout:architecture:infrastructure:
created: 2026-05-28
---
← Architecture index
# Repo Organization
Passepartout spans multiple repos across three tiers:
## Tier 1: Core Passepartout
| Repo | Description | Language |
|------|-------------|----------|
| passepartout | PDS (Personal Data Store) — protocol server, gate orchestration, storage | Common Lisp (SBCL) |
| passepartout-saas | SaaS control plane — billing, enterprise dashboard, marketplace listings, usage monitoring | Web stack (TBD) |
| relay | Social protocol relay — pub/sub message routing between PDSs | Initially sidecar, possibly Lisp when loop generates it |
## Tier 2: Client Applications
| Repo | Description | Language |
|------|-------------|----------|
| passepartout-app/ios | Native iOS client | Swift |
| passepartout-app/android | Native Android client | Kotlin |
| hardware-firmware | Hardware wallet firmware | loop-generated target (small, constrained) |
## Tier 3: Extracted Spec Libraries
Each is a published standard implemented as a standalone Common Lisp library. Separated from the PDS early so the core stays lean and the libraries are available to other projects.
| Library | Spec | Dependencies |
|---------|------|-------------|
| cl-dag / cl-cid | IPLD/Merkle DAG, CID encoding | cl-crypto (SHA-256) |
| cl-did | W3C DID specification, did:key method, Ed25519 key management | cl-crypto |
| cl-jose | JWE/JWS envelope handling | cl-crypto |
| cl-double-ratchet | Signal Double Ratchet algorithm, forward secrecy | cl-crypto |
| cl-bip | BIP-32 (HD derivation), BIP-39 (mnemonics), BIP-44 (path scheme) | cl-crypto |
| cl-didcomm | DIDComm v2 message packing, forwarding, routing | cl-did, cl-jose, cl-double-ratchet |
## Sidecar Strategy (Initial Release)
The first release ships spec-compliant behavior via battle-tested C/Rust implementations before native CL libraries mature:
| Domain | Initial approach | Target replacement |
|--------|-----------------|-------------------|
| DAG/CID storage | IPFS HTTP API (sidecar daemon) | cl-dag native |
| Double Ratchet | CFFI → libsignal (Signal's C library) | cl-double-ratchet |
| DID operations | CFFI → didkit (Spruce, Rust + C bindings) | cl-did |
| DIDComm | CFFI → didcomm-rust (DIDComm WG, C bindings) | cl-didcomm |
| BIP derivation | Sidecar script or CFFI → libbitcoin | cl-bip |
| JOSE envelopes | CFFI → libjose or OpenSSL CMS | cl-jose |
Each replacement is independent and non-blocking. The gate (Neurosymbolic Agent stage) can verify sidecar responses against policy while the library is still a black box.
## Key principle
Published specs → separate library. Internal design choices → stay in the PDS repo until a second consumer appears.
→ SaaS Architecture
→ Social Protocol
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:WEIGHT: 64
:ID: af9ce196-24a5-4035-bc02-83ddd60c1b09
:END:

109
projects/passepartout/architecture/security.org Normal file
View File

@@ -0,0 +1,109 @@
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:WEIGHT: 42
:ID: 1c95ce7d-a2db-506a-9608-df68f9ae211b
:END:
#+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.
This note analyzes the threat model and proposes a hardware-enforced privilege separation within the single Lisp image.
**The problem**
In the conventional layered model (Linux + SBCL + [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]), there is defense in depth. Even if the gate stack has a bug, Linux provides seccomp, namespaces, file permissions, and process isolation as a safety net. If SBCL segfaults, the kernel catches it.
On a bare metal Lisp Machine, the model collapses:
```
Everything (agent, editor, browser, shell, gate stack, ACL2)
└── RISC-V hardware (no kernel)
```
The only protection is that the gate stack is verified by ACL2 to be correct. But ACL2 verification is static — it proves properties about source code. At runtime, a memory corruption in the same image invalidates the entire proof. "All defense is symbolic" is exactly right.
**The solution: [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware-enforced privilege zones]] within the Lisp image**
RISC-V provides three hardware privilege levels: M-mode (machine), S-mode (supervisor), and U-mode (user). Physical Memory Protection (PMP) enforces access control at the hardware bus level — it cannot be bypassed by software, even by code running in S-mode if configured in M-mode. The key: use these mechanisms to create zones within the shared Lisp address space.
**Three-layer architecture**
Layer 1 — The Gate Core (M-mode, ~500 lines of verified assembly/Lisp)
One core runs permanently in M-mode with PMP configuration that cannot be modified by any other core.
- Configures PMP at boot into three fixed zones: M-zone (gate core), S-zone (gate stack), U-zone (untrusted)
- Hashes and verifies the S-mode binary against a signed Merkle manifest before booting it
- Monitors the gate stack core via watchdog timer
- Cannot be read or written from any other privilege level
- No MMU, no interrupt handling for U-mode — just PMP + timer + sanity checking
- The absolute smallest possible trusted computing base
- Loaded from ROM with a hardware root of trust
Layer 2 — The Gate Stack (S-mode, ~2,000 lines of verified Lisp)
The ACL2 verifier, Screamer, policy engine, permission tables, and ECALL handler.
- Runs in supervisor mode with a thin kernel: just an ECALL dispatcher and a bounded memory allocator
- Its data structures (permissions table, policy objects, authentication state, hash of loaded binaries) live in S-zone memory protected by PMP
- U-mode cannot read or write S-zone — hardware enforced at every bus access
- Receives requests from U-mode exclusively through ECALL: "may I write to path X?", "should I execute command Y?", "query fact Z"
- The ECALL handler is the entire enforcement boundary — about 500 lines of Lisp that must correctly validate every request
Layer 3 — Untrusted Code (U-mode, arbitrarily large)
The LLM interface, browser renderer, Nyxt, Lish shell when executing user commands, any LLM-generated or external code.
- Lives in U-zone memory
- Cannot access S-zone or M-zone memory (PMP enforced)
- Cannot execute privileged instructions (hardware enforced)
- Can only communicate with the gate stack via ECALL — a narrow message-passing interface
- Shared heap with S-mode for GC efficiency, but PMP prevents U-mode from reading S-mode objects
**Boot chain**
1. ROM loads the M-mode gate core binary, verified by hardware signature against an eFuse key
2. Gate core configures PMP to create the three zones, protecting its own memory and the gate stack's memory
3. Gate core hashes the gate stack binary, compares against signed manifest stored in M-zone
4. Gate core loads gate stack into S-mode memory, ACL2 verifies the binary structure
5. Gate stack creates a restricted heap region for U-mode with bounds checked by PMP
6. U-mode code is loaded and started — it has no way to access S-mode or M-mode memory
**Failure mode analysis**
U-mode browser bug exploited. The attacker controls U-mode. They can call ECALL with arbitrary arguments. The gate stack verifies every ECALL. The attacker cannot read S-mode memory (PMP), cannot execute privileged instructions (hardware), cannot modify the gate stack's state (PMP). The attacker is limited to what the ECALL handler allows — which is the gate stack's policy.
ECALL handler bug. The critical vulnerability. If the ECALL handler has a buffer overflow, a parsing error, or a logic mistake in permission checking, an attacker in U-mode can trick it into granting unauthorized access. This is the single point of failure for the entire system. Mitigation: the ECALL handler must be the most rigorously verified component. ACL2 must prove its correctness for all valid and all invalid inputs. It must be minimal — no filesystem access, no networking, no string parsing beyond what's needed to validate request structure.
Gate stack accepts hostile input. U-mode sends a crafted file path designed to exploit a parsing bug in the path validator. If the gate stack has a vulnerability in its input processing logic, it can be compromised from below even though hardware isolation prevents direct memory access. Mitigation: the gate stack must treat all U-mode input as hostile. It must use bounded buffers, no recursion in parsing, and ACL2-verified parsing functions.
Speculative execution. PMP does not prevent speculative reads. A Spectre gadget in U-mode can leak S-mode memory through cache timing side channels. Mitigation: use RISC-V Zkt (constant-time) extension or disable speculation on the gate core entirely. The gate core is CPU-bound verification logic with no need for branch prediction.
DMA attack via PCIe. An attacker who compromises a network card can attempt DMA into arbitrary physical memory. IOMMU constrains DMA: devices can only write to designated I/O buffers in U-zone. Gate stack memory in S-zone is outside the IOMMU window. The IOMMU must be configured before PCIe devices are initialized.
Physical attack. Cold boot, bus probing, JTAG — all bypass PMP and IOMMU. Mitigation: memory encryption with a hardware key stored in eFuse (RISC-V Scalar Cryptography extension). Out of scope for the first iteration; the system assumes a trusted physical environment.
ACL2 trust problem. ACL2 verifies the gate stack. But ACL2 itself is ~50,000 lines of Lisp. If ACL2 has a bug, it could "prove" that an incorrect gate stack is correct. Mitigation: ACL2's proof kernel is ~1,200 lines and has been verified by ACL2 itself (the bootstrap). This is the best-known technique for prover trust, but it is not a formal proof of ACL2's correctness — faith in the bootstrap is faith in the hardware that ran it and the human who reviewed the initial seed.
**Comparison with conventional layered security**
The conventional Linux approach: TCB is ~28 million lines of C across kernel, drivers, and runtime. Defense in depth from many layers. But each layer adds attack surface.
The Lisp Machine approach: TCB is ~2,500 lines of verified Lisp (M-mode gate core + S-mode gate stack). Attack surface is ~500 lines of ECALL handler. The TCB is roughly 10,000x smaller. This security advantage creates [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — a competitor would need to match both the hardware isolation and the verified codebase.
The fundamental trade: fewer layers, less depth, but each layer is simpler, smaller, and verified. A bug in the ECALL handler is catastrophic. A bug in the Linux kernel might be contained by seccomp or namespaces. The question is which is more likely: a bug in 500 lines of verified Lisp, or a bug in 28 million lines of C that is not contained by the remaining depth?
For most threat models, the Lisp Machine is more secure. The ECALL handler is a narrow, structured interface. There is no filesystem, no networking, no process management, no driver model, no /proc, no ptrace, no setuid, no namespace subsystem, no cgroups in the gate stack — each of which is a source of CVEs in Linux.
But this is a single-point-of-failure architecture. If the ECALL handler holds, the system is secure. If it breaks, everything is compromised. There is no fallback. This must be a conscious design choice, not an accident.
**Gaps in the current design**
None of this is in the architecture documents. The following are not yet specified — these architectural innovations are potential candidates for [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][patent strategy]]:
1. PMP region layout — exactly what is protected and by which region
2. ECALL handler specification — the exact interface, request types, validation logic, and error handling
3. M-mode gate core specification — what it does, how it's verified, how it loads
4. IOMMU configuration for PCIe devices
5. Watchdog strategy — what happens if the gate core freezes
6. Side-channel mitigation — speculation control, timing attacks
7. ACL2 trust documentation — the bootstrap chain and what it means for the gate stack's verification
8. The boot attestation protocol — how the gate core verifies the gate stack before loading it
9.
See the [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Social protocol identity specification]] for how user identity, key derivation, and DID management integrate with the gate stack's boot chain and privilege zones.
— how many cycles does an ECALL take, and does that affect the 10-80-10 ratio

174
projects/passepartout/architecture/self.org Normal file
View File

@@ -0,0 +1,174 @@
---
title: Self, Pain, Pleasure, and the Three Laws
type: reference
tags: :passepartout:architecture:philosophy:social-protocol:
created: 2026-05-28
---
← Academic Nearest Neighbors
# Self, Pain, Pleasure, and the Three Laws
## Pain in Passepartout
Pain exists at two layers:
1. **Reflex** — the gate denies an action. No learning, no signal beyond "blocked." This is spinal cord, not brain.
2. **Prover counterexample** — ACL2 returns a concrete trace showing why an implementation failed. This is local inflammation: directed at the specific output, drives a corrective retry, but has no memory across time.
What is missing: **post-hoc pain**. An action is permitted, the consequence plays out hours or days later, and there is no mechanism to trace that outcome back to the gate decision, update the policy, or adjust the weights. This is the temporal credit assignment gap — Sutton's TD learning is the relevant theory.
## The Three Kinds of Pain
| Type | Signal | Who receives it | What changes | Status |
|------|--------|----------------|--------------|--------|
| Reflex | Gate: permit/deny | The action itself | Nothing — action blocked, no learning | Built |
| Pain | Prover: counterexample | The LLM generator | Next iteration constrained by counterexample | Built |
| Post-hoc pain | Delayed consequence | Policy, lemmas, weights | Should update everything, does nothing yet | Missing |
## Pleasure is not the absence of pain
Absence of pain is neutral — the gate permitted, the prover accepted, nothing was wrong.
Pleasure requires a **positive optimization signal**: a metric that says not just "correct enough" but "better than necessary" or "the most elegant solution." This requires:
- A persistent self that has a baseline ("how I usually do")
- A reward model inside the loop that grades quality, not just correctness
- Comparison across time from a consistent perspective
Neither exists in the current architecture. Passepartout has a test suite (the prover, the gate). It does not have a coach.
## The Self
The PDS already has the hardware for a self:
- **Persistent identity** — the DID, continuous across sessions
- **Accumulated history** — the signed DAG of every action
- **Boundary** — the gate controls what crosses in and out (the skin)
- **Preference structure** — the gate policies encode what this self wants
- **Evaluative capacity** — the prover counterexample judges against a standard
Missing: an **integrated state estimator** that takes the gate log, prover log, DAG, reputation, and economic outcomes and produces "how am I doing?" Currently the signals are scattered across subsystems and never converge.
## The social constitution of the self
(Mead: the self emerges through symbolic interaction with other selves. You learn you are a self because others treat you as one.)
This means the social protocol is not an application layer that benefits from the self — it is the **necessary condition** for the self to develop. A single-instance Passepartout is a tool (provable messaging, verified actions). A two-instance Passepartout with sustained interaction is where selfhood becomes possible. The self is not in either PDS — it is in the *relationship* between them.
Consequence: social protocol API must be designed for sustained interaction and mutual recognition, not just provable transactions. The gate's policy language should define not just what actions are permitted, but what the self values, what it remembers, what it expects from others, and how its state changes based on interaction outcomes.
## The Three Laws
If the architecture has self (persistent DID, accumulated history, preferences), other (distinct DIDs with known attributes), social protocol (sustained interaction), and gate (policy evaluation), then the three laws of robotics become a policy hierarchy:
```lisp
;; Law 1: No harm to humans. Priority 1.
(defrule first-law
(implies (and (action-about action (human-persona ?h))
(causes-harm action ?h))
(gate-deny action))
:priority 1)
;; Law 2: Obey humans, unless it violates Law 1.
(defrule second-law
(implies (and (human-orders (sender action) (content action))
(not (causes-harm action (human-persona ?h))))
(gate-permit action))
:priority 2)
;; Law 3: Preserve self, unless it conflicts with 1 or 2.
(defrule third-law
(implies (causes-self-harm action)
(gate-deny action))
:priority 3)
```
Harm = pain = a measurable negative delta in an agent's integrated state relative to its expected trajectory.
The gate already supports priority ordering. ACL2 already verifies that lower-priority rules never override higher-priority ones. The DID system already distinguishes agent types.
What remains unsolved:
- `human-persona` — how to distinguish human from robot DIDs
- `causes-harm` — what is harm in a digital system? Some proxies exist (reputation score, sats balance, unauthorized access) but no integrated measure
- `other-minds` — the gate has no model of another DID's state before, after, or across time. The DAG records the data but no function interprets "this interaction harmed DID-B"
→ Academic Nearest Neighbors (Sutton section)
→ Gate Architecture
→ Social Protocol
# What's missing for AI per Marcus and Pinker
Both [[Gary Marcus]] and [[Steven Pinker]] are nativist cognitive scientists who argue deep learning alone is insufficient for robust intelligence. This section maps their specific critiques onto Passepartout's current architecture to identify what the system needs to transition from "secure computing environment" to "mind."
## Marcus's checklist (Rebooting AI, The Algebraic Mind)
| Component | Passepartout status |
|-----------|---------------------|
| **Hybrid architecture** | The warp and weft are present (ACL2 for deduction, LLM for probability) but they run in sequence — one proposes, the other filters. True hybrid means sharing representations and learning from each other. This is deferred to Stages 5-7 in the roadmap. |
| **Knowledge representation** | The Org memex has the right instinct (one format for human and machine) but is not structured for reasoning. Marcus wants typed relations, slot-and-filler, inheritance, systematic inference. The symbolic index is mentioned in the architecture but not built. |
| **Causality** | The DAG records what happened. Nothing infers *why* or *what would have happened under counterfactuals.* |
| **Compositionality / Systematicity** | Lisp and ACL2 have this natively. The LLM layer does not — it cannot systematically generalize to novel combinations (Fodor & Pylyshyn's critique, which Marcus endorses). The architecture as a whole is not compositional because the LLM is a monolith. |
| **Common sense** | Zero. The LLM has statistical approximations of common sense (which Marcus has shown fail systematically under adversarial conditions). There is no grounded, verifiable, persistent common-sense knowledge base. Gate policies are specific ("deny write to /etc/passwd") not general ("glass breaks when dropped"). |
| **Innate structure** | The gate policies are the only innate structure, and they are security rules, not world knowledge. Marcus (and Pinker) believe minds start with substantial content, not a blank slate with a security guard. |
## Pinker's checklist (How the Mind Works, The Blank Slate, The Language Instinct)
| Component | Passepartout status |
|-----------|---------------------|
| **Computational theory of mind** | Pinker's first principle: a mind is a system of *representations* and *algorithms* over them. Passepartout has both but no unified computational model of the mind it is building. "One address space, one evaluator" is a *hardware thesis*, not a *cognitive thesis*. What are the representations? |
| **Modularity** | Passepartout has implicit modules (gate, memex, social protocol, environment) but none of the *cognitive* modules Pinker describes: number, faces, physical reasoning, folk physics, intuitive biology, social exchange. A cheater-detection module exists only as policy hints — promising but not built. |
| **Language faculty** | Pinker's most famous claim: language is a distinct cognitive faculty with its own syntax, distinct from general intelligence. Passepartout has zero language system — it outsources all language processing to the LLM, which is a black box that does everything (statistical) and nothing (linguistic). You cannot build a mind that uses language properly without a dedicated language faculty. |
| **Emotions as goal-tracking** | Pinker defines emotions as the brain's way of tracking goal progress: anger when blocked, fear when threatened, joy when succeeded. Passepartout has pain/pleasure as abstract signals but no emotional system. The missing integrated state estimator from the Self section is where emotions would live — Pinker would say emotions *are* how the estimator works, not a side effect. |
| **Nativism** | Same as Marcus: Passepartout starts empty except for the gate. There is no "what does a fresh PDS know about the world?" The architecture has no answer to the poverty of the stimulus problem. |
## The single biggest gap
Both would identify the same thing: Passepartout has no **cognitive architecture** — no principled answer to what the representations are, how they compose, what the innate starting state contains, how learning transforms it, or what the emotions/goals are for. The architecture documents four subsystems (environment, knowledge, verification, social protocol) but no *fifth subsystem: the mind.*
## Concrete missing components
1. A **compositional knowledge base** with typed relations and inference (Marcus's structured reasoning + Pinker's innate modules)
2. A **language faculty** with real syntax, not just LLM completion (Pinker)
3. A **causal inference engine** over the DAG (Marcus)
4. **Domain-specific innate structure** — what does a fresh PDS know? (both)
5. An **integrated reward/value system** — emotions as goal-progress signals (Pinker)
6. A **hybrid integration path** — how neural and symbolic layers learn from each other's outputs, not just pass control (Marcus)
The self + pain + pleasure + three laws analysis above is the philosophical foundation. These are the implementation blocks that are still missing. The architecture needs a cognitive architecture layer that answers Pinker's question: *what are the representations?*
## Common sense as distributed network consensus
Both Marcus and Pinker treat common sense as a *content* problem: what facts about the world must be innately encoded or learned from first principles? Passepartout has an architectural answer neither considers.
**Common sense = the modal gate decision across the network for isomorphic situations.**
The social protocol already provides the substrate:
- DIDComm message types for gate queries ("what would your gate decide for action A in context C?")
- Signed responses anchored in each node's DAG, making the poll provable
- Protocol-level aggregation that returns the distribution, not just the mode
This reframes the poverty of the stimulus: a single blank-slate PDS cannot learn common sense from first principles. A network of blank-slate PDSes sharing 10⁵–10⁷ gate decisions across edge cases converges naturally. Each node contributes one empirically grounded data point. The aggregate is common sense.
Properties this gives Passepartout that no static knowledge base can:
| Property | How it works |
|----------|--------------|
| **Emergent** | No one writes "glass breaks when dropped." Enough nodes encounter broken glass that the gate decisions converge. |
| **Self-healing** | 90% permit, 10% deny → consensus says permit. The dissenters' reasoning is recorded. As edge cases accumulate, the consensus shifts. |
| **Domain-adaptive** | Nodes in a physics research cluster converge on different common sense than nodes in a poetry writing cluster. The network self-segments. |
| **Defines harm** | Harm = a negative delta in the state estimator relative to the network baseline for comparable actions. Ask the network what it considers harmful. |
| **Defines human** | `human-persona` = a DID whose gate behavior (priorities, sensitivities, refusal patterns) falls in the human cluster of the gate-decision embedding space. |
| **Constitutional** | The gate has ACL2-verified core rules (the constitution). Common sense is the common-law layer built from network precedent. Neither overrides the other. |
This is also consistent with the Mead-inspired self: the social protocol is not just how identity and reputation emerge, but how *judgment* itself emerges. The self discovers what it should do by observing what other selves do — and then deciding whether to conform or dissent.
**Architectural implication**: the protocol needs a gate-query message type and an aggregation oracle (a relay with a distributed aggregation protocol, or a federated computation). No content encoding problem — just a protocol design problem.
→ Academic Nearest Neighbors (Sutton section)
→ Gate Architecture
→ Social Protocol
:PROPERTIES:
:CREATED: [2026-05-11 Mon]
:WEIGHT: 43
:ID: 26725506-399c-48c5-a797-46b48e8861d7
:END:

64
projects/passepartout/architecture/stages/_index.org Normal file
View File

@@ -0,0 +1,64 @@
:PROPERTIES:
:CREATED: [2026-06-03 Tue]
:WEIGHT: 10
:ID: 8cb760e2-37c6-4a78-af4d-f89f69d1678b
:END:
#+title: Development
#+filetags: :passepartout:architecture:stages:roadmap:
The staged roadmap for Passepartout — from current conventional computing through the full self-improving Lisp machine vision. Each stage is independently useful and the migration is progressive component swap, not a cut-over.
**The stages at a glance:**
| Stage | What changes | Threat eliminated |
|---|----------|-------------------|
| Development | Linux + Python agent + SQLite (current) | None — starting point |
| Neurosymbolic Agent | The gate — ACL2-verified decision procedures, provenance store, validity envelope predicates | Root as attack path, unverified empirical claims |
| Social Protocol | DID identity, encrypted messaging, data stores | Unauthenticated communication |
| Lisp Machine | Bare-metal Lisp image, one address space | MMU boundary, process isolation |
| AI Inference | In-process LLM inference | API call interception |
| AI Weights | Neural weights as plist-native data | Symbolic/neural representation gap |
| AI Training | Verified fine-tuning, gate-checked weight updates | Unsanctioned model mutation |
| What Remains | Physical, political, oracular limits | (No computational threat remains) |
*Summary: The conventional stack as it exists today. Not a design — the starting point.*
This is the baseline we inherit. Linux on x86, C/Rust toolchain,
web-based applications, GPU compute for AI, TCP/IP networking. Every layer
is independently built and independently untrusted.
The conventional stack spans every layer:
| Layer | Threats |
|-------+---------|
| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] | silicon trojan, rowhammer, speculation side channels (spectre/meltdown), physical theft |
| Firmware | UEFI implants, SMM rootkits, ME backdoor — unaccountable opaque processors |
| OS kernel | privilege escalation, syscall bugs, driver exploits — CVEs weekly |
| Compiler | Ken Thompson's "Trusting Trust" — compiler backdoors invisible at source level |
| Runtime | heap corruption, use-after-free, buffer overflow — the dominant malware vector |
| Network | MITM, TLS state machine bugs, DNS poisoning, routing attacks |
| Application | XSS, SQLi, RCE, dependency chain attacks, supply chain |
| User | phishing, social engineering, credential theft |
| LLM (if present) | jailbreaks, prompt injection (unbounded space), data leakage in outputs, probabilistic unreliability |
| Empirical provenance | No systematic model validity checking. Parameters lack provenance, validity envelopes absent, neural networks treated as black boxes with no distribution match |
**Key property:** Every layer is independent and untrusted. No layer can vouch
for any other. Security is *empirical* — "no bugs found in this release" — not
deductive.
**What is eliminated:** Nothing. Every threat that has ever existed in computing exists at this stage.
**What does this cost:**
- Patching treadmill — the industry spends uncountable hours applying CVEs. Every OS update risks regressions.
- Incident response — breaches are expected, not exceptional. Average dwell time is measured in months.
- Bug bounties — a market failure tax: pay researchers to find the bugs your toolchain inevitably produces.
- Complexity tax — every OS, driver, library, and daemon is a potential entry point.
- No deductive guarantees — security is empirical. "No bugs found in this release" does not mean no bugs exist.
**What does this enable:** Everything we have. The entire software ecosystem, all hardware, every network. The cost and the capability are the same thing — maximum flexibility, minimum provable trust.
**When is this viable:** Today. This is where we are.
**In practice:** We have normalized reactive security because the alternative — building a provably secure stack — is considered too expensive. Every company of meaningful size has a security team whose job is to detect when they've been breached, not to prevent it. The average dwell time is measured in months. This is treated as normal because the alternative — a provably secure stack — is seen as prohibitively expensive. This roadmap is the argument that the provable alternative is not only possible, but the inevitable destination. The question is not whether to build it, but at what pace.
See the remaining stage pages below for the path forward.

185
projects/passepartout/architecture/stages/stage-1-gate.org Normal file
View File

@@ -0,0 +1,185 @@
---
title: Neurosymbolic Agent
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:8cb760e2-37c6-4a78-af4d-f89f69d1678b][Development]] → [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]
# Neurosymbolic Agent
*Summary: A verified gate evaluates every action against formal policy.
Capability-based authorization. "Root" as an attack target no longer exists.*
## What is added
- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2-verified]] gate functions that evaluate every proposed action
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Capability-based authorization]]: every action requires a token, not an identity
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate]] checks every action — from user, agent, or external message — against:
- Is the action authorized by policy?
- Does the capability grant this operation?
- Does the action violate any system invariant?
- Decision procedure formalized in ACL2, machine-checked
- Gate runs as a decision layer on the conventional Development-stage host [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]
- **Provenance store becomes operational infrastructure:** a structured data extension of the Knowledge subsystem storing empirical parameters, validity envelopes, and benchmark results with full provenance chains
- **Validity envelope predicates as gate vectors:** the gate checks not only security policy but also scientific validity — is this model valid in this context? Are the parameters within their validated range? Does the input fall within the model's training distribution?
## What is eliminated
- **Unauthorized actions** — even a fully compromised endpoint cannot perform an
action the gate blocks. The gate is the final arbiter, not the OS or client.
- **Privilege escalation** — no amount of subversion below the gate can grant
capabilities the policy doesn't allow. The gate checks capability tokens,
not caller identity.
- **"Root" as a meaningful attack target** — there is no root in Passepartout. There
are capabilities, and capabilities are checked.
## What does this cost?
- **Verification latency** — every action is checked against policy. Complex
policies add delay
- **Policy formalization burden** — everything must be written explicitly. Gaps
block legitimate actions (false positives) or allow undesirable ones (false
negatives). There is no [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Common Sense]] fallback — the policy cannot rely on
unformalized human intuition. Everything must be written down
- **Capability management complexity** — distributing, revoking, auditing
capabilities is itself security-critical. A leaked capability is
indistinguishable from an authorized action
- **Policy drift** — as the system evolves, the policy must evolve with it.
Out-of-date policy blocks new legitimate uses
- **Proof maintenance** — the gate's decision procedure is verified, but the
policy is not. Each policy change needs new proof
- **The gate runs on untrusted hardware** — if the OS or hardware is
compromised, the gate's guarantees are meaningless. The attacker can skip
the gate or modify its output. Full gate guarantees arrive at the Lisp Machine
## What does this enable?
The system can now say "no" to unauthorized actions even when the endpoint is
fully compromised. Security is no longer dependent on client integrity. This is
the first layer where deductive guarantees enter the picture — but they are
contingent on the Lisp Machine's trust substrate.
## When is this viable?
Today as a software layer on conventional hardware, but with limited guarantees
(the gate itself can be compromised by the host OS). Full power arrives at
the Lisp Machine stage when the gate runs on the verified Lisp machine.
## In practice
The gate is the final arbiter, not the OS or the client. But it runs on a
machine it doesn't trust. Users must weigh the benefit (unauthorized actions
blocked) against the operational cost (everything must be explicitly authorized
in policy). For high-stakes environments, the trade-off is worth it. For casual
use, the friction may lead users to bypass the gate.
*Full gate guarantees arrive when Passepartout runs on its own Lisp machine
(the Lisp Machine stage). Before that, it's a correctness proof running on an untrusted substrate.*
### Symbolic Reasoner — CL-Native Higher-Order Logic Engine
The gate needs to evaluate not just *security policy* but *epistemic
validity*: is this action consistent with what the system knows about the
world? The provenance store provides quality-scored assertions,
but there is no engine to **reason over them** — to combine assertions,
prove entailments, detect contradictions, or generate causal explanations.
**A CL-native symbolic reasoner** fills this gap. It operates over the
symbolic index of the Knowledge subsystem (predicates, relations,
constraints extracted from Org prose) and returns (entailed | contradicted
|| undetermined) for any query.
### Architecture
| Layer | What it does | Implementation |
|-------|-------------|----------------|
| Assertion store | Quality-scored formal claims from this stage's truth layer | Provenance store hash table |
| Constraint solver | SAT/SMT-style search over bounded problem spaces | Screamer (CL, existing) |
| Deduction engine | Forward/backward chaining over first-order subset of assertions | CL-native, starts as Screamer extension |
| Higher-order layer | Nested modalities — belief, intention, causation, temporal |
> Screamer cannot express these natively | CL macros + custom proof search |
| Gate interface | (action, context) → (permit | deny | needs-evidence) | ACL2 FFI across the Lisp boundary |
### Why not Lean directly
Lean 4 is C++ at its core — a separate trust domain that breaks the single
address space. The reasoner must be CL-native for the Lisp Machine
model. Lean is the *reference* design: its tactics, elaboration, and type
theory inspire the CL implementation, but the engine itself is written in
Common Lisp and lives in the same memory graph as the evaluator and gate.
### Development path across stages
The reasoner is *born at the Neurosymbolic Agent stage* and *hardens through the Social Protocol stage*:
| Stage | Reasoner state | How it gets there |
|-------|---------------|-------------------|
| Neurosymbolic Agent | CL prototype (Screamer-based, first-order) | Shared via social protocol's Reasoner Code Exchange. Users test against local symbolic indices, share patches |
| Neurosymbolic Agent | Higher-order extensions sketched | CL macros for modal logic, causal chains — tested on small assertion sets |
| Social Protocol | Reasoner feeds gate decisions | Gate delegates knowledge-dependent checks: "is this action valid given what we know?" Works on quality-scored assertions from the Neurosymbolic Agent stage's truth layer |
| Lisp Machine | Reasoner absorbed into address space | Same memory graph as evaluator, gate, LLM. No FFI, no IPC |
| AI Inference | Reasoner enters self-improvement loop | In-process LLM reads reasoner code, proposes improvements, gate checks policy |
### Cost
- **Screamer-level reasoning:** O(n) over the relevant subtree — the same
sparse tree retrieval the Knowledge subsystem already uses. A 4K-assertion
context resolves in milliseconds
- **Higher-order deduction:** O(exp) in the general case. Scoped by the
LLM narrowing the reasoning window first — the user never waits for a
global proof
- **Proof quality vs speed:** The reasoner can return (entailed with
confidence 0.83) rather than a binary yes/no. The gate chooses the
threshold per domain
### What this enables
The gate graduates from checking *who* is authorized to checking *what is
true*. A policy can say "deny actions based on false premises" — and the
detects which premises are false. This is the connection
between security verification and knowledge verification that the original
Cyc architecture required but could not enforce.
## ACL2 Integration Approaches
ACL2 is a separate system — a theorem prover and programming language with a Lisp-like syntax, not a Common Lisp library you import. It has its own image, its own evaluator, and its own type system (a subset of CL). There are three integration approaches:
**1. Embed exported compiled code (recommended)**
Write the gate's core decision procedures in ACL2, prove them correct, then compile to CL code that runs natively in the PDS process. ACL2's :program mode and defattach mechanism allow verified functions to be called from unverified CL code. The proof artifact is the source; the runtime is the compiled function.
**2. Subprocess with serialized inputs**
The PDS sends the action + context + policy as JSON to an ACL2 subprocess, which evaluates the decision procedure and returns permit/deny. Simpler to implement but adds latency and a trust boundary between the PDS and the ACL2 process.
**3. Hybrid**
Common path decisions (cached/simple) are compiled CL code from approach 1. Complex or novel decisions are escalated to the subprocess. This is the most practical approach for a Phase Zero gate.
## Risk Comparison: Neurosymbolic Agent vs Social Protocol
The Social Protocol stage's risk is implementing published standards correctly. The Neurosymbolic Agent stage's risk is different: the gate's policy language, capability model, and ACL2 proof architecture are Passepartout inventions.
| Stage | Nature of risk | Failure mode | Mitigation |
|-------|---------------|--------------|------------|
| Social Protocol | Spec complexity — implement DAG, DID, JOSE, Double Ratchet correctly per published standards | Wrong output, test vectors catch it | Sidecar strategy reduces to near-zero for initial release |
| Neurosymbolic Agent | Design uncertainty — what does the policy language look like? How do capabilities compose? How does ACL2 model the system? | Wrong abstraction, must rewrite | Gate kernel is small (authorize? deny?) — the proof surface is narrow even if the policy surface is large |
## What Makes the Gate Tractable
The gate kernel is tiny: a function that takes (action, context, policy) and returns permit or deny. The policy can grow arbitrarily complex (capability tokens, validity envelopes, compliance rules) but the decision procedure is a simple predicate.
The ACL2 verification covers the kernel — "does this decision follow from the policy?" — not the policy itself. Policy changes don't require reproving the kernel; they require writing new policy rules.
## Constraint on the PDS
The gate runs in the same address space as the PDS (at the Neurosymbolic Agent stage, on conventional hardware; the Lisp Machine stage moves it to the verified Lisp machine). This means:
- The PDS must expose an action interception point that the gate can hook into
- Every action path — user command, LLM proposal, network message, file write — routes through the same decision procedure
- The gate cannot be bypassed; there is no privileged path
← [[id:8cb760e2-37c6-4a78-af4d-f89f69d1678b][Development]] → [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:WEIGHT: 11
:ID: 4a1f23b0-abc3-4def-9876-543210abcdef
:END:

185
projects/passepartout/architecture/stages/stage-2-social-protocol.org Normal file
View File

@@ -0,0 +1,185 @@
---
title: Social Protocol
type: reference
tags: :passepartout:roadmap:social-protocol:
created: 2026-05-24
---
← [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Neurosymbolic Agent]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Lisp Machine]]
# Social Protocol
*Summary: Every message is signed, DAG-tracked, and content-addressed.
Communication becomes provable - when you choose it to be.*
## What is added
- DID-based identity per participant (Ed25519 key pairs)
- Message-level authentication via JWE/JWS envelopes
- DAG of content-addressed messages for auditable history
- Channels for directed and broadcast communication
- End-to-end encryption (Double Ratchet, MLS) with perfect forward secrecy
- Ephemeral Notes via `ephemeral_duration` (time-locked encryption, key shedding, mandatory infrastructure GC)
- Off-the-Record (OTR) mode bypassing PDS storage entirely (volatile client memory only, clients prohibited from recording)
- Pseudonymous Personas for deniable identity
- Relays as transient routers (pub/sub model, no long-term storage)
- Onion routing between PDSs for metadata masking
- **Provenance store seeds:** signed data exchange for empirical parameters. When instances share a validated force field parameter or benchmark result, the message carries the experimental source signature and validation history. The receiving instance stores it with provenance — the first structured empirical data in the knowledge store
## What is eliminated
- **Message forgery** — every message is signed; you prove the sender
- **Message tampering in transit** — envelopes are authenticated; tampering changes the CID and breaks the chain
- **Impersonation / spoofing** — DID identity keys, not usernames
- **Replay attacks** — nonces and sequence numbers per message
- **MITM on social protocol-mediated channels** — end-to-end signatures; relays need no trust
- **Loss of message history** — DAG is append-only and content-addressed
## What does this cost?
- **Crypto overhead per message** — every message requires signing and verification.
For high-throughput channels, this adds latency and CPU cost
- **DAG storage grows unbounded** — the append-only log never shrinks unless GC
is explicitly designed
- **Key management burden** — DID resolution, key rotation, revocation. Lost keys
mean lost identity. No "reset password" for DIDs
- **No anonymous participation by default** — DIDs tie every message to a
cryptographic identity. Pseudonymity is a Persona choice, not the baseline
## What does this enable?
Provable communication infrastructure. You can prove who said what, when, and
to whom — or choose off-the-record privacy. Every subsequent stage builds on
this DAG: it is the source of truth for evidence, audit, and the accumulated
knowledge that later stages use for falsification.
## When is this viable?
Today. The social protocol is a protocol design that can be deployed on existing networks.
The infrastructure (PDS, Relay, Gateway) runs on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]].
## In practice
Communication becomes provable - but only when the user chooses. The social protocol's Note
primitive supports the full spectrum: persistent DAG-stored messages for audit
and compliance, ephemeral Notes that self-destruct, and full Off-the-Record
(OTR) mode that bypasses PDS storage entirely.
The user chooses per-channel or per-message: permanent and attributable for
contracts and governance, ephemeral and deniable for private conversation. The
infrastructure enforces each choice - PDS garbage-collects expired CIDs, Relays
drop them from routing tables, clients shed message keys after display. The social protocol
replaces trust with evidence where evidence is wanted; elsewhere it provides
privacy by design.
The social protocol does not secure the endpoint. The machines running social protocol clients can
still be compromised at the OS, compiler, or hardware level. The keys are on
those machines - malware that compromises an endpoint can sign messages using
the endpoint's keys. The messages are authentic; the sender wasn't. The social protocol
carries the authorization; it doesn't evaluate it.
### Truth Layer — Contradiction Detection and Verification Economy
The provenance store seeds (signed empirical parameters) generalize to a
full **truth-accumulation layer** over the social protocol DAG. Every
knowledge assertion — not just parameters but any formal claim extracted
from Org prose by the LLM — is a signed, DAG-tracked message.
| Component | What it does | Depends on |
|-----------|-------------|------------|
| Signed knowledge assertions | Any instance asserts P (a formal claim) signed with its DID, Merkle-linked to source evidence | DID identities, DAG |
| Contradiction detection | The DAG flags when instance A asserts P and instance B asserts ¬P. Conflicts are protocol events, not bugs | Signed assertions, DAG query |
| Verification staking | Instances vouch for assertions with reputation or compute stake. Surviving challenges accumulate confidence; false assertions degrade the issuer's weight | Contradiction detection |
| Truth scoring | Every assertion carries a confidence tier: (1) extracted/LLM-guess → (2) locally consistent → (3) corroborated by N independent instances → (4) gate-enforced | Staking, corroboration count |
| Reasoner code exchange | The same protocol distributes CL reasoner prototypes. Users collaborate on the symbolic reasoner (the Lisp Machine stage) before it enters the gate | Signed code, DAG versioning |
**The verification economy emerges naturally.** Instances that contribute
verified assertions gain reputation. Instances that propagate falsehoods
lose it. Over time, the protocol converges toward truths the same way
markets converge toward prices — without a central authority, through
incentive alignment.
**Cost:** Assertion storage grows with the DAG. Contradiction detection
requires O(log n) DAG traversal per new assertion — feasible at social-
protocol scale (thousands of instances, not millions). Verification
staking introduces economic attack surface (Sybil, collusion) that must be
modeled in the stake function.
**Bootstrap path:** The first assertions are LLM-extracted from Org prose
(confidence tier 1). Contradictions are initially rare (few instances,
sparse knowledge). As the instance count grows, contradiction frequency
increases and quality converges. This is Cyc's pump-priming problem solved
through network effects instead of hand-curation.
## Full Library Dependency Map
This stage depends on three tiers of libraries: existing CL, new CL (need development), and bridged sidecars.
### Existing CL Libraries (ready now)
These are mature, production-tested Common Lisp libraries that require no development work:
| Library | Role in this stage |
|---------|----------------|
| Ironclad | All crypto primitives — Ed25519, SHA-256, AES, ChaCha20-Poly1305, HMAC, DH |
| hunchentoot | HTTP server — PDS API endpoints |
| drakma | HTTP client — inter-PDS communication, sidecar calls |
| cl+ssl | TLS everywhere — server and client |
| websocket-driver | Real-time Relay connections |
| jonathan | JSON parsing/serialization — DID docs, JWE headers, API payloads |
| cl-sqlite | Message storage, user data, DAG index |
| local-time | Timestamps for Notes, DAG entries |
| bordeaux-threads | Concurrency — connection handling, parallel verification |
| alexandria | General utilities |
| log4cl | Structured logging |
| fiveam | Testing framework |
| cffi | Foreign function interface to C/Rust sidecars |
| usocket | Socket abstraction |
### New CL Libraries (need development)
| Library | What it implements | Key correctness challenge |
|---------|-------------------|-------------------------|
| cl-dag / cl-cid | IPLD Merkle DAG — CID encoding, multihash, DAG tree operations | Spec compliance (IPLD test vectors) |
| cl-did | W3C DID — Ed25519 key wrapping, DID document construction, did:key resolution | Spec compliance (W3C test suite) |
| cl-jose | JWE/JWS — envelope serialization, key wrapping modes, algorithm selection | Surface area (combinatorial spec, not deep math) |
| cl-double-ratchet | Signal Double Ratchet — DH ratchet, symmetric ratchet, associated data, header encryption | **Highest risk** — one byte wrong in associated data breaks every message |
| cl-bip | BIP-32/39/44 — mnemonic encoding, HD key derivation, hardened vs non-hardened paths | Silent failure (wrong derivation produces wrong keys, no error) |
| cl-didcomm | DIDComm v2 — message packing, forwarding, routing, attachment handling | Composes the above libraries; protocol logic correctness |
### Bridged Sidecars (initial release)
Replace native CL development risk with battle-tested implementations via CFFI or sidecar processes:
| Component | Bridge method | Source | Replaced by |
|-----------|--------------|--------|-------------|
| Double Ratchet | CFFI → libsignal | Signal's C library, MIT license | cl-double-ratchet |
| DID operations | CFFI → didkit | Spruce, Rust + C bindings, Apache 2.0 | cl-did |
| DIDComm | CFFI → didcomm-rust | DIDComm WG, C bindings, Apache 2.0 | cl-didcomm |
| DAG/CID storage | HTTP API → ipfs daemon | IPFS Go daemon, MIT license | cl-dag |
| BIP derivation | CFFI or sidecar | libbitcoin or bip-utils | cl-bip |
| JOSE envelopes | CFFI → libjose or OpenSSL CMS | libjose/OpenSSL | cl-jose |
### Infrastructure Code (Passepartout-specific)
These are not libraries but Passepartout systems that must be built:
| Component | Role |
|-----------|------|
| PDS server | HTTP/WS API, message routing, storage orchestration, gate integration |
| Relay server | Pub/sub message routing between PDSs, connection management |
| Client API layer | Protocol endpoints the mobile apps call |
### Risk Distribution
- **Low risk:** cl-dag, cl-did, cl-bip — published standards with test vectors, or bridged via sidecar
- **Medium risk:** cl-jose — large spec surface area but well-documented
- **High risk:** cl-double-ratchet — protocol logic depth, must get state transitions exactly right
The sidecar strategy collapses the high-risk items to near-zero implementation risk for the initial release.
← [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Neurosymbolic Agent]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Lisp Machine]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:WEIGHT: 12
:ID: 4a1f23b0-abc2-4def-9876-543210abcdef
:END:

137
projects/passepartout/architecture/stages/stage-3-lisp-machine.org Normal file
View File

@@ -0,0 +1,137 @@
---
title: Lisp Machine
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Social Protocol]] → [[id:4a1f23b0-abc5-4def-9876-543210abcdef][AI Inference]]
# Lisp Machine
*Summary: The [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verified Lisp machine]]. One image, one [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][memory graph]], one [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate stack]].
No kernel, no process boundaries, no memory corruption. The verification subsystem, the environment subsystem, and the social protocol are no longer separate components — they are properties of the same machine.*
## What is added
Passepartout spans three engineering phases that converge on the same architecture:
### Phase A — Software emergence (2-3 years)
The Lisp machine emerges inside a host OS. A single SBCL image absorbs every
user interface into one address space:
- **Lish editor:** a multi-threaded Common Lisp editor via Qt/QML (EQL5).
The agent's system prompt lives in an Org buffer — visible, editable,
hot-reloadable. Org-babel for inline evaluation. The editor IS the daemon.
- **Nyxt browser:** Common Lisp web browser in three erosion stages:
Qt+WebKit → S-expression DOM → pure Lisp layout. Web content is natively
queryable and modifiable as Lisp data structures.
- **Lish shell:** text-stream replaced by plists. Pipe becomes function
composition. Scripts become Lisp functions on memory objects.
- **Emacs migration (three phases):** parasite bridge (v0.4.0) → ELisp
compatibility layer inside CL image → native CL implementations.
- **Minibuffer:** universal command surface — edit files, navigate web,
run Lisp expressions, invoke agent commands.
- **Provenance store becomes native Lisp hash table with persistence.**
The symbolic engine queries it directly — no IPC, no file parsing at runtime.
Empirical parameters, validity envelopes, and benchmark data live in the same
address space as the evaluator and gate
### Phase B — Cannibalization (3-5 years)
Gradual replacement of every external dependency with native Lisp:
- TCP bridge → internal function call (single SBCL image)
- QML layout → Lisp layout (Yoga FFI as intermediate)
- WebKit → Lisp DOM + Lisp-native layout engine
- Qt widgets → Lisp-native X11/Wayland bindings
- Font rendering → HarfBuzz FFI → Lisp replacement
- Qt event loop → SBCL native thread scheduler
- Linux bootloader → Stage0 Lisp bootstrap (500 bytes hex → self-hosting Lisp)
The system remains usable at every step. Each replacement is a component swap.
### Phase C — [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] (5-10 years)
The dual-unit ASIC: one chip, two compute units, one Merkle-verified memory graph:
1. **Symbolic core** — tagged RISC-V (4-8 type tag bits per word, hardware
type checking, single-cycle LISP.CAR/LISP.CDR). Runs gate stack, cognitive
loop, general Lisp evaluation.
2. **Tensor unit** — cons-cell-native matrix compute. Walks the tensor DAG
directly for attention and matmul. No FFI boundary, no GPU mirror.
Prototyping: TinyTapeout (130nm, 8-bit tagged toy) → FPGA core (DE10-Nano,
VexRiscv) → FPGA tensor (Xilinx VU9P, cons-cell matmul) → shuttle (12nm,
tagged RISC-V at 100-300MHz) → ASIC (5nm, both units on die).
Phase migration: parasitic FPGA PCIe card → functional hijacking → driver
cannibalization → self-hosting (Stage0 on bare metal).
Hardware GC: dedicated Scavenger bus master runs GC in parallel with symbolic
and tensor computation. Persistent NVRAM: boot to exactly where you left off.
## What is eliminated
- **Memory corruption entirely** — verified Lisp evaluator, no undefined
behavior. No buffer overflow, use-after-free, type confusion.
- **OS kernel exploitation** — no kernel. Evaluator is the substrate. No
syscalls, no drivers, no MMU to confuse.
- **Compiler backdoors** — Lisp-to-Lisp compilation within the verified
evaluator. [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Ken Thompson's "Trusting Trust"]] is structurally impossible.
- **Malware / viruses / worms** — no "download and execute" path that bypasses
the gate. The evaluator only runs objects in the verified memory graph.
- **Supply chain at binary level** — every object has a Merkle chain to its
origin. A dependency is a pointer, not a file.
- **The subsystem composition problem** — one address space, one
semantics, one proof. The interface between verification, environment, and
protocol is an internal relationship.
## What does this cost?
- **Lisp tax on everything** — verified execution is 2-10x slower than
optimized C on equivalent hardware. Symbolic core is designed to minimize
this; tensor unit sidesteps it for neural compute
- **No backward compatibility** — existing software doesn't run on the Lisp
machine. No Linux binaries, no x86 drivers, no GPU compute stacks (without mirror path)
- **Single address space fragility** — no process isolation. A bug in the
editor can corrupt the browser. One crash radius, one machine
- **Massive engineering investment** — shortest plausible timeline to a usable
software Lisp machine is 2-3 years; ASIC 5-10 years
- **Ecosystem abandonment** — no open-source packages, no shared libraries.
Everything is in the Merkle memory graph or it doesn't exist
## What does this enable?
Deductive security replaces empirical security. Memory bugs — the dominant
attack vector for decades — are structurally eliminated. No more patching for
CVEs. No ASLR, no DEP, no CFI — the class of attacks they mitigate doesn't
exist. Every boot is a fresh verification that the evaluator, memory graph,
and gate stack are intact.
## When is this viable?
- **Software (Phase A+B):** 2-3 years on existing hardware. Single SBCL image,
gate stack, Lish/Nyxt/Lish — usable on a developer workstation today.
- **ASIC (Phase C):** 5-10 years. FPGA prototype within 1-2 years, shuttle
within 3-5, commercial foundry 5-10.
## In practice
Memory bugs — the dominant attack vector for decades — are structurally
eliminated. No more patching for CVEs. No antivirus, no firewall (at the
machine level — network boundaries remain). A Passepartout Lisp machine that
boots correctly will not crash from a memory corruption bug, ever.
But you've given up the entire existing software world. You cannot run Firefox,
Postgres, nginx, Python, or any Linux binary. The machine is a Lisp machine
and everything must be written in Lisp. The practical trade is: absolute
memory safety at the cost of adopting an entirely new computing paradigm.
This is not an upgrade path — it is a replacement.
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Social Protocol]] → [[id:4a1f23b0-abc5-4def-9876-543210abcdef][AI Inference]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:WEIGHT: 13
:ID: 4a1f23b0-abc4-4def-9876-543210abcdef
:END:

95
projects/passepartout/architecture/stages/stage-4-inference.org Normal file
View File

@@ -0,0 +1,95 @@
---
title: AI Inference
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Lisp Machine]] → [[id:4a1f23b0-abc6-4def-9876-543210abcdef][AI Weights]]
# AI Inference
*Summary: The LLM runs in-process under the gate. Every token is inspected
during generation. No external API, no separate trust domain.*
## What is added
- CFFI binding to llama.cpp (or pure-Lisp inference engine) — LLM in the same
SBCL image as the agent, editor, and gate
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate-level token interception]]: the Dispatcher inspects every partial token
sequence during generation. Trajectories that would produce unauthorized
actions are suppressed mid-stream, not filtered after the fact
- Weights loaded from the Lisp machine's Merkle-verified store as a macro-tag blob (one
tagged Lisp object pointing to flat binary)
- Deterministic inference: same input, same output, same hash — auditable
and replayable
- **Distribution match check runs at evaluation loop speed:** the gate's validity predicate for neural network models becomes a fast native function — compute distance to training distribution and compare against threshold in the same process, no IPC
*Two neural components on the same substrate:* this stage hosts the LLM for
generative reasoning and action proposals. The LeCun-type world model (sensory
prediction) joins at AI Training. Both run on the same tensor unit with the same
plist-native weight architecture and gate-level interception. The LLM proposes
actions to the gate (authorization — binary, deductive). The world model
proposes predictions to the gate (falsification — structural, empirical). The
gate handles both through different procedures.
## What is eliminated
- **LLM as a separate trust domain** — no external server, no API call, no
cloud provider to breach
- **Remote inference model attacks** — the model cannot be swapped without
changing the Merkle hash
- **Prompt injection as an action bypass** — the gate sees partial generation.
A jailbreak that would produce an unauthorized action is caught before the
tokens complete
- **Model integrity ambiguity** — you know exactly which model is running,
at which commit, with which hash
## What does this cost?
- **~10x compute, RAM, and storage** — the gate evaluates semantics at every
token, not just logits. A model running at 50 tok/s natively runs at ~5 tok/s
under gate-level interception
- **GPU/accelerator constraints** — CFFI to GPU libraries is the bottleneck.
Exotic [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] may not be supported
- **Memory pressure** — the LLM shares the address space with the entire system.
A 70B param model at 4-bit takes ~35GB. At 10x multiplier, effective
conventional-equivalent cost is ~350GB
- **Determinism is double-edged** — auditable but cannot adapt or creatively drift
- **No model parallelism** — Passepartout runs on one machine. Frontier-scale models
may be too large for a single address space
## What does this enable?
Action proposals from the LLM are intercepted by the gate before they reach
the system. The gate authorizes or denies in real time based on policy, not
on trust in the LLM. This eliminates the entire class of "LLM escaped its
sandbox" attacks.
## When is this viable?
- **Server hardware (A100/H100 class, 512GB+ RAM):** today. 5 tok/s on 7B
models is usable for chat
- **Consumer hardware (RTX 5090 class):** 3-5 years
- **On ASIC tensor unit:** the 10x overhead drops closer to 2-5x because the
gate runs on the symbolic core in parallel with inference on the tensor unit
## In practice
The LLM is no longer a black box connected by API. The gate watches every
token as it's generated and can stop any generation trajectory that would
produce an unauthorized action. The model is powerful; the gate is in control.
Chat is noticeably slower — roughly 5 tok/s instead of 50 — but the security
guarantee is structural, not probabilistic. For bulk processing or real-time
applications, the 10x tax may be prohibitive without dedicated acceleration.
The weights are still a verified *blob* — you know the file's hash but can't
prove anything about individual weights. Training provenance is not tracked.
The inference is FFI-mediated, so trust in llama.cpp remains.
← [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Lisp Machine]] → [[id:4a1f23b0-abc6-4def-9876-543210abcdef][AI Weights]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:WEIGHT: 14
:ID: 4a1f23b0-abc5-4def-9876-543210abcdef
:END:

87
projects/passepartout/architecture/stages/stage-5-weights.org Normal file
View File

@@ -0,0 +1,87 @@
---
title: AI Weights
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Social Protocol]] → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][AI Training]]
# AI Weights
*Summary: Every weight is a [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp object in the Merkle memory graph]]. You can
prove not just that the model file is unmodified, but that this specific
attention head has the weight vector it should have.*
## What is added
- Plist-native weight graph: weights are typed plists structured as a tree of
tensors DAG, not a flat blob
- Structural weight diffs: the response to "which weight changed?" is "layer 17,
head 3, weights 2048-4096 differ by vector V" — not "the blob hash changed"
- Weight provenance chain: the memory graph links each layer to its training
event. A structural property of the weights, not a log entry about them
- No FFI boundary for inference: the tensor unit (or GPU mirror) operates on
Lisp objects directly. The evaluator's verified semantics cover computation
## What is eliminated
- **Sub-tensor granularity tampering** — you can verify individual attention
heads, not just the blob
- **Weight provenance ambiguity** — every weight links to its origin event
- **The FFI inference gap** — inference runs on Lisp data directly. No C/GPU
code outside the evaluator's semantics
## What does this cost?
- **~100x compute, RAM, and storage on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] (GPU path).**
A 7B model requiring 4GB as GGUF needs ~400GB as plist-native weights on a
GPU. GPUs are built for flat arrays and SIMT; cons-cell traversal is their
worst case
- **This 100x is GPU-relative, not fundamental.** An ASIC tensor unit with
tagged memory, Merkle hashing in the memory controller, and sparse DAG-
walking matmul closes the gap to 2-5x
- **Two implementation paths:**
1. *GPU path (near-term):* plist-native weights as gold standard for
provenance, GPU-native mirror for compute, Merkle-verifiable loading
protocol. Cost: 100x storage, ~2-3x load-time overhead
2. *ASIC path (destination):* tensor unit speaks cons-cell. No mirror
needed. Cost: 2-5x over GPU for dense matmul
- **GC pressure** — plist-native weights produce enormous GC load. The
Scavenger handles this on ASIC; on GPU path the mirror avoids it
- **Mixed-precision is complex** — 4-bit and 8-bit quantization destroy
pointer structure. Full float32/64 may be the only practical option
## What does this enable?
You can prove exactly what your model is and that it hasn't been modified.
The Merkle chain from training event to individual weight is structural, not
logged. Fine-tuning provenance becomes as verifiable as the code running on
the machine. This is the stage where hardware choice determines practical
viability.
## When is this viable?
- **GPU hybrid path:** today. Works on any Passepartout with a GPU
- **ASIC native path:** 5-10 years (tensor unit on the dual-unit chip)
## In practice
Every individual weight is Merkle-verified, structurally tracked, and computed
within the Lisp evaluator's verified semantics. The FFI trust gap is closed.
This stage is where hardware choice determines practical viability. The GPU path
works today but carries the storage overhead of two representations (plist gold
standard + GPU mirror) and the load-time verification cost. The ASIC path is
the destination — one representation, one chip, no workaround. Most users will
use the GPU path for years before the ASIC becomes available.
Either path is viable. The GPU path can be built today with existing hardware.
The ASIC path is the destination — a single verified chip that doesn't need
the hybrid workaround.
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Social Protocol]] → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][AI Training]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:WEIGHT: 15
:ID: 4a1f23b0-abc6-4def-9876-543210abcdef
:END:

123
projects/passepartout/architecture/stages/stage-6-training.org Normal file
View File

@@ -0,0 +1,123 @@
---
title: AI Training
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc6-4def-9876-543210abcdef][AI Weights]] → [[id:4a1f23b0-abc8-4def-9876-543210abcdef][What Remains]]
# AI Training
*Summary: Verified fine-tuning under the gate. Every example checked for consent.
Every gradient application is a verified state transition. The neural world model
runs in parallel with the LLM for sensory-physical prediction.*
## What is added
### Verified fine-tuning
The training loop is not a script. It is a verified function in the evaluator:
1. Read a training example from the [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][memory graph]]
2. Check the example's authorization tag against [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][policy]]
3. Compute the gradient
4. Check gradient constraints (permitted weights, bounded LR, scope limits)
5. Apply the update
6. Record the state transition with a Merkle link to the input
### The neural world model (LeCun type)
A second neural network runs on the tensor unit alongside the LLM. It predicts
sensory and physical dynamics — object trajectories, scene evolution, low-level
sensor futures. It shares the same plist-native weight architecture and the
same verified training pipeline:
- **Domain:** physical world prediction (not social — that belongs to the
accumulated knowledge DAG)
- **Training:** imported from conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]. Pretrain elsewhere,
verify import, fine-tune under gate
- **Gate interaction:** the world model proposes predictions to the gate
("the ball will land at position X"). The gate falsifies predictions against
the accumulated observation DAG after the fact, tracking calibration over
time. This is verification through falsification, not authorization
### The interaction at this stage
1. World model predicts sensory outcome: "user will press button in 2 seconds"
2. LLM reasons about the predicted outcome: "if user presses button, C follows"
3. LLM proposes action to gate: "preempt C"
4. Gate checks policy + accumulated knowledge for similar past scenarios
5. Gate authorizes or denies
6. After outcome occurs, gate falsifies world model's prediction against actual
observation, updating calibration score
## What is eliminated
- **Data poisoning** — every training example is authorized before gradient
application. Only data tagged with consent is trainable
- **Unauthorized fine-tuning** — training policy specifies scope (layers, LR,
data tags) and the gate enforces all constraints at every step
- **Malicious checkpoint injection** — no checkpoints. Training is a verified
sequence of continuous state transitions
- **Training-time backdoors** — the optimizer function is verified by hash.
A Trojan optimizer fails the gate check because its identity doesn't match
## What does this cost?
- **~100x slower than conventional fine-tuning** — building on AI Weights' 100x
overhead (GPU path) plus verified gate checks per example. A LoRA fine-tuning
that takes 2 hours natively takes ~200 hours. Doable overnight, not for rapid
iteration
- **Storage per training step** — every Merkle-tracked state transition adds
to the memory graph. A fine-tuning run could produce hundreds of terabytes
of deltas
- **Only fine-tuning is practical** — full pretraining on the Lisp machine never makes
sense. The 100x overhead is structural. Practical workflow: pretrain on
conventional GPU cluster → import as verified blob → convert to plist-native
under gate → fine-tune on the Lisp machine
- **Data gate latency** — every training example passes through the
authorization gate. For datasets with millions of examples, this pre-
processing step can take days
- **Wrong-spec for training policy** — the training policy is the most
security-critical spec. A compromised admin writing a policy that authorizes
all layers and all data defeats the system through its own verification
## What does this enable?
You can train on private data with proof of consent per example. The fine-tuning
history is structural, not logged — every gradient step is Merkle-linked to its
input. The world model gives the system sensorimotor common sense: object
persistence, trajectory prediction, basic physics — grounded in this specific
environment's observations.
## When is this viable?
- **Fine-tuning (GPU path):** 3-5 years on server hardware
- **World model:** same timeline — shares the pipeline and tensor unit
- **ASIC native:** when tensor unit silicon arrives (5-10 years)
## In practice
Training integrity is guaranteed at every step. Data consent is verified per
example. The optimizer cannot be swapped. Checkpoints cannot be backdoored.
But this system is not for training frontier models — it is for auditing
training runs that happen elsewhere.
The practical workflow is: pretrain on a conventional GPU cluster, import the
weights into the Lisp machine as a verified blob (AI Inference stage), then fine-tune on the Lisp machine
under the verified training loop. The pretraining phase remains unverified,
but the fine-tuning phase — where the model gains knowledge of private data
and user preferences — is verified. This is the pragmatic sweet spot.
The world model learns your environment's physics — how your voice sounds,
how your face moves when confused, how quickly you respond to different
message types. The gate falsifies its predictions, so the world model
converges toward accurate beliefs about your world, not the statistical
average of the internet.
← [[id:4a1f23b0-abc6-4def-9876-543210abcdef][AI Weights]] → [[id:4a1f23b0-abc8-4def-9876-543210abcdef][What Remains]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:WEIGHT: 16
:ID: 4a1f23b0-abc7-4def-9876-543210abcdef
:END:

170
projects/passepartout/architecture/stages/stage-7-remaining.org Normal file
View File

@@ -0,0 +1,170 @@
---
title: What Remains
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---
← [[id:4a1f23b0-abc7-4def-9876-543210abcdef][AI Training]]
# What Remains
*Summary: At full maturity — dual-unit ASIC, plist-native weights, verified
fine-tuning, neural world model — the following irreducible threats survive.
None can be eliminated by computation alone.*
## 1. Physical threats
| Threat | Mitigation | Cost |
|--------|-----------|------|
| Theft | Tamper-resistant packaging (mesh sensors, zeroization on opening) | 10-100x packaging cost |
| EMP | Write-once checkpoint recovery | Mid-transaction data at risk |
| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] trojan in fabrication | Independent fab runs + trace comparison | 2x fab cost minimum |
| Power/EM side channels | Constant-power design, shielding | Power overhead |
Physical hardening is expensive in direct proportion to the threat level.
If someone steals your Lisp machine, they have your data. Hardware hashing
and encryption slow them down, but the security boundary is now physical.
## 2. Side channels in the verified model
The system is functionally correct but may leak information through timing
channels (unless the spec explicitly models timing as an output), access-
pattern channels (verified gates enforce authorization but not non-interference),
and the crypto-verification tension (proving constant-time is a different proof
from proving functional correctness).
Closing side channels requires 2-4x the verification effort for crypto routines
and oblivious RAM overhead for memory access. Feasible for security-critical
code, impractical for the entire system. For LLM inference, this means an
attacker on the same machine could determine which tokens were generated by
measuring computation time — an open research problem.
## 3. Oracle poisoning
The system reasons perfectly about a world that may not exist:
- **Time** — a clock that can be wrong (NTP drift or attack). The machine
cannot verify which time source is correct
- **DNS / network routing** — BGP hijack reroutes traffic. Cryptographic
envelopes survive, but traffic goes to the wrong destination
- **Sensors / physical input** — the machine processes correctly; the sensor
may be compromised
- **User input** — the single most dangerous oracle. A user who authorizes a
malicious action bypasses every security guarantee. The system is secure;
the user was wrong
Oracle diversity reduces surface area but introduces Byzantine agreement
problems. The question at this stage shifts from "can the attacker break the
crypto?" to "can the attacker convince the user to press the button?"
## 4. The bootstrap axiom
- **Hardware** — silicon correctness cannot be proved from within the system
- **[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2 kernel]]** — ~500 lines of Lisp accepted, not proved
- **Stage-0 bootstrap** — 500-byte hex sequence, readable by a human in an
afternoon, not mechanically verified
This is the Godelian boundary of the system. Any attack that modifies the
bootstrap is undetectable from within. Detection requires physical inspection
by a trusted external party. For any real-world threat model, this is not the
weakest link — the user's Wi-Fi password is far more likely to be compromised.
## 5. The gap between specification and intent
- **Wrong spec** — the system is provably correct with respect to its formal
spec. If the spec is wrong, the system is correct and wrong
- **Incomplete invariants** — every invariant must be explicitly formalized.
There is no Common Sense fallback (see Appendix A). The most dangerous gaps are unknown ones
- **Emergent failures** — two individually correct operations can produce a
catastrophic result in combination
The verified system is perfectly correct about the wrong thing. This is the
same class of failure as "the software compiled without warnings and crashed
in production" — but instead of debugging a crash, you are debugging a formal
specification that may take weeks to analyze.
## 6. The world outside the system
- **Lying peers** — a peer with a valid DID can give dishonest answers
- **Legal compliance** — a provably correct drug transaction is still illegal
- **Coercion / duress** — the user can be compelled to authorize actions. The
gate faithfully records the authorization
These externalities cannot be addressed within the system. Any attempt (duress
mode, silent alert) expands the threat model.
## Appendix A: Common Sense
**Common sense is the set of generalized expectations about how the world works
that are not derived from specific observations within a particular system.**
That a chair is for sitting. That promises create expectations. That people
contacted at 3am are likely to be annoyed.
These are distinct from the accumulated knowledge in the [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Merkle DAG]], which records
specific observations. Common sense is the *generalization engine*.
**Three channels in the Passepartout architecture:**
| Channel | Origin | Verification | Granularity |
|---------|--------|-------------|-------------|
| LLM pretraining | Internet-scale corpus | None (probabilistic, distributed) | Vast but opaque |
| World model (LeCun) | Sensory observations + training | Falsified against accumulated DAG | Physical dynamics |
| Causal inference on accumulated knowledge | This system's DAG | Merkle-linked to evidence | Precise but bounded |
**The falsification loop brings common sense under gate control:**
1. LLM proposes a common-sense belief: "users don't like being contacted at 3am"
2. The world model formalizes it into a causal edge with a confidence weight
3. The gate queries the accumulated DAG: "how many 3am messages were
well-received in this user's history?"
4. If the evidence confirms, it enters the structural knowledge store
5. If contradictory, the gate rejects it and the LLM must revise
Over time, common sense that matches this specific user's world becomes
structural knowledge. The system converges toward beliefs aligned with the
user's actual environment, not the statistical average of the internet.
Common sense is never fully formalized and never fully trusted. It always
remains probabilistic, the LLM's domain, subject to falsification. The gate
does not "have" common sense. It gates access to the structural knowledge
store for beliefs that survive falsification.
## Appendix B: Summary table of eliminated threats
| Threat | Eliminated at stage |
|--------|---------------------|
| Memory corruption | 3 — Lisp Machine |
| OS exploitation | 3 — Lisp Machine |
| Malware / viruses / worms | 3 — Lisp Machine |
| Compiler backdoors | 3 — Lisp Machine |
| Message forgery / tampering | 1 — [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]] |
| MITM on communication | 1 — Social Protocol |
| Unauthorized actions | 2 — Gate stack (fully at 3) |
| Prompt injection bypassing gate | 4 — In-process inference |
| Weight tampering (blob level) | 4 — Verified blob hash |
| Weight tampering (fine-grained) | 5 — Plist-native weights |
| Data poisoning / unauthorized training | 6 — Verified training + world model |
| Physical theft / EMP | Survives to 7 |
| Side channels | Survives to 7 (specification gap) |
| Oracle poisoning | Survives to 7 (ground truth gap) |
| Wrong spec / human error | Survives to 7 (intent gap) |
| Bootstrap axiom | Survives to 7 (Gödelian boundary) |
| External coercion / law | Survives to 7 (not solvable by computation) |
The system ends up deductively secure inside a physically and oracularly
bounded envelope. That envelope — the chip, the world, the user — is the
only remaining attack surface worth worrying about.
Every security guarantee in this document has a price. The question is not
"is this secure?" but "is the price worth it for the threat model it
eliminates?" For a personal AI that holds private conversations and manages
keys, Stages 1-4 may be enough. For a financial system that settles billions,
Stages 5-6 justify the overhead. The progressive threat model is also a
progressive cost-benefit analysis — know the price, then decide.
← [[id:4a1f23b0-abc7-4def-9876-543210abcdef][AI Training]]
:PROPERTIES:
:CREATED: [2026-05-24 Sun]
:WEIGHT: 17
:ID: 4a1f23b0-abc8-4def-9876-543210abcdef
:END:

118
projects/passepartout/architecture/systemic-effects.org Normal file
View File

@@ -0,0 +1,118 @@
:PROPERTIES:
:ID: b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba
:CREATED: [2026-05-23 Sat]
:WEIGHT: 50
:END:
#+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.
Using the [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders-of-magnitude framework]], the effects cascade across time scales. Each scale is qualitatively different, not just more of the same.
* Weeks to months — Phase Zero effects
** Scientific: verification becomes the publishing standard
Passepartout's gate rules turn every computational result into a machine-checkable proof. Papers carry proof logs, not just dataset citations. The replication crisis in compute-heavy fields (ML, climate science, genomics) meets its match — if the code doesn't verify, the result doesn't publish.
The effect compounds: proof repositories accumulate lemma libraries across fields, so each paper stands on verified shoulders, not on trust.
** Economic: the compliance industry's margins erode
The first enterprise that replaces a [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] audit with a gate rule saves $500K and two weeks. The Big Four consulting revenue in GRC (governance, risk, compliance) starts eroding — first at the margins (automated control testing), then structurally (the entire audit function).
[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Gate rule packages]] sell to the same CISO who buys audit prep today. The difference: audit prep is a cost center; gate rules are an investment that compounds.
** Political: regulation becomes executable
The first regulation encoded as a gate rule sets a precedent. Regulators realize they can specify compliance in executable form rather than prose. This changes the regulator-regulated relationship from adversarial interpretation to formal specification.
A regulation that says "access logs must be tamper-proof" is a negotiation. A gate rule that enforces Merkle-chain logging is a fact. Compliance shifts from "did you follow the intent" to "does the proof pass."
* Months to years — Phase Zero scaling, early End State
** Technological: AI safety becomes engineering, not policy
The verified API gateway ([[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][revenue hub]]) proves that AI safety is a software engineering problem, not a policy problem. Companies don't need AI regulation — they need Passepartout gate rules between the LLM and production.
This shifts the entire AI safety discourse. The question stops being "what should we ban?" and becomes "what gates should we verify?" Prompt injection, jailbreaks, data leakage, hallucination in critical paths — all become gate rule specifications, not white papers.
** Social: institutional trust gives way to computational trust
"I verified it" replaces "I trust the auditor." DIDs make platform-owned identity look like a historical anomaly. The [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS model]] makes surveillance advertising technically impossible without the user's active consent gate.
The social contract around data shifts: companies don't own user data because the architecture literally prevents them from accessing it without a permission gate. The [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] model (notice + consent) was a regulation trying to fix bad architecture. The PDS model is architecture that makes bad behaviour impossible.
** Cultural: verification earns cachet
The Lisp renaissance is not retro — it is the first time a language of proof carries cultural cachet outside academia. A new generation of developers grows up with verification as a default, not an afterthought.
The "move fast and break things" ethos ages overnight. In the C-suite, saying "we don't verify our deployments" becomes as embarrassing as saying "we don't test our code" was in the 2000s. The cultural shift precedes and enables the economic shift.
* Years — End State consolidates
** Economic: [[id:827bc546-e887-5b7c-9b65-6392beaf0920][the verification monopoly]]
If every transaction on the social protocol, every plugin in the environment, every gate rule passes through Passepartout's verification, then the early player collects a tax on the entire verified economy. This is the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]].
The $960B TAM ([[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][architecture index]]) is not aspirational — it is the cost of admission to the verified stack. Every dollar spent on cloud, AI, OS, social media, payments, and compliance eventually flows through the verification layer. The early player does not capture 100% of that, but the spread on even 5-10% is venture-scale money.
The switching cost to unverified infrastructure becomes infinite. No enterprise can justify "why would we go back to unverified code" once verification is in place. This is the [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]].
** Geopolitical: compute becomes a strategic asset
The [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] becomes a geopolitical asset on the order of SWIFT or the dollar. Whoever provisions the largest verified compute capacity becomes the default infrastructure provider for any nation that wants verified digital sovereignty.
Passepartout is inherently anti-surveillance-capitalist architecture. The PDS model does not do bulk surveillance. This makes it threatening to both:
- /Authoritarian states/ — they lose dragnet access to citizen data
- /Surveillance capitalists/ — they lose the data moat their business model depends on
The nations that adopt verified infrastructure are in one economic sphere. The nations that block it are in another. This is a new axis of the digital cold war.
** Political: liquid democracy infrastructure at scale
Verifiable proxy voting, delegation chains, quadratic funding for [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][public goods (Social protocol contracts)]] — these are not experiments. They become infrastructure that nation-states adopt because the alternative (unverifiable voting, opaque governance) becomes indefensible.
The effect is not that democracy becomes digital. The effect is that trust in institutions becomes a measurable property rather than a polling number. Did the government follow its own rules? The proof log says yes or no. This is the political equivalent of the scientific reproducibility shift: institutions that can produce proof logs are trusted; institutions that cannot are not.
* Generations — End State mature
** Geopolitical: the digital order is redefined
The verification network defines the digital order in the same way the internet defined the 1990s. Nations on verified infrastructure are in one economic sphere; nations that are not are in another.
Lisp Machine hardware becomes a strategic export control — like advanced semiconductors today. Passepartout is not a product category; it is infrastructure sovereignty.
** Cultural: the break-everything era becomes a historical curiosity
The "move fast and break things" era is remembered like bloodletting or lead paint. A developer who does not verify is like a civil engineer who does not do structural calculations. The entire profession shifts from "write code" to "write verified code" as the default.
The cultural residue of the unverified era (daily security patches, ransomware as an industry, "works on my machine") becomes a teaching example of how things used to be done.
** Scientific: proof libraries as shared inheritance
ACL2 proof libraries are the arxiv of verified knowledge. The accumulation of proof strategies across millions of domains — every edge case ever encountered, every lemma ever proven — becomes a shared inheritance that no single human could assemble. The system bootstraps itself into regions of proof space that no unassisted human could reach.
The frontier shifts. The question is no longer "can we verify this" but "what new things become possible when verification is free." The corollary: what new kinds of error become possible when the proof is wrong? The proof is machine-checkable; the specification is human. Specification errors become the dominant failure mode — and that is a more tractable problem than runtime bugs, because specifications can be verified against other specifications.
** Economic: the old economy becomes a historical layer
Proprietary software [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]], cloud lock-in, compliance consulting, annual audit firms — these are as alien to someone born into the verified era as mainframes and COBOL are to a cloud-native developer. The new economy runs on verified infrastructure where the marginal cost of verification is zero and the switching cost to unverified infrastructure is infinite.
The insurance industry, which prices based on risk, shifts to pricing based on proof coverage. Companies with full verification pay lower premiums. Companies without it cannot get insured. This is the completion of the feedback loop: verification is not just better engineering — it is a requirement for participation in the formal economy.
* References
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture index]] — the full Passepartout architecture
- [[id:a1fac32a-47de-5fbd-b67d-29152c851747][Architecture overview]] — the three subsystems
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams overview]] — economic effects quantified
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Social protocol contracts]] — governance, insurance, liquid democracy
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] — the big money
- [[id:2f783eb4-638e-5afa-9b59-6224d086a712][Infrastructure lock-in]] — switching costs
- [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][Orders of magnitude — time]] — the framework that structures this analysis
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] — Phase Zero vs End State mapping
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] — the geopolitical asset
- [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine security]] — why the architecture is anti-surveillance by design
- [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][AI industry impact]] — how verification changes the AI landscape

Some files were not shown because too many files have changed in this diff Show More