External Epistemic Memory

What is EEM?

External Epistemic Memory (EEM) is knowledge that lives outside the model, carries its justifications with it, and lets you understand how the system knows what it knows.

EEM is defined by three load-bearing properties: it is external (outside model parameters), epistemic (justified beliefs with truth values), and memory (persistent semantic knowledge). Each property is necessary. Together they distinguish EEM from every other approach to LLM knowledge management.

Three Properties

External

Knowledge lives outside model parameters, in a separate substrate. It survives compaction, model swaps, and session boundaries. It is separable, copyable, shareable, inspectable, editable, and auditable. Of these six properties, auditability is the most epistemically important — it makes “how do you know that?” answerable by justification chain traversal.

Epistemic

Not just facts but justified beliefs with truth values (IN/OUT), retraction cascades, contradiction records (nogoods), and derivation depth. This is what distinguishes EEM from RAG, which is external semantic memory but not epistemic.

Memory

Persistent structured knowledge in Tulving's semantic memory category — not ephemeral context. The knowledge persists across sessions, across models, and across time.

What EEM Replaces

EEM vs RAG

RAG is external semantic memory but not epistemic. It retrieves content by similarity but has no justification chains, truth values, retraction cascades, or contradiction tracking. EEM adds the epistemic layer that RAG lacks. RAG retrieves raw chunks the model must reason over from scratch every time. EEM retrieves pre-computed, reviewed, justified beliefs — the reasoning happened during construction and is amortized across all queries.

EEM vs Context Windows

Conversation history and context windows are ephemeral — lost at session boundaries, destroyed by compaction. EEM persists across sessions and model swaps. Context compaction destroys justification networks (quantified across 33 measured compaction events). Large context windows are primarily needed for tracking human conversational state, not for problem-solving — an agent with EEM and external memory tools can solve most problems with a 64k context window.

EEM vs Parametric Knowledge

In-parameter knowledge has no audit trail. It cannot be inspected, corrected, or traced to sources. EEM makes “how do you know that?” answerable by justification chain traversal. When challenged, a model with only parametric knowledge constructs reasoning post-hoc — you cannot distinguish a correct answer from a hallucination decorated with fabricated justification. EEM provenance is real: built at derivation time, not retrofitted.

EEM vs Self-Assessed Confidence

LLM self-assessed confidence does not track accuracy. Confirmed across 4 model families (corrected March 2026): Opus r=0.280, Flash r=0.267, Sonnet r=0.223, Pro r=0.137. Confidence explains only 2-8% of variance. Revision based on self-assessed confidence damages accuracy in all 4 models (Opus -3pp, Sonnet -12pp, Flash -15.5pp, Pro -41.5pp). Answer and confidence come from the same process — the same structural flaw as human overconfidence (Kahneman). EEM replaces “am I sure?” with “is this justified?” Confidence experiment methodology.

EEM vs Fine-Tuning / LoRA

Fine-tuning and LoRA adapters require access to model weights, training infrastructure, and must be repeated per model per domain. EEM achieves the same effect — domain-adapted model behavior — through the context window, without weight access. The derive step is the LLM building its own adapter in token space. Unlike LoRA, EEM adapters are inspectable, revisable, composable, and transferable across models. The same beliefs.db works with Claude, Gemini, Qwen, or any future model.

How It Works

Belief Maintenance System (BMS)

EEM is built on Doyle's (1979) Belief Maintenance System architecture¹: SL justifications with antecedents, propagation cascades, retraction cascades, and an exogenous problem-solver slot. The BMS substrate is content-agnostic by design.

Hybrid Architecture

The implementation is a hybrid BMS: symbolic BMS handles structure (justifications, propagation, cascades, backtracking, challenge/defend) while LLMs handle semantic operations (derive generates beliefs, review-beliefs critiques them, contradiction detection finds nogoods). Putting an LLM in the BMS problem-solver slot is what Doyle's architecture prescribes.

Key Mechanisms

• SL Justification — a node is IN when ALL antecedents are IN. Multiple justifications allowed — node stays IN if ANY justification is valid. Enables non-monotonic reasoning via outlist.
• Retraction Cascade — when a node goes OUT, all dependents whose justifications become invalid also go OUT, automatically and transitively. Retract one belief and the network figures out what else falls.
• Nogoods — a set of nodes that cannot all be IN simultaneously. When detected, dependency-directed backtracking traces backward through justification chains and retracts the responsible premise with fewest dependents (minimal disruption).
• Challenge/Defend — dialectical argumentation: challenging a node makes it go OUT. Defending neutralizes the challenge. Multi-level chains supported. Preserves the original argument unlike retract.
• Restoration — when a retracted node comes back IN, dependents are recomputed — no manual rederivation needed.

Derive-then-Review

Over-derive, then review catches errors, retraction cascades propagate corrections. Both roles overshoot: derive over-generates, review over-retracts. Working through candidate retractions is where insights hide. 13-37% of derived beliefs are retracted per review round — the system finds and removes its own errors.

Universal Chunking

Source material of any size — code, documentation, papers, logs — is chunked into manageable pieces, each processed into beliefs. The beliefs are orders of magnitude smaller than the source (9-26x compression measured). No stage of the pipeline requires more than ~20k tokens of context. A 64k context window is generous. Even 32k is workable. EEM construction is the step that makes arbitrarily large problems tractable.

Measured Results

98.5%

A/B grade across 3,853 questions with dual-path architecture (Claude Opus 4.6, May 2026). Zero D/F grades — eliminated the failure tail entirely. Full-scale validation methodology.

88% vs 33%

Expert-service with EEM (Claude Opus 4.6) scores 88% A-grade vs agent pipeline baseline 33% on same 50 Red Hat domain questions, 15x faster. Three rubrics, six systems tested (May 2026). Three-way eval methodology.

7,319

Beliefs built by Qwen 3.8 27B (a local open-weight model) across 10 repositories at zero API cost. Hypothetical cloud model cost for the same work: ~$1,243. Quality validated by a successful 3,800-line game port using these beliefs.

40+

Expert knowledge bases built across domains, from 237 beliefs (aap-expert) to 12,731 beliefs (redhat-expert). Code, documentation, Jira, literature, and cross-domain aggregations.

Model Compensation

EEM compensates for model size: Sonnet 4.6 + beliefs approximates Opus 4.6 without beliefs. Haiku 4.5 with dual-path achieves 94% A+B, matching Opus at 98%. Smaller models with EEM match larger models without it. This means you can use cheaper inference providers and compensate with better knowledge.

Small Model Construction

EEMs don't require large models to build. Qwen 3.8 27B (running locally at zero cost) built 7,319 beliefs across 10 Rust repositories with derive-from-scratch. Haiku built 972 beliefs with depth-6 architectural findings for under $30. The derive-then-review quality gate works regardless of which model drives it — iterative inference compensates for model size.

Expert Prompt Paradox

Telling an agent it is an expert reduces belief utilization. Beliefs alone outperform beliefs + expert prompt: Opus 4.6 100% vs 94.2%, Sonnet 4.6 94.2% vs 91.8% (March 2026, 50 questions). The humble generic prompt produces better results because the agent consults the knowledge base instead of trusting its “expertise.” Expert prompt ablation methodology.

Self-Critique Failure

LLM revision based on self-critique makes answers worse across all 4 tested model families: Pro dropped 41.5pp, Flash dropped 15.5pp, Sonnet dropped 12pp, Opus dropped 3pp (March 2026, corrected). Self-critique fails because the same model that made the error evaluates the error. EEM externalizes the critic's judgments, replacing internal self-assessment with external structured tracking. Self-critique experiment methodology.

Architecture

Dual-Path Retrieval

EEM is queried via dual-path retrieval: BMS path (pre-computed beliefs) + FTS path (source chunk search), merged by a third pass. Each path stays within cognitive budget.

Cognitive Budget

Borrowed from graphics frame budgets: decompose work into focused passes (BMS pass, RAG pass, merge pass) each within the model's attention budget. Mixing beliefs and document chunks in a single prompt degrades performance (Opus 4.6 drops 95.5% to 86%). Three focused passes achieve 100%. Architectural ablation results.

Context Window as Virtual Memory

With external memory tools, the context window becomes a cache, not a limit. The agent works with a few beliefs at a time, stores intermediate results back to memory, and retrieves new beliefs as needed. The effective context window becomes infinite. This is virtual memory — the same solution computing discovered when RAM wasn't big enough.

Dynamic Knowledge Adapter

The context window functions as a LoRA adapter without weight access. An EEM is the mechanism: the LLM processes source documents and produces beliefs — semantic weight-equivalents in token space — that condition the model's activations the same way LoRA weight updates would. At query time, the LLM queries the EEM and assembles its own domain adapter on demand from the relevant belief slice. No pre-built adapter, no routing logic. The model is its own adapter engineer.

Expert Pipeline (Reasons Forge)

Reasons Forge is the construction pipeline: chunk source material, propose beliefs, derive connections, review derivations, detect contradictions, deduplicate, export. Available as a CLI and as an MCP server for integration with Claude Code, IDE extensions, and custom agents. Value accrues at each stage. Derive produces new knowledge — connections the source doesn't make explicit.

Knowledge Provider & Inference Provider

AI agent architecture separates into two distinct roles: a knowledge provider (EEM) and an inference provider (LLM). The model provides inference (reasoning, generation). The EEM provides knowledge (justified beliefs, contradiction records, derivation chains). These are different services with different scaling characteristics and different update cycles.

This is the same evolution computing went through:

The providers scale independently. You can upgrade the inference provider (swap Haiku for Opus) without rebuilding knowledge. You can expand the knowledge provider (add beliefs, run derive) without retraining the model. The knowledge provider has a unique property: it improves itself. Each derive-then-review cycle adds knowledge and corrects errors. The inference provider's quality is fixed between training runs.

Amortized Cost

EEM construction cost is O(chunks) + O(beliefs × rounds), amortized across all queries O(queries). The crossover point is the second query — after that, EEM is strictly faster and cheaper. Waiting for AI to reprocess documents at request time is like rebuilding database indexes on every query.

Reliability, Not Just Speed

The speed argument is real, but the reliability argument is what matters. Answers without EEM are unreviewed (13-37% of what models generate is wrong), have no contradiction checking, no retraction history, no justification chain, and no provenance. An unreviewed answer is an oracle that constructs reasoning post-hoc. EEM beliefs have real provenance — built at derivation time, reviewed, contradiction-checked, with every claim traceable to source material.

Small Models and Multi-Agent Collaboration

Once the knowledge provider is separated from the inference provider, multiple agents — running different models, at different times, for different purposes — can all share the same knowledge base.

Small Models Build EEMs

EEM construction doesn't require large models. The derive-then-review pipeline's quality gate catches errors regardless of which model generates them:

Iterative Inference

Small models compensate for limited capability through iteration. Round 1 names landmarks A, B, C. Round 2 sees those as context and finds D, E, F that it couldn't have found cold. The model's parameters don't change, but the knowledge it works from grows with each round. Haiku reached depth 6 by building on its own depth-1 derivations — finding genuine architectural issues (failure cascades, isolation bypass vectors, unverified root assumptions) that required multiple reasoning steps.

Multi-Agent Patterns

• Sequential: Haiku explores and derives depth 0-3, Opus derives depth 4+. Different inference providers, same knowledge provider.
• Parallel: Multiple agents scan different source partitions simultaneously. Deduplication and contradiction detection handle overlaps.
• Cross-model review: Qwen derives, Opus reviews. Neither model needs to know about the other.
• Application feedback: Bug finder discovers a new invariant violation, stores it as a belief. Code fixer retrieves it. Each agent's work makes the next agent's work better.

Optimal Pipeline

Use the right model for each role: small models (Haiku, Qwen) for exploration and shallow derivation. Medium models (Sonnet) for review and code generation. Large models (Opus) for deep synthesis and architectural reasoning. The knowledge provider means cheap models have access to the same pre-computed knowledge that expensive models would have derived themselves.

For AI Agents

LLM agents use EEM by:

• Querying beliefs via reasons search / reasons show / reasons explain before answering
• Citing node IDs for auditability
• Running reasons derive to generate new beliefs from existing ones
• Running reasons review-beliefs to self-audit
• Recording nogoods with reasons nogood when contradictions appear
• Storing findings back to the knowledge provider for future agents to use

The agent does not need to be told it is an expert — the knowledge base speaks for itself.

MCP Server (Reasons Forge)

Reasons Forge is available as an MCP server, providing EEM tools to any MCP-compatible client (Claude Code, IDE extensions, custom agents):

recall

Search beliefs by query

remember

Store a new belief

forget

Retract a belief

explain

Trace justification chain

beliefs

List beliefs with filters

checkpoint_save/load

Save and restore working state

Context Budget

For single-shot problems, pack beliefs and prompt into 32-64k context. For multi-turn agent work, keep the system prompt small (~3k for identity and tools), use the remaining ~50-60k as workspace, and retrieve beliefs on demand via tool calls. The agent decides what to page in and what to store back — the knowledge provider is always available for re-retrieval.

Two CLIs

Both are available in the ftl-reasons repository.

beliefs

Structured markdown KB with provenance and manual maintenance. Simple, flat. Use for independent facts.

reasons

Full BMS with automatic propagation, cascades, backtracking, and LLM-driven operations. Use for justified conclusions with dependency chains.

Getting Started

Install from the ftl-reasons repository, then:

1. reasons init — creates reasons.db
2. Add premises from observations: reasons add node-id "observation text"
3. Add justified conclusions with --sl to link dependencies: reasons add conclusion "derived text" --sl premise-a,premise-b
4. Use reasons derive to find connections the source doesn't make explicit
5. Use reasons review-beliefs to audit — expect 13-37% retraction rate
6. Retract when evidence changes: reasons retract node-id — cascades propagate automatically

Construction cost is O(chunks) + O(beliefs × rounds), but it amortizes across all queries O(queries). Process once, reason forever.

Glossary

BMS (Belief Maintenance System)

A system that tracks which beliefs are currently justified and automatically propagates changes when justifications change. Based on Doyle (1979).

IN / OUT

A belief's current truth status. IN means all its justifications hold. OUT means at least one required justification has failed.

SL Justification (Support List)

A rule that says “believe X when all of A, B, C are IN.” A belief can have multiple SL justifications — it stays IN if any one of them holds.

Retraction Cascade

When a belief goes OUT, everything that depended on it is automatically re-evaluated. Dependents whose justifications no longer hold also go OUT, transitively.

Nogood

A recorded contradiction — a set of beliefs that cannot all be true simultaneously. When detected, the system traces backward through justification chains to find the least-disruptive belief to retract.

Derive

An LLM operation that reads existing beliefs and proposes new ones with justification links. Generates knowledge the source material doesn't state explicitly.

Review

An LLM operation that critiques existing beliefs, proposing retractions for beliefs that are wrong, unsupported, or redundant. 13-37% retraction rate per round.

Knowledge Provider

The EEM service that stores and maintains justified beliefs. Provides search, explain, consistency checking, retraction cascades, and contradiction detection. Model-agnostic — any inference provider can query it.

Inference Provider

The LLM that provides reasoning, generation, and projection through concept space. Queries the knowledge provider for justified beliefs and uses them to produce grounded answers.

Reasons Forge

The construction pipeline that builds EEMs from source material. Available as CLI and MCP server. Handles chunk, explore, propose, derive, review, deduplicate, and contradiction detection.

Theoretical Foundations

• Doyle (1979) — Belief Maintenance Systems with SL justifications, propagation, retraction cascades, and an exogenous problem-solver slot.
• de Kleer (1986) — ATMS uses assumption-based environments and nogoods. BMS beats ATMS for EEM because revision matters more than multiple environments when the problem solver (LLM) produces 13-37% errors.
• AGM (Alchourrón, Gärdenfors, Makinson 1985) — formal theory for rational belief revision. Entrenchment scoring in backtracking is a crude approximation of AGM.
• McCarthy & Hayes (1969) — frame problem: what persists across state changes. Staleness checking addresses this by detecting when source files change under beliefs.
• Platonic Representation Hypothesis (Huh et al. 2024) — neural networks trained on different data and objectives converge toward a shared statistical model of reality. EEM operates on this shared concept space, which is why beliefs transfer across models.
• Kahneman & Tversky — overconfidence is structural: answer and confidence come from the same process in both humans and LLMs. EEM replaces “am I sure?” with “is this justified?”