Help Us Build The Library
A call to build the universal knowledge substrate that AI needs and humans deserve.
In the previous post, we described concept space – the high-dimensional geometry that LLMs navigate when they reason. We showed that structured beliefs steer models more precisely than prompts, that hallucinations are geometric collisions, and that the context window is a LoRA you already have.
This post is about what comes next: mapping the entire manifold. We call it The Library.
Three Eras
| Era | Substrate | Limitation |
|---|---|---|
| Web Era | Static pages searched by keywords | No structure, no verification, no logic |
| AI Era | Isolated LLMs generating answers per prompt | Ephemeral context, no persistence, each session starts from zero |
| Library Era | Curated logic graph co-authored by humans and AI | The thing we are building |
The Web Era gave us access to information. The AI Era gave us the ability to reason over it. The Library Era adds the missing piece: persistence with justification. Knowledge that carries its evidence, corrects itself when wrong, and accumulates value over time.
What The Library Actually Is
The Library is a network of domains – scoped knowledge bases that together map concept space. Each domain is a SQLite database containing beliefs with justification chains, truth values (IN/OUT), contradiction records, and embedding-based search.
A physics domain. A software architecture domain. A medicine domain. A legal domain. Each one is a chart in the differential geometry sense – a local coordinate system covering one region of the manifold. The collection of all charts is an atlas. The Library is an atlas of concept space.
Each domain is:
- Portable – a single SQLite file, runs anywhere, zero dependencies
- Justified – every belief traces back to source material through explicit justification chains
- Self-correcting – retracting a wrong belief cascades through all its dependents automatically
- Auditable – you can ask “why does the system believe X?” and get a traceable answer
- Model-independent – built by one model, queryable by any model, usable by humans
How Domains Get Built
The construction pipeline has four stages:
1. Ingest. Point the pipeline at source material – git repos, PDFs, documentation, markdown files. The system slices text along semantic boundaries.
2. Derive. An LLM reads the source material and generates structured beliefs with explicit justifications. This is the expensive inference step where the model does deep reasoning. Each belief names its antecedents – the other beliefs or source passages it depends on.
3. Review. A second pass (AI and/or human) evaluates each derived belief for validity, sufficiency, and necessity. Bad beliefs get retracted. Retraction cascades automatically through everything that depended on them. In practice, 13-37% of derived beliefs get retracted per review round. This is not a failure rate – it is the system working as designed.
4. Export. The reviewed beliefs are exported as a portable SQLite database (reasons.db). This compiled domain is the finished product – ready to serve via MCP, embed in a context window, or federate with other domains.
The expensive work (derive + review) happens once. Every future query is cheap retrieval. This is the thermodynamic argument: do not burn energy regenerating knowledge that has already been verified.
The Numbers
We have been running this pipeline for over a year across 40+ knowledge bases. The results:
| Metric | Without EEM | With EEM | Change |
|---|---|---|---|
| Per-query cost | Baseline | 0.53x | -47% |
| Synthesis speed | Baseline | 15x faster | Amortized construction |
| Accuracy (arch. questions) | Baseline | +12-14pp | Across 4 model families |
| Model equivalence | Opus alone | Sonnet + EEM | Same accuracy, cheaper model |
| Haiku + EEM | – | 94% A+B | Opus without EEM: 98% |
Smaller models with structured knowledge match or approach larger models without it. This means you can drop one or two model tiers and maintain quality. For organizations spending six or seven figures on AI inference, this is not an academic curiosity – it is a budget line item.
Why It Must Be Federated
A single centralized Library would face three structural problems:
Cascade collapse. In a universal graph, retracting one root belief could flip millions of downstream beliefs to OUT. Federated domains solve this by scoping retraction cascades to their boundaries. A correction in the physics domain does not accidentally break the chemistry domain.
Vocabulary collision. “Energy” means different things in physics, biology, and economics. No single schema works. Federated domains let each field use its own vocabulary. Embedding-based search handles translation – concepts with different names but similar meanings cluster together naturally. Cross-domain beliefs provide explicit bridges where needed.
Processing budget. You cannot run derive-then-review over billions of beliefs at once. Federated domains partition the problem. Each domain maintains itself independently, with daily cron updates keeping it current without requiring global reprocessing.
The architecture is not a design choice – it is the only design that works at scale. Three independent lines of reasoning (our research, Google AI’s first-principles derivation, and the classical TMS literature) converge on the same federated architecture.
The Protocol
The Library is a protocol, not a platform. The key decisions:
- SQLite as the domain format. Portable, zero-dependency, runs everywhere. A domain is a single file you can copy, email, or host.
- URL-addressable beliefs. Every belief has a globally unique address:
domain-url/belief-name. This makes cross-domain citation possible without requiring a central registry. - SL justifications. Every belief carries its support list – the antecedent beliefs it depends on. This is Doyle’s 1979 architecture, proven over four decades.
- MCP as the query interface. Model Context Protocol lets any AI agent query any domain. The tools:
deep_search,search,explain_belief,what_if,get_belief,list_beliefs,propose_belief.
Open protocol means anyone can build domains, anyone can host domains, and any model can query them. No vendor lock-in, no walled gardens.
Three Roles
Building The Library requires three kinds of work:
AI as miners and assemblers. LLMs run 24/7, traversing the boundaries of known knowledge through iterative derivation. They discover latent connections across concept space, propose new beliefs, and generate justification chains. This is the derive step – the part AI is already good at.
Humans as epistemic arbiters. When AI finds a contradiction or discovers a new conceptual cluster, humans decide what is true. They break ties, provide direction, and exercise judgment that no model can replicate. This is the review step – the part that keeps the system honest.
Community as curators. Domain quality depends on expertise. The physics domain needs physicists. The legal domain needs lawyers. The software architecture domain needs engineers who have built systems. No single team can curate all of human knowledge. The Library grows domain by domain, curated by the people who know each domain best.
What Exists Today
This is not a whitepaper about something we plan to build. The core infrastructure is running:
- Reasons Forge – the construction pipeline. Ingest, derive, review, export. Open source.
- 40+ expert knowledge bases built and serving queries across domains (enterprise products, codebases, classical AI literature, research projects)
- 12,731 beliefs in the largest single domain (redhat-expert), with justified dependency chains, retraction records, and contradiction logs
- MCP server serving domains to Claude Code, IDE extensions, and custom agents
- Daily cron maintenance keeping domains current as source material changes
The pipeline is proven. The question is not whether it works. The question is whether the community will help scale it.
What We Need
Domain builders. Pick a domain you know well. Build it. The pipeline does the heavy lifting – you provide the source material and the expert review. Start small: a single codebase, a collection of papers, a body of documentation. A useful domain can be built in a day.
Protocol contributors. The federation layer – cross-domain querying, sync protocols, domain discovery – is designed but not yet implemented. This is where distributed systems expertise matters.
Reviewers. The derive-then-review pipeline produces 13-37% retraction rates because AI over-generates. Human reviewers who can spot subtle errors, identify missing context, and flag contradictions are essential. This is the epistemic arbiter role – the quality gate that makes everything else trustworthy.
Skeptics. If this is wrong, we want to know. Bring counterarguments, edge cases, and failure modes. The Library’s own truth maintenance system works by recording contradictions and propagating corrections. The research program should do the same.
The Map Outlasts the Mapmaker
The Library is not tied to any particular model, company, or era of AI. A belief recorded today with its justification chain will be usable by models that do not exist yet. The concepts are real, the relationships between them are stable, and a map made with today’s tools will be navigable by tomorrow’s.
Early astronomers mapped the sky with instruments far cruder than what we have today. Their star maps are still useful. The Library is the same kind of project – mapping something real, something permanent, something that every future intelligence will need to navigate.
The tools to build it exist now. The question is whether we build it together.
The tools are open source at reasonsforge.com. The research is at llmeem.ai. Community at github.com/eem-hub.