The library as architecture.

Why a single model isn’t enough

A single causal model, built well, answers a specific question for a specific stakeholder at a specific time. That is a deliverable. It is not capability. The reasons are concrete:

• The next question comes from a different stakeholder. The marketing-mix model from last quarter cannot answer the supply-chain question this quarter, unless the structural assumptions in one connect to the structural assumptions in the other. They don’t, by default.
• The model’s assumptions decay. The expert who supplied the elasticity prior leaves. The market shifts. The structural relationship that was reasonable in 2024 is wrong in 2026. Nothing in the model itself flags this.
• The reviewer of the answer is not the builder. Six months later, a regulator, an audit committee, or a successor team needs to understand the model. The assumptions, the data lineage, the elicitation transcript — all need to be recoverable, not from the modeler’s memory.
• The model is wrong in ways the data didn’t show. A domain expert sees the output and identifies a missing edge. The model needs to be revised, not defended. Revision is a first-class operation, not a project rerun.

Each of these is a property of organizational reality — turnover, drift, audit, contestation. They are not properties of any particular model. They are pressures that act on every model. A model survives them only if there is something around it that absorbs the pressure: a structure that lets the model be composed, scoped, queried, audited, contested, and retired in ways that don’t depend on the person who built it.

That structure is the Library.

What the Library contains

The Library is not a folder of models. It is six categories of content, each tied to a specific operation the library must support:

1. The structured causal models themselves

The core content. Directed acyclic graphs, structural equations, parameter priors, identification assumptions. The models are first-class artefacts — named, versioned, queryable. See What Belongs in a Causal Model Library for the five categories of content the library has to contain, and the two design pressures that shape what each category looks like.

2. Composition primitives

How models join. Two models built separately can refer to the same variable, partially overlap in their assumptions, or contradict each other on edges. Composition primitives are the rules that say when two models can be combined, what the combined model means, and what gets checked when they touch. See How Causal Models Compose for the four primitives.

3. Scope & validity declarations

Where each model applies. Internal validation tells you the model is right within its frame. It cannot tell you whether the question being asked is inside the frame. Scope declarations are the artefacts that close that gap — explicit boundaries on population, time, regime, and assumption space. See Where a Causal Model Stops for what a scope declaration contains and how it flows through the library.

4. The translation interface

How questions become queries. The stakeholder asks “what should we do?”; the library answers a formal causal query. The path between the two is the translation layer — four primitives that ensure what gets answered matches what was asked. See Where the Question Becomes the Query.

5. Provenance & audit

How the library remembers. Every estimate, every assumption, every revision is traceable to its source — the elicitation transcript, the parameter prior, the structural decision, the reviewer’s objection. Audit is not a separate process imposed on the library; it is a property of how the library stores its content. See How the Library Remembers for the four audit primitives.

6. The Caretakers

The work the library cannot do on its own. Models decay; assumptions get contested; new domains arrive; reviewers need to challenge structure. None of these are operations the library performs autonomously — each requires human judgment. The Caretakers are the roles that handle that judgment, and the library’s job is to make their work tractable, not to replace them. See The Work the Library Cannot Do.

How content enters the Library

The architecture above describes what the library contains. The authoring process describes how content gets in. Most organizations have causal knowledge that lives in experts’ heads — what causes loss-ratio deterioration, why a clinical protocol works for some patients, where the supply chain’s actual bottlenecks are. That knowledge is the raw material for the library. Getting it out of the heads and into the library is the engagement.

The process has four phases, each producing a committable artefact. See Encoding Your Experts’ Causal Knowledge — The Four Phases for the full treatment. The phases:

• Phase 1 — Make it explicit. Structured elicitation that turns causal claims (“X drives Y, but only when Z”) into directed graph fragments. Output: an initial DAG.
• Phase 2 — Find the bottlenecks. The places where one expert’s knowledge is the only source — the institutional single points of failure. Output: a heat-map of knowledge concentration.
• Phase 3 — The first transfer. A second expert reviews and contests the DAG. Disagreements surface explicit assumptions that no single expert would have named. Output: a refined DAG with structural assumptions documented.
• Phase 4 — From holders to architects. The experts whose knowledge populated the library become its caretakers. The transition is intentional: the role changes from source to steward.

The four phases produce content that has the properties the library needs — explicit, structured, contested, attributable. Content acquired any other way doesn’t.

Composition is the durability property

If a library contains 30 models and a new question requires a 31^st, the 31^st model is not built from scratch. It composes from the existing models — reusing the structural fragments that have already been built, validated, and scoped. Composition is what makes the library compound rather than accumulate.

Composition is also where the library is most fragile. Two models that are each internally valid can produce silent nonsense the moment they touch. The composition primitives — alignment, restriction, merge, transport — are the rules that catch the failure modes. See How Causal Models Compose for the four primitives and the worked example.

Composition depends on scope. Two models composed across incompatible scopes are exactly the silent-nonsense failure mode the scope primitives exist to prevent. Scope declarations are the gating check on every composition.

Audit, provenance, and the Caretakers

The library’s answers are usable to the extent that they can be defended. Defense requires three things: a reviewer can see what was assumed, can challenge specific assumptions, and can trace each conclusion back to its evidence.

Provenance and audit are the library’s memory of its own reasoning. Every estimate carries the elicitation transcript that supplied its priors, the structural decisions that shaped its DAG, and the reviewer feedback that revised it. The artefact a regulator sees is not a model output; it is the trace from question to answer with every assumption inspectable along the way.

What audit cannot do, by itself, is identify when an assumption has gone stale. Markets shift; clinical protocols evolve; supply-chain topology changes. The model’s assumptions were correct under conditions that no longer hold. Detecting this is human work, not library work — it requires someone who knows both the model and the domain. The Caretakers are the roles that do this work, and the library’s job is to make their judgment efficient: surfacing models due for review, flagging contested assumptions, escalating contradictions between sub-libraries.

The library does not replace expert judgment. It compresses the cost of exercising it from impossible to tractable.

Why this architecture, not another

Alternative architectures exist. Three worth naming, and why each falls short:

• The model registry. A folder of trained ML models with metadata. Workable for predictive models. Does not work for causal models because the registry doesn’t store the structural assumptions, the elicitation lineage, or the scope of validity — all of which determine whether the model can answer a given question. A model registry can tell you the model exists; it cannot tell you whether the model applies.
• The LLM-as-engine. An LLM that reasons over a corpus of expert documents. The problems are the ones argued on the Why not an LLM? page: no mechanism, no access to your specific structure, no audit trail. Fluent but unaccountable.
• The single monolithic model. One causal model that tries to cover the whole organization. Brittle in exactly the places the library is robust: composition, scope, contestation, revision. A single model is a single failure point.

The Library architecture exists because each of these alternatives fails on a specific property the underlying pages develop in detail. Composition, scope, translation, audit, caretaker support — each is a property the library is built to provide and each of the alternatives lacks.

For the deeper position behind the architecture — the framing of an organization’s causal knowledge as an asset that must be made explicit before it can be operated on — see the Causal Memory hub.

Further reading

Two pages situate the Library within the broader research landscape. They are useful for readers comparing this architecture to academic and commercial alternatives.

The Literature is an annotated reading list of papers that move the field — recent work in identification, transport, sensitivity analysis, and structural-causal-model methodology. Each entry states what the work does, why it matters for applied causal modeling, and what it changes in how the models on this site are built.

Four Paradigms, One Bet situates the Library against three alternative ways to combine LLMs and causality. The four paradigms place the LLM in different roles — assistant, reasoner, generator of causal knowledge, or mediator over a structured library. The page argues why the fourth is the right bet, and what the others get wrong.