Reasoning Infrastructure

For a Technical Reader

What you have when causal models cover all the considerations of a domain.

01 The idea

A single .bayes file covers one mechanism in a domain, claims frequency, treatment response, supplier failure, credit behaviour. Build enough causal models, ensure they share a consistent variable ontology, the same node names, the same units, the same conditioning conventions, and something qualitatively different appears.

You no longer have a collection of models. You have a domain knowledge graph: a library of composable causal building blocks that can be assembled into bespoke decision models without starting from scratch each time.

In EARA terms, this is exactly what the Library concept points at. Each model is a verified sub-model. Together they are the domain’s reasoning infrastructure.

Vandenplas, M. (2026). Enterprise AI Reasoning Architecture: A Reference Architecture for Trustworthy Enterprise AI. Working draft. Rung3.ai.

02 What you have

With a sufficient library of composable DAGs, you can:

Compose. Wire sub-models into a full decision model by connecting their interfaces. The front-door criterion handles identification across the seam. The composed model is immediately queryable at all three rungs.

Reuse. The mortality sub-model from one healthcare engagement plugs into another client’s cost model. The claims frequency sub-model built for one insurer transfers to the next. Every engagement benefits from all prior ones.

Update without rebuilding. If claims frequency shifts, replace that DAG and leave the rest intact. The composed model absorbs the change. No retraining. No redeployment. One file, versioned.

Interrogate at any level. Run inference on a sub-model alone, on a composed pair, or on the full domain graph. The same cognitive primitives, Explain, Inquire, Scenarios, Optimize, operate at every level of composition.

03 The properties

What emerges is a causal ontology for the domain: the insurance domain, the grid domain, the clinical pathway domain, expressed as a library of verified, composable, interoperable causal mechanisms.

Each sub-model has three properties that make composition safe:

A defined interface: the input nodes and output nodes are named and typed. Connection is explicit.
Independent testability: the sub-model can be validated in isolation before it is wired into a composition. A failure is locatable.
A documented assumption set: every edge, every CPT, every U-node encoding is stated. Composition inherits these assumptions and makes them visible.

These are not implementation conveniences. They are the audit trail for the composed model. A regulator challenging a decision made by a composed model can trace every claim back to the sub-model that produced it and the assumption set that governed it.

04 The analogy

The closest analogy in software is a microservices architecture: but for reasoning rather than computation. Each service (sub-model) has a defined interface, can be tested independently, and composes into larger systems through well-specified contracts.

The difference from microservices is that what flows through the interfaces is not data but probability, calibrated, certified, and auditable at every hand-off. The architecture does not just process information. It reasons about it.

A microservices architecture routes requests. A causal architecture routes beliefs, each sub-model updating its posterior given what it receives from its neighbours, and passing on what it has inferred.

05 The implication

The first firm to build that library for a domain owns the domain’s reasoning infrastructure. New clients get a head start because 70% of the relevant mechanisms already exist. Customisation is elicitation of the remaining 30%.

The corollary: a firm that builds models in isolation, without a shared ontology, does not accumulate this advantage. Each engagement starts from scratch. The library never forms.

This is also where the distinction between Rung3 as a consulting practice and Rung3 as a platform starts to matter. The consulting practice delivers causal models. The platform delivers the causal architecture that makes every subsequent model cheaper, faster, and more auditable than the last.

The long-run question is not which AI your organisation uses. It is whether the domain knowledge that makes AI useful to you is locked in a vendor’s weights, or in a library of causal models your organisation owns, maintains, and improves.

06 Where it sits

Reasoning infrastructure is not a component of EARA, it is what EARA produces over time. Each engagement adds verified sub-models to the library. Each sub-model is a composable building block. The library is the asset.

The methodology that produces the sub-models is documented at Methodology →. The cognitive primitives that operate on composed models are at Cognitive Primitives →. The governance artifacts that certify each composition are at Pipeline →.