memex/notes/passepartout-symbolic-engine-exploration.org

Toward a Symbolic Engine — Whitehead, Architecture Options, and the Ontology Problem

• The starting point: Whitehead's logic and its relevance
• The v1.0.0 to v3.0.0 path
• The problem with the translation layer
• Five architecture options
• The lossiness problem
• Verified extraction and non-lossy growth
• The flip: from lossy to deterministic
• The ontology is the bottleneck
• What remains open
• Relation to the competitive landscape

The starting point: Whitehead's logic and its relevance

Alfred North Whitehead, in collaboration with Bertrand Russell, produced Principia Mathematica between 1910 and 1913 as an attempt to derive all of mathematics from logical first principles. The work took over three hundred pages to prove that one plus one equals two. This is not pedantry. It is the unavoidable cost of building a formal foundation from axioms. Every symbol must be defined. Every inference rule must be justified. There is no shortcut.

Whitehead's later work, Process and Reality, replaced the substance ontology of Western philosophy (things are made of static objects) with a process ontology (things are made of events that become). His fundamental entities are not atoms or objects but actual occasions — events of becoming that prehend (grasp) other events, synthesize them, and reach satisfaction (completion). This maps with surprising precision to Passepartout's pipeline architecture, where signals pass through gates, each gate prehends the signal and either includes or excludes it from the developing response, and the final response is the satisfaction of the concrescence.

Both bodies of work are directly relevant to the v3.0.0 symbolic engine because they illuminate the two hardest problems. Principia Mathematica demonstrates why building an ontology is genuinely difficult — it requires defining the fundamental categories of what can be known and how they relate. Process and Reality provides a vocabulary for describing the pipeline's operation that is more precise than any software engineering terminology. The dispatcher does not "check" signals. It prehends them. Gates do not "pass" or "reject." They positively or negatively prehend. The signal pipeline is not a processing chain. It is a concrescence.

The v1.0.0 to v3.0.0 path

The version v2.0.0 describes a Lisp Machine desktop — Qt/EQL5, the Lish shell, a Nyxt-based browser, and mobile clients. This is a product surface, not a reasoning engine. The jump from v1.0.0 to v3.0.0 (skipping the desktop) is a jump from "agent with deterministic gates" to "agent whose reasoning is predominantly symbolic."

The ROADMAP describes an architecture called 10-80-10. Ten percent of computation is neural for input translation, eighty percent is symbolic for reasoning against a knowledge graph, and ten percent is neural for output formatting. The LLM translates natural language into structured queries — Prolog facts, knowledge graph lookups, constraint expressions. The symbolic engine, composed of VivaceGraph (a Lisp-native graph database with Prolog-like queries), Screamer (a constraint solver with non-deterministic backtracking), and ACL2 (a theorem prover for Common Lisp), handles the reasoning. The LLM then translates the symbolic results back into natural language.

There is an explicit dependency on the LLM at both I/O boundaries. The symbolic engine is described as taking the wheel, but the wheel is still connected to the LLM at the input shaft and the output shaft. The LLM is the only component in the architecture that can bridge between natural language and formal logic. Screamer can find solutions to constraint problems. ACL2 can prove properties of functions. VivaceGraph can store and query facts. None of these can read a human sentence like "find all functions that read files from the /tmp directory" and translate it into a graph query. None of them can take a constraint check result and explain to the user why it failed in terms the user understands. The neural dependency is in the human interface layer.

The problem with the translation layer

If the 10-80-10 architecture is implemented as stated — LLM translates natural language to structured queries, symbolic engine reasons, LLM translates results back — then the system has a problem that does not appear in the ROADMAP's description. The LLM's translation of the user's natural language into symbolic form is a lossy operation. The user's original phrasing, tone, intent, ambiguity, and all of the context that makes natural language rich are stripped away and replaced by formal assertions. If the translation is wrong, the symbolic engine reasons correctly from incorrect premises, and there is no way to trace the error back to its source because the original natural language is not preserved in the symbolic layer.

Worse, the reverse translation — symbolic result to natural language explanation — is also lossy. The symbolic engine might have derived a result through a chain of twelve constraint checks, each with its own justification in terms of existing facts. The LLM will summarize this into a paragraph of natural language. The justification is lost. The user cannot inspect the reasoning chain. The symbolic engine's transparency — its core advantage over pure neural systems — is erased at the output boundary.

This creates a dual-representation problem. If the knowledge graph stores only symbolic facts, then the natural language version of the user's knowledge (the prose in the Org files) is ephemeral and lost once translated. But if the system stores both — the original natural language and the extracted symbolic fact — then there are two representations of the same knowledge that can and will diverge. Which representation is authoritative? If the user writes "the security model considers .env files as sensitive" and the LLM extracts the fact (:security-model :covers :dot-env-files), and later the symbolic engine deduces (:not (:sensitive :dot-env-files) :because (:only-checked-at :write-time)), the two representations now disagree. The human expression and the symbolic deduction are in tension. There is no resolution within a single knowledge graph architecture.

Five architecture options

The discussion explored five distinct architectures for how the symbolic engine relates to the human memex. Each has different trade-offs, and none is clearly the correct choice yet.

Option one is the ROADMAP's auto-formalizer, where a separate knowledge graph stores symbolic facts and the LLM populates it by extracting facts from unstructured data (documentation, manuals, logs, session histories). The knowledge graph becomes co-authoritative with the human prose. This is the simplest implementation — build the KG, run the LLM in extraction mode, load the results, done. But it 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.

Option two preserves the two-memex architecture but treats them as intentionally separate domains. The human memex contains prose files — thoughts, diaries, decisions, documentation, logs. The symbolic memex contains formal facts — constraints, rules, relationships, deductions. The archivist skill bridges between them, extracting symbolic facts from prose when needed and projecting symbolic deductions back into human-readable explanations when the user asks. But the memexes do not try to stay synchronized. They are allowed to diverge because they serve different purposes. The prose captures what the human intends. The symbolic memex captures what the symbolic engine has proven. When they disagree, both are correct in their own domain. This is philosophically honest — it admits that no lossless translation between natural language and formal logic is possible — but it is also complex. The user must now reason about two separate knowledge stores and understand when to trust each.

Option three emerged from the observation that the tangle mechanism already handles the dual-representation problem for code. Lisp code lives in literate blocks within Org files (#+begin_src lisp). The tangle mechanism extracts these blocks and generates .lisp files. SBCL loads the compiled fasls into the running image. No one queries Org files as a code runtime. The Org files are the source form. The loaded image is the runtime form. Symbolic facts could follow the same pattern. A new block type — say, #+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. The archivist writes new fact blocks, Screamer derives new facts as new blocks, ACL2 verifies rule blocks, and all of it lives in the same Org files as the prose and the Lisp code. This is aesthetically appealing because it unifies the format. One toolchain, one version control system, one Merkle tree. But it does not solve the fundamental problem. The block language itself IS the knowledge representation language, and that language is the ontology we have not yet defined. The format is unified but the content is unspecified.

Option four is one memex with two indices. The prose remains in human language in Org files. The prose is the ground truth — always. Two indices sit on top of the prose as derived views. The neural index uses vector embeddings, which already exist in the codebase through embedding-native.lisp, to enable semantic search. The LLM navigates the prose through embedding space, retrieving relevant headings and contexts. 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. The LLM searches the neural index. The dispatcher and symbolic engine query the symbolic index. They do not need to understand each other's representations. They only need to agree on which heading or block they are referring to. And 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. The cost of rebuilding is compute, not data.

Option five is the simplest: make symbolic facts entirely ephemeral. 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. ACL2 verifies them. When the session ends, the facts are discarded and re-derived from the prose 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 might be the correct first step, as a way to learn what kinds of facts are actually useful before committing to a storage format.

The lossiness problem

The one-memex-two-indices architecture (option four) has a flaw that emerged during the discussion. A deterministic engine fed by a probabilistic extraction is not deterministic. The loss is inherited.

The neural index is lossy by design. A vector embedding approximates meaning by positioning text in a high-dimensional space. When the LLM searches "what functions handle security" against the neural index, it retrieves headings whose embeddings are close to the query embedding. The retrieval is approximate. Some relevant headings are missed. Some irrelevant headings are included. The LLM compensates by using its own understanding to filter and synthesize the results. This is acceptable for the neural domain because the entire domain operates on probabilities, not certainties.

The symbolic index cannot afford this. Screamer checking a set of constraint facts finds solutions that hold within the extracted set of facts, but those solutions may not hold in the real world because the extraction may have missed facts or introduced false ones. ACL2 proving a property about a set of extracted facts proves a property about the extraction — that from these premises, this conclusion follows. But if the premises are incomplete or incorrect because the LLM failed to extract them correctly from the prose, the proof is logically sound but practically useless. The probabilistic extraction poisons the deterministic engine.

The extraction is the weak link. The symbolic index cannot be "what the prose says" if the extraction mechanism is a large language model whose output is sampled, not proven. There must be a way for the symbolic index to grow without passing through the LLM.

Verified extraction and non-lossy growth

The resolution to the lossiness problem is not to abandon LLM extraction entirely. It is to separate the growth of the symbolic index into paths that do not involve the LLM and paths where the LLM proposes but the symbolic layer verifies.

The symbolic index can grow through four non-lossy mechanisms. First, the gate stack itself encodes implicit ontological claims. Gate vector two asserts that there exists a class of files called secrets. Gate vector seven asserts that there exists a class of commands called destructive. Gate vector eight asserts that there exists a class of domains called trusted. These claims are currently expressed as code — as Lisp functions that pattern-match against file paths, shell commands, and URLs. They are not facts. The symbolic engine cannot query them, derive new facts from them, or check them for consistency. But they can be made explicit. The gate stack can be bootstrapped into the ontology's seed. Every gate becomes a set of initial symbolic facts. (:class :secrets :member ".env"). (:class :secrets :member "*credentials*"). (:class :destructive-commands :member "rm -rf /").

Second, gate outcomes produce facts directly. Every time gate seven rejects a shell command, the dispatcher produces a plist with the matched pattern and the severity. This is already a symbolic event — it contains a category, a specific command, and a classification. The symbolic index can ingest these events as facts without any LLM involvement. A gate rejection is a fact: this command, at this time, in this context, was classified as dangerous. Over time, the set of classified commands grows, and Screamer can generalize from individual instances to broader patterns. The symbolic index grows from the runtime.

Third, deduction from existing facts. If Screamer knows that all commands containing "rm -rf" are catastrophic, and it observes that commands containing "shred" are similar in structure and effect, it can propose a new rule: all recursive deletion commands with device targets are catastrophic. ACL2 can check whether the existing ruleset already covers this case, whether it creates contradictions, and whether it is derivable from the existing axioms. If it passes all checks, the new rule is admitted as a derived fact with full provenance — not extracted from prose by an LLM, but deduced from existing facts by a deterministic engine.

Fourth, explicit human authoring. The user writes a defrule or defconstraint. It becomes a symbolic fact with no extraction step at all. The human is the author. The fact is admitted directly.

The LLM is not excluded from the process but is demoted from extractor to proposer. The archivist reads prose and proposes candidate facts. The LLM might be wrong. It might hallucinate a fact that does not correspond to anything in the prose. It might extract a fact that contradicts an existing fact in the symbolic index. It might propose a fact that is syntactically malformed and cannot be parsed by the symbolic engine's loader. None of these failures contaminate the symbolic index because the proposals are not admitted automatically. They must pass Screamer's consistency check against the existing facts, then ACL2's verification against the known rules. Proposals that fail are discarded. Proposals that pass are admitted with LLM-provenance flagged — the symbolic index knows that this fact originated from an LLM extraction, not from a gate outcome, a deduction, or a human authoring. This provenance can be used later to weigh the fact's reliability or to trigger re-extraction.

The LLM is still useful because it can surface facts that are obvious to a human reader of the prose but would take the symbolic engine many deduction steps to reach independently. But it cannot corrupt the symbolic index, because the admission gate is deterministic.

The flip: from lossy to deterministic

Even with verified extraction, the symbolic index begins its life as a lossy construct. The initial extraction from the prose — the first population of the symbolic index — cannot be verified against existing facts because there are no existing facts. The LLM produces the seed. The seed is uncertain. Some facts in the seed are correct. Some are incomplete. Some are wrong. The symbolic engine, in its first sessions, reasons from an uncertain foundation.

But this changes as the symbolic engine accumulates non-lossy facts through gate outcomes, deductions, and human authoring. The uncertain LLM-extracted facts are gradually replaced by proven facts. The gate stack's implicit claims become formalized. The repeated patterns of gate rejections produce categories that are not LLM-speculated but empirically grounded. Screamer's deductions fill in gaps that the LLM missed. The human explicitly authors rules that override incorrect extractions.

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 the prose, the symbolic engine reads the prose through its own lens and produces a deterministic index. This is not an LLM extraction verified by Screamer. It is the symbolic engine itself — with its now-substantial ontology of categories, rules, and constraints — parsing the prose and asserting facts in its own language. The extraction mechanism ceases to be probabilistic and becomes deterministic.

Whether this amounts to a "reindexing" depends on what the symbolic engine's language is capable of expressing. If the symbolic language can capture the full propositional content of the prose, then the symbolic index becomes a complete representation, which negates the meaning of "index" because an index is inherently a partial representation. A complete representation is not an index. It is a translation. But perhaps the symbolic language has different capabilities than a traditional index and can legitimately claim completeness within its domain — every actionable proposition in the prose, every constraint the gate stack needs, every fact the planner queries — even if it cannot capture tone, ambiguity, emotional weight, or aesthetic quality. The symbolic index would be complete for the purposes of the symbolic engine, while the neural index remains the gateway to the full richness of the prose.

The ontology is the bottleneck

All of these architecture options converge on the same unsolved problem: what is the knowledge representation language? What goes into the symbolic index? What syntax do the fact blocks use? What does Screamer query? What does ACL2 prove? What does the archivist write?

Whitehead proved that answering these questions is not a weekend project. Principia Mathematica had to define the logical connectives, the quantifiers, the theory of types, the theory of descriptions, the axioms of reducibility, and the foundations of arithmetic before it could prove anything at all. Every category introduced carries a burden of justification. Every inference rule must be demonstrated sound. Every symbol's semantics must be defined without circularity.

Passepartout faces the same problem, but for a different domain. Whitehead was building the foundation for all of mathematics. Passepartout needs an ontology for its bounded world: software engineering tasks, file system operations, security rules, tool capabilities, project structures, session histories, memory objects, gate outcomes. This is more limited than PM's scope, but it is still an ontology, and the difficulty is genuine. What does a "file" mean to the symbolic engine? Is it a path string, a memory object with a Merkle hash, an artifact with versions and provenance? Is it a member of a project, within a scope, with privacy tags and modification timestamps? Each of these attributes must be expressed in a formal language that Screamer can check, ACL2 can verify, and the archivist can populate.

The gate stack already encodes an embryonic ontology. Each gate is an implicit claim about a category of things. Making these claims explicit — extracting the ontology from the code — is the boot sequence for the symbolic engine. The categories latent in the dispatcher become the initial set of types and relations in the symbolic index. New categories are added as new gates are developed, as the archivist encounters novel prose patterns, and as Screamer deduces new classes from the patterns of gate outcomes.

The ontology grows organically from the system's own operation. It does not need to be designed upfront, the way Principia Mathematica required years of axiomatic design before any proofs could be written. It emerges from the interaction of the gate stack (which defines categories implicitly through pattern matching), the archivist (which surfaces new categories from prose), Screamer (which generalizes categories from instances), and the human (who explicitly declares new categories through rules and constraints). The seed is small — fifty to one hundred core categories extracted from the dispatcher's implicit claims. The growth is continuous.

What remains open

Several design questions are unresolved and should remain unresolved at this stage. They represent genuine research decisions that require more exploration.

The first is whether the symbolic index requires a separate persistence format or can live entirely in memory during the session. If the symbolic engine can re-derive its facts from the prose and gate stack on startup, then there is no need for a serialization format, and the ontological design can evolve without commitment. But re-derivation has a compute cost, and if the symbolic engine's reasoning accumulates value across sessions — if yesterday's deductions accelerate today's responses — then persistence is necessary. The question cannot be answered without knowing how the symbolic engine is actually used.

The second is what minimum viable fact language allows the symbolic engine to begin reasoning. A starting point might be triples: (:entity :relation :value), grounded to an Org heading and timestamped with provenance. (:file ".env" :is-member-of :secrets-class :source heading-23 :provenance :gate-bootstrap). This 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. The right granularity depends on what queries the planner actually needs to make.

The third is the contradiction policy. When the symbolic index contains two facts that cannot both be true — for example, when the prose asserts that a file is public in one heading and the gate stack classifies it as secret in a later outcome — what happens? The current dispatcher resolves conflicts by priority ordering (the gate with the highest priority wins). The symbolic index will need an analogous mechanism: either flag both and await human resolution, choose the more recent fact, choose the fact from the more trusted source (human authorship over LLM extraction, gate outcome over deduction), or maintain both as alternate world-states. This is a genuinely hard AI problem that is typically hand-waved in agent architectures but would become concrete and unavoidable in a working symbolic engine.

The fourth is the role of the human in the ontology's growth. The human can explicitly declare rules, write constraints, and correct symbolic facts. But how much of the ontology should the human need to maintain? If the human must write a defrule for every new category the symbolic engine encounters, the overhead is prohibitive. If the symbolic engine can generalize from instances — observing that Screamer has classified thirty-seven commands as dangerous and extracting the common structural pattern — then the human role becomes supervision rather than authorship. The human reviews and approves proposed generalizations. The symbolic engine proposes them. The balance between automatic induction and human verification is a design parameter that cannot be set without experience running the system.

The fifth is the format of the extraction. Even with verified extraction where Screamer checks LLM proposals, the LLM must still produce proposals in a format that the symbolic engine can parse. That format is a knowledge representation language, even if it is a provisional one. The format must satisfy multiple constraints simultaneously. It must be parseable by the tangle loader, present in the fact blocks if those are used, and machine-writable by the LLM. It must be queryable by VivaceGraph and Screamer, which implies a structured syntax with well-defined semantics. It must be human-readable in Org files, which implies a syntax that looks natural alongside prose and Lisp code. And it must be amenable to ACL2 verification, which implies a logic without side effects and with termination guarantees. These constraints pull in conflicting directions, and no existing language satisfies all of them simultaneously.

Finally, there is the question of the phased transition from the current architecture (95-5-0 neural-gate-symbolic) to the v3.0.0 architecture (10-80-10). This is not a single big-bang release. It is a progression where the symbolic engine gains autonomy incrementally. The PM-type-level gates can be added immediately, with the gate stack formalizing its implicit categories as seed facts. Screamer can be wrapped and loaded as a skill, initially used only for the archivist's verification step, later promoted to a planner component. VivaceGraph can be integrated as the persistence layer for the symbolic index, initially populated only by the gate bootstrap, then enriched by gate outcomes, deductions, and verified LLM proposals. The auto-formalizer — the LLM's extraction mode — can be developed as a separate skill that proposes candidate facts, with Screamer as the admission gate. The full 10-80-10 planner is the last component, built on top of a mature symbolic index that is already populated, queried, and trusted.

The path from here to v3.0.0 is not a matter of choosing the right architecture and implementing it. It is a matter of growing the architecture as the system itself learns what facts it needs, what categories are useful, and what knowledge representation language emerges from the interaction of the gate stack, the archivist, the constraint solver, and the human. The ontology is the work, and the ontology is emergent.

Relation to the competitive landscape

None of the surveyed fifty-five competitor systems has this problem. None of them is neurosymbolic at any level beyond prompt-engineering-based tool calling. They do not need an ontology because they do not have a symbolic engine. Their safety is heuristic. Their memory is flat. Their reasoning is entirely neural.

Passepartout's architectural bet is that the ontology problem is worth solving — that a system which can prove properties about its own behavior, derive new rules from observed outcomes, and reason against a verified 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 Whitehead demonstrated is genuinely difficult. The reward is a system that cannot hallucinate at the reasoning level, whose safety is provable rather than empirical, and whose knowledge accumulates across sessions through deduction rather than through LLM re-prompting.

This note does not resolve any of the open questions. It captures them at a level of detail that makes them distinguishable and thinkable. The design space is still open. The next step is not to choose the architecture but to begin building the components that make the architecture possible — the PM-type-level gates, the Screamer wrapper, the gate-to-fact bootstrap — and to learn from the building which architecture emerges.

See also: notes/passepartout-whitehead.org for the four concrete contributions from Whitehead's work (type-level gates, theory of descriptions, architectural vocabulary, and KG type hierarchy), and notes/competitive-landscape.org for the full survey of competitor systems and the five-level neurosymbolic spectrum.