Fix Untitled titles: convert all YAML frontmatter to org-style headers
This commit is contained in:
Hermes
@@ -3,6 +3,7 @@
|
||||
: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
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Definite Description Resolution
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Definite Description Resolution
|
||||
:PROPERTIES:
|
||||
:ID: 3f4573b2-aa55-44a7-a6c8-861dc443ac32
|
||||
:ID: design-description-resolution
|
||||
:CREATED: [2026-05-14 Thu]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Literate Programming as Discipline
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Literate Programming as Discipline
|
||||
:PROPERTIES:
|
||||
:ID: e6269aec-ea0a-406e-8b44-9dbd7b38c83a
|
||||
:ID: design-literate-programming
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Local-First Architecture
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Local-First Architecture
|
||||
:PROPERTIES:
|
||||
:ID: 3747ae5f-b4e5-4503-b397-a5b07862062d
|
||||
:ID: design-local-first
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Observability and the Thought Trace
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Observability and the Thought Trace
|
||||
:PROPERTIES:
|
||||
:ID: ee527687-28e2-4f0f-8d3c-af5cc531e3d4
|
||||
:ID: design-observability
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Cybernetic Loop: Why the Metabolic Pipeline Works
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Cybernetic Loop: Why the Metabolic Pipeline Works
|
||||
:PROPERTIES:
|
||||
:ID: bf3f84da-358b-4d87-bc1a-fa91d1994e20
|
||||
:ID: design-cybernetic-loop
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Evaluation Harness
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Evaluation Harness
|
||||
:PROPERTIES:
|
||||
:ID: a6dd0808-4366-4bda-be6e-f6d43f2eeab8
|
||||
:ID: design-evaluation-harness
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The MCP Strategy
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The MCP Strategy
|
||||
:PROPERTIES:
|
||||
:ID: bffb1695-5bf5-4434-8f64-e74f19d2e537
|
||||
:ID: design-mcp-strategy
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The REPL as Cognitive Substrate
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The REPL as Cognitive Substrate
|
||||
:PROPERTIES:
|
||||
:ID: 1ede13cb-05c0-4b1a-a873-98cf89bade81
|
||||
:ID: design-repl-cognition
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Time Awareness as a Structural Advantage
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Time Awareness as a Structural Advantage
|
||||
:PROPERTIES:
|
||||
:ID: 9e9950a8-82a5-42db-af2d-742ba09ff8ed
|
||||
:ID: design-time-awareness
|
||||
:CREATED: [2026-05-07 Thu]
|
||||
:WEIGHT: 40
|
||||
: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:
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Token Economics and Performance Advantage
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Token Economics and Performance Advantage
|
||||
:PROPERTIES:
|
||||
:ID: 876fe3af-80fb-42dc-a0d0-714670e5b964
|
||||
:ID: design-token-economics
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
: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.
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Homoiconicity as Foundation
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Homoiconicity as Foundation
|
||||
:PROPERTIES:
|
||||
:ID: 7dee11bc-72b0-43a3-9bc8-2f022b59ba49
|
||||
:ID: design-homoiconicity
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Non-Negotiable Identity
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Non-Negotiable Identity
|
||||
:PROPERTIES:
|
||||
:ID: 0a33bd83-ff3c-4eac-bc97-83eb6702051a
|
||||
:ID: design-identity
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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).
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: One Single Agent
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* One Single Agent
|
||||
:PROPERTIES:
|
||||
:ID: 92e314a1-a650-4878-958a-9646aef4e032
|
||||
:ID: design-multi-agent-default
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Org-Mode as Unified AST
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Org-Mode as Unified AST
|
||||
:PROPERTIES:
|
||||
:ID: 4bf2264c-db97-4d7b-9972-5a5d052d80be
|
||||
:ID: design-org-unified-ast
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Unified Memory Argument
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Unified Memory Argument
|
||||
:PROPERTIES:
|
||||
:ID: 1076101b-6201-4461-81e5-38d7886b66af
|
||||
:ID: design-unified-memory
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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."
|
||||
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
: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
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Performance — Why Ontology Growth Doesn't Make the System Slower
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Performance — Why Ontology Growth Doesn't Make the System Slower
|
||||
:PROPERTIES:
|
||||
:ID: 772ae489-b10a-48a0-bc3b-29136163d45b
|
||||
:ID: design-performance
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Provenance Chain as Product
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Provenance Chain as Product
|
||||
:PROPERTIES:
|
||||
:ID: 2e3e576e-8839-4566-bae1-f40137428bb9
|
||||
:ID: design-provenance-product
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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."
|
||||
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
: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
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Empirical Validation — MOMo and Modular Ontology Engineering
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Empirical Validation — MOMo and Modular Ontology Engineering
|
||||
:PROPERTIES:
|
||||
:ID: b572b3a0-0238-470f-9bf8-63d356f68fe0
|
||||
:ID: design-momo
|
||||
:CREATED: [2026-05-08 Fri]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Semantic Wikipedia as Entity Backbone
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Semantic Wikipedia as Entity Backbone
|
||||
:PROPERTIES:
|
||||
:ID: 183253ff-a0b7-468e-9858-6cb8ae2fb246
|
||||
:ID: design-wikipedia
|
||||
:CREATED: [2026-05-08 Fri]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,8 +1,7 @@
|
||||
---
|
||||
title: Open Questions
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
:PROPERTIES:
|
||||
:END:
|
||||
#+title: Open Questions
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
* Open Questions
|
||||
|
||||
|
||||
@@ -1,8 +1,7 @@
|
||||
---
|
||||
title: Relation to Passepartout's Existing Architecture
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
:PROPERTIES:
|
||||
:END:
|
||||
#+title: Relation to Passepartout's Existing Architecture
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-11 Mon]
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
: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
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Layered Signal Authentication — Trust in the Pipe
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Layered Signal Authentication — Trust in the Pipe
|
||||
:PROPERTIES:
|
||||
:ID: 7e2f0f84-c2ad-4036-b2ba-0630776c73c8
|
||||
:ID: design-layered-auth
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Self-Preservation — The Active Third Law
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Self-Preservation — The Active Third Law
|
||||
:PROPERTIES:
|
||||
:ID: 02f01d02-fc56-4551-81da-8704dbd65d89
|
||||
:ID: design-self-preservation
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Type-Level Gates — Structural Safety from Self-Modification
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Type-Level Gates — Structural Safety from Self-Modification
|
||||
:PROPERTIES:
|
||||
:ID: c47b80ec-2cf2-44ce-9781-96c14498669d
|
||||
:ID: design-type-level-gates
|
||||
:CREATED: [2026-05-14 Thu]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
: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
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Abstract Fact Store Interface — Modular by Design
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Abstract Fact Store Interface — Modular by Design
|
||||
:PROPERTIES:
|
||||
:ID: 64be38aa-56ca-4960-92e1-f3fc4cb51a2e
|
||||
:ID: design-fact-interface
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Cardinality Policies — Singular, Dual, and Plural Facts
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Cardinality Policies — Singular, Dual, and Plural Facts
|
||||
:PROPERTIES:
|
||||
:ID: f23e5518-bf2a-459e-8d2e-a9645fad76ac
|
||||
:ID: design-cardinality
|
||||
:CREATED: [2026-05-08 Fri]
|
||||
:WEIGHT: 40
|
||||
: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?"
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Ephemeral First, Persistent Later
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Ephemeral First, Persistent Later
|
||||
:PROPERTIES:
|
||||
:ID: 1b88cec6-76d8-4496-ae36-1bf16b5bc962
|
||||
:ID: design-ephemeral-first
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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,16 +1,8 @@
|
||||
---
|
||||
title: How Categories Grow — The Organic Ontology
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* How Categories Grow — The Organic Ontology
|
||||
:PROPERTIES:
|
||||
:ID: ce124de6-6777-4dca-aaf3-57e842c1855b
|
||||
:ID: design-organic-ontology
|
||||
:CREATED: [2026-05-08 Fri]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Knowledge Graph Type Hierarchy — Structural Anti-Self-Reference (v3.0.0)
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Knowledge Graph Type Hierarchy — Structural Anti-Self-Reference (v3.0.0)
|
||||
:PROPERTIES:
|
||||
:ID: 699de53a-06ff-4815-9f9d-70b006d372b8
|
||||
:ID: design-kg-type-hierarchy
|
||||
:CREATED: [2026-05-14 Thu]
|
||||
:WEIGHT: 40
|
||||
: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."
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Merkle DAG for Version History
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Merkle DAG for Version History
|
||||
:PROPERTIES:
|
||||
:ID: d08f4f7b-6800-4625-a8f6-f91b3231ae2e
|
||||
:ID: design-merkle-dag
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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).
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Ontology Versioning — How Worldviews Change Without Losing Perspective
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Ontology Versioning — How Worldviews Change Without Losing Perspective
|
||||
:PROPERTIES:
|
||||
:ID: 49104db7-0c41-4507-8755-42b4a48b7cc9
|
||||
:ID: design-ontology-versioning
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Awakening — Sufficiency Criterion
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Awakening — Sufficiency Criterion
|
||||
:PROPERTIES:
|
||||
:ID: 5788ad0f-45fb-4b2d-a3ab-09a4d95f351c
|
||||
:ID: design-awakening
|
||||
:CREATED: [2026-05-08 Fri]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Chosen Path: Option 4, Starting with Option 5
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Chosen Path: Option 4, Starting with Option 5
|
||||
:PROPERTIES:
|
||||
:ID: b21917d8-cb6e-4959-96c0-9326b0611134
|
||||
:ID: design-chosen-path
|
||||
:CREATED: [2026-05-08 Fri]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Five Architecture Options
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Five Architecture Options
|
||||
:PROPERTIES:
|
||||
:ID: e9c7a384-b42d-4dff-8da7-d4b62bb69956
|
||||
:ID: design-five-options
|
||||
:CREATED: [2026-05-08 Fri]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Gate-to-Fact Bootstrap — Extracting the First Ontology from Code
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Gate-to-Fact Bootstrap — Extracting the First Ontology from Code
|
||||
:PROPERTIES:
|
||||
:ID: 28a8caf7-c0a1-4154-8ca3-3a0d11cf121a
|
||||
:ID: design-gate-bootstrap
|
||||
:CREATED: [2026-05-08 Fri]
|
||||
:WEIGHT: 40
|
||||
: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:
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The LLM as Proposer — Verified Extraction
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The LLM as Proposer — Verified Extraction
|
||||
:PROPERTIES:
|
||||
:ID: 02798a39-c12b-4835-bc61-34f57a860cdb
|
||||
:ID: design-llm-proposer
|
||||
:CREATED: [2026-05-08 Fri]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
: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
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Core Knowledge: The Four Pillars of Agentic Reliability
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Core Knowledge: The Four Pillars of Agentic Reliability
|
||||
:PROPERTIES:
|
||||
:ID: dd9d7e5a-dd75-4762-8c31-f312de9c6585
|
||||
:ID: design-four-pillars
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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,16 +1,8 @@
|
||||
---
|
||||
title: The Dispatcher as Learning System
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Dispatcher as Learning System
|
||||
:PROPERTIES:
|
||||
:ID: 76d92677-1eb0-4a3a-bee7-561874841e45
|
||||
:ID: design-dispatcher-learning
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Probabilistic-Deterministic Split
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Probabilistic-Deterministic Split
|
||||
:PROPERTIES:
|
||||
:ID: 1937ee88-945e-4014-b5a0-cb3c8dcf1689
|
||||
:ID: design-probabilistic-deterministic
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
: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
|
||||
|
||||
@@ -1,14 +1,9 @@
|
||||
---
|
||||
title: Gaur & Sheth (2023): CREST — Trustworthy Neurosymbolic AI
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-11 Mon]
|
||||
:ID: ec267c73-4e0d-4efb-9497-cb72f74538e4
|
||||
:END:
|
||||
* Gaur & Sheth (2023): CREST — Trustworthy Neurosymbolic AI
|
||||
#+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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Historical Lineage — McCarthy's Advice Taker
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Historical Lineage — McCarthy's Advice Taker
|
||||
:PROPERTIES:
|
||||
:ID: 3d25a808-d623-42fb-a054-15fb28cd464b
|
||||
:ID: design-mccarthy
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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,14 +1,9 @@
|
||||
---
|
||||
title: Marcus (2020): The Case Against Pure Deep Learning
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-11 Mon]
|
||||
:ID: 4c65fdbb-a45c-4c71-ac29-6488e9271f4a
|
||||
:END:
|
||||
* Marcus (2020): The Case Against Pure Deep Learning
|
||||
#+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:
|
||||
|
||||
|
||||
@@ -1,14 +1,9 @@
|
||||
---
|
||||
title: Sheth et al. (2022): Knowledge-Infused Learning
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-11 Mon]
|
||||
:ID: a56c8e07-9e5b-4070-a0f9-280188ccd6b7
|
||||
:END:
|
||||
* Sheth et al. (2022): Knowledge-Infused Learning
|
||||
#+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."
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Competitive Argument
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Competitive Argument
|
||||
:PROPERTIES:
|
||||
:ID: 2e7d9fe6-6e78-41a0-96ad-b07777275d23
|
||||
:ID: design-competitive
|
||||
:CREATED: [2026-05-10 Sun]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Whitehead's Process Philosophy and Type Theory
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Whitehead's Process Philosophy and Type Theory
|
||||
:PROPERTIES:
|
||||
:ID: d251d338-f52e-4a17-b458-a255dd097b98
|
||||
:ID: design-validation-whitehead
|
||||
:CREATED: [2026-05-14 Thu]
|
||||
:WEIGHT: 40
|
||||
: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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user