Enterprise AI Reasoning Architecture

Enterprise AI will mature only when language becomes the interface to reasoning, not the reasoning itself.

The past decade of AI progress has delivered systems of remarkable linguistic capability. They summarize, retrieve, generate, and converse. What they do not do, structurally, by design, is reason. They have no explicit representation of how the world works, no mechanism for evaluating interventions, no architecture for uncertainty that holds up under audit, and no governance layer that produces artifacts a regulator can inspect. When an enterprise deploys a language model as a reasoning system, it is not making a technology choice. It is making a category error.

This paper introduces Enterprise AI Reasoning Architecture (EARA): a reference architecture that corrects that error by treating reasoning as a first-class architectural capability rather than an emergent property of language.

Scope. EARA is not proposed for all enterprise AI. It is most valuable for enterprise systems whose decisions must be reproducible, explainable, governable, or auditable, systems where the cost of an incorrect or unjustifiable recommendation is significant. For tasks that are fundamentally about language, drafting, summarizing, searching, classifying, a language model alone is often sufficient. The reasoning concern applies when the task is a decision, not merely a response.

The paper makes contributions at two levels.

Conceptual contributions

Three ideas underpin the architecture. Each introduces vocabulary the paper will use throughout.

Reasoning State

The explicit computational representation of an enterprise decision problem: beliefs, uncertainty, causal structure, evidence, goals, constraints, candidate actions, and assumptions. Reasoning state is to a reasoning architecture what data is to a database, the primary object the architecture exists to manage.

Reasoning as an Architectural Concern

The thesis that reasoning, like data, identity, messaging, and observability before it, has become important enough to deserve explicit architectural treatment. This is not a claim about what language models can or cannot do. It is a claim about where architectural responsibility should reside.

Reasoning Architecture

The architectural response to that concern: a set of components, interfaces, services, and artifacts that address reasoning explicitly and consistently, with language at the boundary and inference at the core.

Architectural components (EARA)

EARA realizes these concepts through five components. Each is defined in its own section.

Domain Models

Explicit, elicited representations of causal knowledge, distinct from a database, a vector store, or a language model’s parametric memory. A domain model is to enterprise reasoning what a database schema is to enterprise data. It is a new category of enterprise asset.

Cognitive Primitives

Reusable reasoning services, Explain, Inquire, Monitor, Optimize, Scenario, Robustness, Learn, each of which answers a specific class of enterprise question by orchestrating inference operations over the domain model.

Governance Artifacts

Typed, versioned, reproducible objects produced at each stage of the reasoning pipeline: Scope Card, Identification Certificate, Decision Certificate, Audit Record. These are the evidentiary basis for every recommendation, inspectable, contestable, and submissible to a regulator.

Memory

Episodic records of past reasoning that allow the system to accumulate experience: linking current episodes to similar past ones, detecting pattern change over time, and informing learning.

Language Interface

The boundary components that translate between natural language and the reasoning layer, parsing questions into typed queries at the front, narrating certified results in plain language at the back. The language model is confined to these two roles.

Together, these components define a system capable of answering the questions enterprise decisions actually turn on: What is the probability of this outcome? Why is that risk increasing? Which intervention will reduce it most? What evidence would reduce our uncertainty before we act? What would have happened had we decided differently? And can we show the regulator our reasoning?

A language model alone does not provide explicit architectural mechanisms for representing, governing, and certifying these capabilities. EARA does.

The Missing Layer in Enterprise AI

Every major advance in enterprise software architecture has followed the same pattern. A capability matters enough that leaving it implicit becomes a problem. It sits scattered across applications. It gets handled inconsistently. No one can govern what they cannot see. So the industry gives it its own layer: representations, services, interfaces, artifacts, patterns.

Data became a first-class architectural concern. Databases emerged.
Identity became a first-class architectural concern. Identity and access management emerged.
Messaging became a first-class architectural concern. Middleware and message queues emerged.
Observability became a first-class architectural concern. Logging, tracing, and monitoring platforms emerged.

In each case, the pattern was the same. The capability did not disappear from applications. It moved into its own layer, one no single application could have built alone, and every application got to use it.

Reasoning is becoming important enough that leaving it implicit inside applications is no longer adequate for enterprise systems.

1.1   The enterprise decision problem

An enterprise decision is not a retrieval problem. It is not answered by finding the most relevant document or generating the most plausible response. It requires an explicit reasoning state: a computational object that persists, evolves as evidence arrives, and produces certified output.

A reasoning state contains:

• Beliefs: probability distributions over the variables that matter, not point estimates or hedged language
• Uncertainty: quantified, not expressed as qualifiers like probably or it seems
• Causal structure: which variables influence which, under what conditions, and through what mechanisms
• Evidence: what has been observed, with what confidence, from what source
• Goals: what the organization is trying to achieve
• Constraints: what it cannot do, what it is unwilling to do, what policy requires
• Candidate actions: the options under consideration and their expected consequences
• Assumptions: what the system is taking for granted that an adversarial reviewer might contest

Language communicates this state. It does not constitute it. A system that produces a confident recommendation has not maintained a reasoning state, it has generated text that resembles the output of a system that did. The difference is invisible in the response and decisive in the audit.

1.2   Reasoning is not represented

There is no explicit computational object that holds the belief state. There is no typed artifact that records the evidence. There is no certified output that a regulator can inspect. The reasoning state that enterprise decisions require is transient, implicit, or absent altogether.

This is a structural observation, not a criticism of any particular model or vendor. These capabilities require explicit architectural support. They are not intrinsic to language modeling, regardless of how capable the language model becomes. Scaling improves language competence. It does not define how an enterprise system represents uncertainty, records evidence, executes policy, or produces auditable decisions. Those responsibilities belong to the architecture, not the language model.

Current enterprise AI architectures often treat language generation as a proxy for reasoning. A system that generates fluent, confident, well-structured text is assumed to be reasoning well. For many applications, that assumption is close enough. For enterprise decisions, where the reasoning state matters, where the assumptions must be named, where the output must survive an audit, it is not close enough. The failure mode is silent. There is no structural signal that the system has left its competence boundary. The response looks the same whether the reasoning was sound or fabricated.

1.3   What retrieval-augmented generation does not solve

The standard architectural response to these limitations is Retrieval-Augmented Generation: ground the language model’s responses in retrieved documents and the knowledge problem is reduced. RAG is a genuine improvement for knowledge-intensive tasks. It is not a reasoning architecture.

RAG addresses one specific deficiency: outputs are anchored to a document corpus rather than to parametric memory alone. It does not address the reasoning deficiency. The language model still performs the inference. The retrieved documents are evidence; the language model’s judgment over that evidence remains unstructured, uncertified, and unauditable. RAG improves evidence acquisition. It does not define how evidence is represented, evaluated, or transformed into decisions.

An enterprise that has deployed RAG has built a better-informed language model. It has not built a reasoning system.

1.4   What agent frameworks do not solve

Agent frameworks extend the reach of the language model by allowing it to select and invoke tools in sequence. They represent a genuine architectural advance over single-turn generation. They do not solve the reasoning problem.

In an agent framework, the language model remains responsible for coordinating the reasoning process. It chooses which tools to invoke, interprets their outputs, and synthesizes a response. The chain of tool calls provides structure without substance: an audit trail of what was invoked, not a derivation of why the conclusion follows from the evidence.

This produces a failure mode distinct from naive generation but equally consequential for enterprise use. An agent that reasons incorrectly will call the right tools in the wrong order, misinterpret their outputs, or reach a confident conclusion from ambiguous evidence. The structure of the agent trace creates an appearance of rigorous process without the reality of explicit reasoning state.

1.5   The pattern

What databases, identity management, messaging, and observability have in common is not that they introduced new capabilities. They made existing capabilities explicit. Data existed before databases; applications simply managed it themselves, inconsistently and without governance. Identity existed before IAM; applications simply implemented it themselves, with the results that security professionals spent the following decades correcting.

This principle applies across the history of enterprise software. For reasoning, that threshold is being crossed now, not because language models have become less capable, but because the enterprise use cases pressing against their limits have become more demanding. Clinical decisions, financial recommendations, security operations, regulatory compliance: these are domains where implicit reasoning, unauditable conclusions, and uncertified outputs are not merely suboptimal. They are liabilities.

Enterprise AI is starting down the same path. It shows up first where it matters most: systems whose decisions must be reproducible, explainable, governable, auditable. This is not a universal need. It scales with the cost of being wrong and not knowing it.

1.6   The gap, stated precisely

What has been missing is a reference architecture: one that organizes the components, defines the interfaces, specifies the artifacts, and gives every enterprise AI system a pattern to adopt, whatever inference engine sits underneath it.

The gap is not a better language model, more tools, or a longer context window. It is an architectural layer in which the domain model is explicit, uncertainty is represented rather than expressed, causal relationships are encoded structurally, and every recommendation produces a typed artifact that holds up under audit. Section 2 specifies what that layer must contain.

This paper proposes that reference architecture. We call it Enterprise AI Reasoning Architecture (EARA). EARA does not replace language models. It gives them an explicit reasoning architecture. It gives them something to reason with.

Section 2 defines the abstraction. Sections 3 through 5 specify the components. Section 6 shows what the architecture looks like in practice.

What Is a Reasoning Architecture?

Section 1 established that reasoning has become an architectural concern. This section defines what a reasoning architecture is, abstractly, before specifying how EARA realizes it. This paper specifies an architecture, not an inference engine. The definitions in this section are technology-agnostic. They apply to any system that addresses the reasoning concern, regardless of the specific inference engine, language model, or governance framework it uses.

2.1   Four formal definitions

Four terms require precise definition before the architecture can be specified. Precision here is not pedantry, it is what allows the paper to be implemented rather than merely read.

Every architectural decision in EARA follows from one commitment: reasoning state must be represented explicitly. What is explicit can be inspected. What is inspected can be audited. What is audited can be governed. The rest of the architecture is a consequence of that single commitment.

These definitions have a natural order: reasoning (2.0) motivates the state (2.1); the state motivates the concern (2.2); the concern motivates the architecture (2.3). A system that does not maintain explicit reasoning state is not a reasoning architecture, regardless of how sophisticated its language model is.

Terminology note. This paper uses five related but distinct terms: reasoning (Definition 2.0) refers to the cognitive process; reasoning state (Definition 2.1) is the explicit computational object that captures it; reasoning concern refers to the architectural responsibility of managing that state; reasoning architecture (Definition 2.3) is the architectural layer that addresses that concern; and reasoning engine refers to the inference component within that layer that computes over the domain model. These terms are not interchangeable. When later sections use “reasoning,” they mean the process defined in 2.0, not the engine, the state, or the architecture.

2.2   Why explicit representations matter

Modern software architectures distinguish between computation and representation. Computation produces results. Representation persists them. A database does not exist because computation over data is impossible without one. It exists because explicit representation makes data inspectable, versionable, auditable, exchangeable, governed. The same principle applies to every major architectural concern that has been separated from applications.

Databases represent data.
IAM represents identity.
Observability platforms represent system behavior.
A reasoning architecture represents reasoning state.

The shift from implicit to explicit representation is what transforms a capability into an enterprise asset. Data that lives only inside a computation, a running program, an in-memory object, a neural activation, cannot be inspected, audited, or governed. Data that lives in a representation can be. The same is true of reasoning state.

This is why the governance artifacts in Section 5 are not a compliance add-on. They are a structural consequence of the decision to represent reasoning state explicitly. Reasoning becomes an enterprise capability precisely because it is represented. What is represented can be certified. What is certified can be governed. What is governed can be trusted.

2.3   The separation of concerns

The central structural principle of a reasoning architecture is the hard separation between language and reasoning. This separation is not a stylistic choice, it is what makes the system auditable.

A reasoning architecture assigns exactly one concern to each architectural role. The following table describes those roles abstractly. Any conforming implementation must assign responsibility for each concern to a distinct component or layer.

The separation is enforced structurally. No natural language crosses into the reasoning core. No inference result is ever produced by the language model. The language model is permitted at exactly two points: parsing an incoming question into a typed query, and narrating a certified result into a plain-language response. Everything between those two points is deterministic, typed, and auditable.

This boundary is what makes reproducibility a structural property rather than a hope. The same query, the same domain model, the same evidence, the same result, every time. Not because the system tries to be consistent, but because consistency is enforced by the architecture.

2.4   The reasoning state lifecycle

Figure 2 shows how reasoning state evolves across a complete enterprise reasoning episode. This lifecycle is the organizing spine of the architecture: every component defined in Section 2.3 plays a role in at least one step, and every governance artifact defined in Section 5 is produced at a specific step.

Figure 2. The reasoning state lifecycle. A question initializes the state; evidence updates it; a cognitive primitive operates on it; a governance artifact certifies the result; policy acts on the certificate; the episode is archived; and learning periodically updates the domain model. This paper refers to this figure throughout: Section 3 covers domain model and state creation (steps 1–2); Section 4 covers cognitive primitives (step 5); Section 5 covers governance artifacts (step 6).

2.5   The signature diagram

Figure 1 shows the architecture as a layer between the language surface and enterprise applications. The amber boundaries are the only places natural language is present. Everything between them is the reasoning layer.

Figure 1. The EARA architecture. Natural language enters and exits at the amber boundaries. Everything between them is the reasoning layer: deterministic, typed, and auditable. Reasoning State (red) is the central object all other components operate on.

2.6   The boundary

The most important design decision in a reasoning architecture is not which inference engine to use. It is where to draw the language boundary. The boundary determines what is auditable, what is reproducible, and what can be held to account.

A well-drawn boundary has three properties:

• Hard. The language model cannot cross it in either direction. It receives a typed query; it returns a narrated result. It does not see the intermediate reasoning state, and it does not influence the inference.
• Typed. The objects that cross the boundary are typed artifacts, CausalQuery in, DecisionCertificate out. Not natural language. The type system is the contract between the language interface and the reasoning core.
• Certified. Nothing exits the reasoning layer without a governance artifact that records what was computed, on what evidence, under what assumptions, at what time. The certificate is the unit of accountability.

A boundary that is soft, where the language model can influence intermediate reasoning steps, is not a reasoning architecture. It is a language model with structured prompts. The difference is not cosmetic. A soft boundary produces outputs that cannot be audited, replicated, or explained independently of the model that produced them.

2.7   The interface contract

Architecture is interfaces. The separation-of-concerns table in Section 2.3 identifies the roles and their artifacts. This section specifies the typed objects that flow between them, the interface contract that makes the boundary concrete and implementable.

Every object that crosses a role boundary is a typed artifact. No natural language crosses any internal boundary. The flow is strictly typed end to end:

Two additional flows support the domain model and memory roles:

Every typed object in this contract is a governance artifact in the sense of Section 5: it carries a version, a timestamp, and enough provenance to reconstruct the reasoning that produced it. The interface contract is therefore also the governance contract. An implementation that passes typed objects between roles but does not version and timestamp them does not conform to EARA.

2.8   EARA as a reference implementation

Reader’s guide. This paper uses three levels of claim. Claims about “a reasoning architecture” describe the abstract pattern, applicable to any conforming implementation. Claims about “EARA” describe one reference implementation of that pattern. Claims about “one implementation” or “one approach” describe choices that may vary across conforming implementations. Readers should evaluate the architectural claims independently of the EARA-specific choices.

EARA is one reference architecture for the reasoning concern. It is not the only possible architecture. Any system that maintains explicit reasoning state (Definition 2.1), separates language from inference at a typed boundary, and produces certified governance artifacts is a reasoning architecture in the sense defined here.

EARA realizes these principles using specific components: a causal domain model as the knowledge representation, a probabilistic inference engine as the reasoning engine, seven cognitive primitives as the service layer, and four governance artifacts as the accountability layer. These choices are motivated in the sections that follow. They are choices, not requirements. An organization using a different inference engine, a different domain model formalism, or a different governance schema can still conform to the reasoning architecture pattern.

What cannot vary in any conforming implementation: the boundary must be hard, the reasoning state must be explicit, and the governance artifacts must be typed and versioned. Everything else is implementation.

Domain Models as Enterprise Assets

A reasoning architecture requires something to reason about. Not a corpus of documents, not a vector space of embeddings, not a set of fine-tuned weights. It requires an explicit representation of how the relevant part of the world works, which variables matter, how they influence each other, what mechanisms connect cause to effect, and under what conditions those mechanisms hold. This paper calls that representation a domain model.

This section argues three claims. First, that a domain model is a distinct kind of knowledge representation, different from a database, a document store, or a language model's parametric memory. Second, that domain models must be elicited from domain experts, not learned from data alone. Third, that an explicit, elicited domain model is a new category of enterprise asset, one that companies will own, version, and protect in the same way they own database schemas today.

3.1   What a domain model is not

Four existing knowledge representations are sometimes confused with domain models. Each addresses a different problem.

A database represents what has happened: rows, transactions, historical records. It answers observational questions about the past. It does not represent why things happened, what would happen under intervention, or what would have been true in a different world.

A vector store or document corpus represents what has been written. Retrieval-augmented generation grounds language model outputs in documents, reducing hallucination on factual questions. It does not represent causal structure. Retrieving a document about a disease does not give a system the ability to reason about what would happen if a treatment were administered.

A language model's parametric memory represents statistical patterns in text. It encodes correlations between words, phrases, and concepts at scale. It does not represent mechanisms. The distinction between correlation and causation is not detectable from token frequencies, regardless of how many tokens are trained on.

A rules engine represents explicit policy: if-then conditions that act on known facts. Rules engines are excellent at encoding what an organization has decided to do under known conditions. They do not represent uncertainty, causal structure, or the consequences of novel interventions.

A domain model addresses what none of these provide: an explicit, structured representation of the causal mechanisms that govern a domain, the variables, their relationships, the direction of influence, and the uncertainty associated with each.

3.2   What a domain model is

Before defining a domain model, it is worth distinguishing three concepts that are frequently conflated:

• An ontology defines what exists in the domain: the vocabulary of entities, variables, and relationships. It answers the question: what are the things we care about and how do we name them? An ontology has no probabilistic content and makes no causal claims.
• A domain model assigns probabilistic structure and causal relationships to an ontology: which variables influence which, with what strength, under what conditions, and with what uncertainty. It answers the question: how does the domain work? A domain model can be queried to produce beliefs about unobserved states.
• An inference engine computes over a domain model: given evidence, it produces posterior distributions, evaluates interventions, and identifies counterfactuals. It answers the question: what does the domain model imply about this situation? The inference engine consumes the domain model; it is not part of it.

This paper is concerned primarily with domain models, with what they must contain, how they must be built, and why they constitute an enterprise asset. The inference engine is an implementation choice; the domain model is an architectural requirement.

A domain model, in the sense used by this paper, supports three classes of query corresponding to Pearl’s Ladder of Causation:

• Observational queries: given what we have seen, what is the probability of this outcome? This is the question a predictive model answers.
• Interventional queries: if we take this action, what will change? This requires causal structure: a model that represents not just correlations but the mechanisms by which causes produce effects.
• Counterfactual queries: what would have happened had we acted differently? This requires the model to reason about a world that did not occur, holding specific variables fixed at their actual values while changing others.

A domain model that supports all three classes of query is a causal model. A domain model that supports only the first is a statistical model. The distinction is architectural, not merely technical: an enterprise AI system that cannot answer interventional and counterfactual questions cannot reason about decisions, only about observations.

This is why the domain model is the central component of a reasoning architecture. The reasoning state defined in Section 2, beliefs, uncertainty, causal structure, evidence, goals, constraints, can only be maintained by a system that has an explicit model of the domain. Without an explicit domain model, the reasoning state is implicit in the language model's weights, invisible, and unauditable.

3.3   Why domain models must be elicited

A natural response to the requirement for a domain model is to ask whether it can be learned from data. The answer is: partially, and the limit matters enormously.

Statistical structure, correlations, conditional probabilities, predictive relationships, can be learned from data. This is what machine learning does, and it does it well. But causal structure cannot be learned from observational data alone. Two datasets with identical observational distributions can correspond to entirely different causal structures, implying opposite responses to the same intervention.

This is not a limitation of current learning algorithms. It is a mathematical result: the causal graph that generated a dataset is not identifiable from the dataset alone without additional assumptions or experiments. Those assumptions must come from somewhere. In a reasoning architecture, they come from domain experts, the people who understand the mechanisms, not just the correlations, in the domain they work in.

The elicitation requirement follows directly: the structure of a domain model must be elicited from domain experts. Data can calibrate the parameters; it cannot supply the structure. An important corollary: the domain model encodes what your experts know. It is not a product of your data. Two organizations with identical data but different experts will produce different domain models, and should. The model reflects the causal understanding of the organization, not merely the statistical patterns in its records.

3.4   Domain models as enterprise assets

A database schema is not data. It is the structure that makes data interpretable, consistent, and governable. An organization that loses its database schema loses its ability to use its data coherently. The schema embodies decades of decisions about what matters, how it relates, and how it should be organized. It is an enterprise asset, maintained, versioned, and protected.

A domain model occupies the same position in a reasoning architecture. It is not the reasoning, it is the structure that makes reasoning possible, consistent, and governable. It embodies the domain expertise of the organization: the causal mechanisms that its experts have identified, validated, and encoded. It is the part of the system that cannot be rebuilt from data alone if it is lost.

Three practical implications follow:

• Domain models must be versioned. A domain model is a living artifact. As understanding evolves, as evidence accumulates, as the domain changes, the model must be updated. Each version must be preserved, because past decisions were made under past versions. An audit requires knowing which model was active when.
• Domain models must be governed. Changes to a domain model change the reasoning of every system that depends on it. Governance processes, review, approval, impact assessment, that apply to schema changes in a database should apply equally to domain model changes.
• Domain models represent organizational knowledge that is not in the data. When an expert leaves, their knowledge of the domain's causal mechanisms leaves with them, unless it has been encoded in a domain model. An organization that maintains explicit domain models retains causal knowledge as an enterprise asset rather than a personal possession.

Today, enterprises own data, software, and documents. The claim of this section is that they will also own reasoning models, explicit representations of causal knowledge that are reusable, versionable, and composable across applications. That is a new category of enterprise asset, and it is already being created by organizations that build reasoning architectures.

3.5   Implementation in EARA

EARA realizes the domain model requirement using causal models: Bayesian Networks, Structural Causal Models, Dynamic Bayesian Networks, and Influence Diagrams. Each supports a different combination of query types and temporal reasoning capabilities. The choice among them is a domain decision, it depends on what the domain requires, not on what the architecture mandates.

What the architecture mandates is that the domain model be explicit, elicited, versioned, and exposed through a typed interface, the Scope Card, that declares what the model covers, what evidence it accepts, what queries it supports, and what gates must pass before it is invoked. The Scope Card is the contract between the domain model and the reasoning layer. It is specified in Section 5 as a governance artifact.

Other inference frameworks, probabilistic programming languages, knowledge graphs with reasoning engines, symbolic AI systems, can serve as the domain model in a conforming reasoning architecture, provided they support the required query classes and expose a typed interface. EARA does not mandate the inference technology. It mandates the role.

Cognitive Primitives

A reasoning architecture that only performs inference, computing posteriors over a domain model, is necessary but not sufficient for enterprise reasoning. Enterprise decisions require more than a number. They require explanation of what drove the number, inquiry about what would change it, monitoring of whether the model is still valid, optimization of what to do about it, scenario analysis of what might happen, robustness checking of how fragile the conclusion is, and learning from what actually happened.

These are distinct cognitive functions. Each answers a different class of question. Each operates on the reasoning state through a different combination of operations over the domain model. Each produces a distinct typed artifact. Together they constitute the cognitive service layer of a reasoning architecture.

This section specifies seven cognitive primitives. Each is defined using the same six-question template: responsibility, input, output, artifacts produced, guarantees provided, and realization in EARA. This structure is deliberate: it allows the primitives to be specified, implemented, tested, and cited independently of one another.

Cognitive primitives are the irreducible operations that any reasoning system must be able to perform, the atoms from which more complex inference is composed. In EARA's framing they map directly onto Pearl's three rungs: Association (Rung 1) detects that X and Y move together in data. Intervention (Rung 2) predicts the effect of forcing X to a value. Counterfactual (Rung 3) reasons about what would have happened under a different history. None reduces to the others.

The practical implication is concrete: when a client asks "what would have happened if we hadn't launched that campaign," that is a Rung 3 query. An LLM alone will confabulate an answer. EARA routes it to the structural model and returns a defensible one.

A cognitive primitive is a deterministic function that operates on explicit reasoning state and produces a typed artifact. The language model phrases the question and narrates the result; it does not perform the computation.

4.1   Explain

Why does the model believe this?

4.2   Inquire

What should I learn next?

4.3   Monitor

Is the model still a good description of reality?

4.4   Optimize

What is the best action under my constraints?

4.5   Scenario

What would happen in each possible future?

4.6   Robustness

How fragile is this conclusion?

4.7   Learn

What should the model believe differently?

4.8   Composition and the reasoning loop

The seven primitives are not alternatives, they compose. A typical enterprise reasoning episode invokes several in sequence:

Monitor runs continuously alongside this loop, not as a step within it. Learn runs periodically, after episodes have accumulated, not during a single reasoning episode. Scenario is invoked when planning rather than deciding, before the evidence arrives rather than after.

The primitives share one reasoning state and one domain model. They do not maintain separate representations of the domain. This is what makes the system coherent: every primitive's output is consistent with every other's, because they all operate on the same underlying probabilistic structure.

Governance Artifacts

Governance artifacts are typed, versioned, reproducible objects that record every step of the reasoning pipeline and constitute the evidentiary basis for every recommendation. They are not logs: a log records what happened as a side effect; a governance artifact certifies what was computed as a required output of the interface contract defined in Section 2.7.

This section specifies four governance artifacts. Each is defined using the same template applied to the cognitive primitives in Section 4: responsibility, what it records, when it is produced, who produces it, guarantees it provides, and its schema in EARA.

5.1   The artifact lifecycle

Governance artifacts form a directed chain. Each artifact is a prerequisite for the next. Nothing proceeds without a certificate; nothing is issued without a traceable predecessor.

The chain is gated. If the Identification Certificate is a refusal, the pipeline halts and returns bounds or an explicit statement of non-identification, never a fabricated point estimate. The Decision Certificate cannot be issued without a valid Identification Certificate. The Audit Record is generated unconditionally: it records both successful reasoning and refused queries.

5.2   Scope Card

What does this domain model cover, and under what conditions may it be used?

5.3   Identification Certificate

Is this query identified, and if not, why not?

5.4   Decision Certificate

What did the system conclude, and what is the full basis for that conclusion?

5.5   Audit Record

What happened in this pipeline, in what order, and could it be reproduced?

5.6   Why artifacts are not logs

The distinction between governance artifacts and logs deserves one more paragraph, because it is the distinction that makes EARA's governance claims defensible rather than aspirational.

A log is a record of what happened, produced as a side effect of computation. It is not part of the architecture's interface contract. Its format is typically implementation-specific, its contents are determined by what the developer chose to record, and its relationship to the computation it describes is informal.

A governance artifact is a typed output of a defined interface, produced as a required step in the pipeline, with a schema that is part of the architecture specification. Its existence is guaranteed by the architecture, not by the diligence of the implementor. Its format is standardized across implementations. Its contents are sufficient to reconstruct the reasoning that produced it.

This is why a conforming EARA implementation cannot omit the Identification Certificate, cannot issue a Decision Certificate without one, and cannot finalize an episode without an Audit Record. These are not optional compliance features. They are structural outputs of the interface contract defined in Section 2.6. An implementation that does not produce them does not conform to EARA, regardless of how sophisticated its inference engine is.

What It Looks Like in Practice

The architecture described in Sections 2–5 is abstract by design. This section shows what it looks like when instantiated in three enterprise domains: clinical decision support, security operations, and financial credit assessment. These are illustrative scenarios, they demonstrate the architecture, not a specific deployment.

The scenarios share one observation: the architecture is identical across all three. Only the domain model changes. This is the practical consequence of the separation of concerns established in Section 2.3: the domain model is domain-specific; every other component is reused without modification.

6.1   Clinical decision support, sepsis triage

Domain: Emergency medicine. Decision: Does this patient have sepsis, and if so, what is the treatment priority?

The domain model encodes the clinical mechanisms of sepsis progression: the relationships between infection source, immune response, organ function, and mortality risk. It was elicited from intensivists and emergency physicians, not learned from EHR data. It represents what clinicians know about causation, which findings are diagnostic, which interventions change the trajectory, what would have happened without treatment, not merely what correlates with sepsis in historical records.

The episode: A clinician dictates notes. The language interface extracts structured evidence: temperature, lactate, white cell count, blood pressure, clinical impression ("looks septic"). Hard observations (lab values) and soft evidence (clinical impression, P(SepticAppearance) = 0.76) enter the domain model together. Bayesian updating propagates both through the network.

The primitives invoked:

• Explain: pattern analysis identifies the findings that most distinguish sepsis from competing diagnoses (bacteremia without organ dysfunction, severe dehydration). Impact analysis attributes the posterior shift to specific observations: lactate and hypotension carried the call; temperature barely registered.
• Inquire: VoI ranks available tests. Blood culture is more definitive in the abstract; procalcitonin is ranked first here because its result would most likely move the posterior across the treatment threshold before the four-hour window closes.
• Optimize: given the posterior and a constraint set (allergy history, available antibiotics, unit protocol), the optimizer returns: blood culture now, lactate repeat in two hours, broad-spectrum antibiotics within one hour. CT rejected, would not change tonight's decision.
• Robustness: retracted analysis: remove the lactate value and the posterior falls from 0.81 to 0.61. The clinician is told: this call leans on the lactate. If the result is revised, re-infer.

The output: The DecisionCertificate records posterior = 0.81, recommended action = immediate antibiotics + fluid resuscitation, pattern explanation = lactate + hypotension, VoI = procalcitonin next. The language interface narrates: "Sepsis probability 81%. The lactate and hypotension are the primary drivers. Recommend immediate broad-spectrum antibiotics and fluid resuscitation under protocol SEP-3. Procalcitonin would most reduce remaining uncertainty, order now if available." The AuditRecord is filed; the episode is linked to the patient record.

6.2   Security operations, intrusion detection

Domain: Enterprise cybersecurity. Decision: Is this account compromised, and what action should the SOC take?

The domain model encodes the kill chain: the causal progression from initial access through credential theft, privilege escalation, lateral movement, and data exfiltration. It was elicited from security architects and threat intelligence analysts. Each stage has a prior probability of occurrence and a conditional probability given the preceding stage. The model reasons about attack state as a hidden variable, inferred from observable telemetry, not directly observed.

The episode: Raw telemetry arrives: a login from an unusual geography, a privileged PowerShell execution twelve minutes later, a 4GB upload to external storage eight minutes after that. The language interface normalises unstructured log entries into typed evidence. The domain model updates: P(Compromise) rises from 0.12 to 0.93 as the kill chain pattern accumulates. No single event triggered this, the posterior reflects the chain, not the individual events.

The primitives invoked:

• Monitor: the account's behavioral likelihood trace collapses. This is not a rare event under an intact model; it is a structural break. The MonitoringCertificate flags drift, not anomaly.
• Explain: the impossible-travel login and the privileged execution carry the posterior. The data upload confirms it but does not drive it, the call was already at 0.89 before the upload.
• Optimize: under policy CYB-12 (disable at P > 0.90), the optimizer confirms: disable account, notify SOC, preserve memory image for forensics. These actions are evaluated as interventions, their expected effects on evidence preservation and attacker capability are computed, not assumed.

The output: "Probability of compromise: 0.93. Evidence most consistent with credential theft followed by privilege escalation. Primary drivers: impossible-travel authentication and privileged PowerShell execution. Under policy CYB-12, disabling the account and notifying the SOC is recommended. This recommendation is grounded in Identification Certificate IC-2026-0417." The AuditRecord provides the complete pipeline trace, reproducible by an independent reviewer from the same evidence and model version.

6.3   Financial credit, SME lending

Domain: Commercial lending. Decision: Should this credit application be approved, under what conditions, and what is the basis for the decision?

The domain model encodes the causal mechanisms of SME credit risk: the relationships between business financials, sector exposure, management quality, macroeconomic conditions, and probability of default. Critically, it models interventions, the effect of a personal guarantee, a covenant, a reduced facility, not just correlations with historical default rates. It was elicited from credit officers with domain knowledge of the causal mechanisms, not learned from a loan tape alone.

The episode: A loan application arrives. Financial statements are parsed; the language interface extracts structured evidence. Soft evidence enters for qualitative factors: management assessment ("strong but untested at this scale," P(ManagementQuality = High) = 0.65). The posterior over default probability is computed.

The primitives invoked:

• Scenario: three economic scenarios are evaluated simultaneously: base, stress, severe stress. The covenant structure is tested across all three. In the severe stress scenario, the debt service coverage ratio breaches the covenant seven times in ten. This is flagged before the decision is made, not discovered in the first covenant review.
• Optimize: given the applicant's risk profile and the bank's risk appetite, the optimizer returns: approve at 80% of requested facility, require personal guarantee, include DSCR covenant at 1.25x. The rejected alternatives, full facility without covenant, decline, are documented with reasons.
• Explain: the sector exposure and the untested management at scale carry the risk. The personal guarantee changes the intervention distribution significantly.

The output: The DecisionCertificate records the recommended terms, the posterior over default under each scenario, the pattern explanation, and the policy rule that authorized the decision. The language interface produces a credit memo in plain language: recommendation, basis, conditions, rejected alternatives, and assumptions. The AuditRecord satisfies regulatory requirements for explainability and is available for supervisory review without reconstruction.

6.4   One architecture, three domain models

The three scenarios share every architectural component except the domain model. The language interface, the reasoning engine, the seven cognitive primitives, the four governance artifacts, and the policy layer are identical. The domain models differ in their variables, their causal structures, their evidence types, and their Scope Cards, but not in their role in the architecture.

This is the practical meaning of a reference architecture. It does not prescribe a deployment. It specifies the pattern that a deployment must follow. An organization that builds a credit risk domain model and a fraud detection domain model can run both through the same reasoning architecture, with the same governance artifacts, under the same audit framework. The architecture provides the substrate; the domain model provides the domain knowledge.

The component table from Section 2.3, instantiated across the three scenarios, confirms that every role is filled in every domain by the same component serving the same concern. The only variation is in the Scope Card that declares what each domain model covers.

The Future

Every major architectural advance in enterprise software followed the same sequence. First, a capability became important enough that its absence was felt as a liability. Then, a vocabulary emerged for describing what was missing. Then, reference architectures appeared that specified how to address it. Then, implementations multiplied and the pattern became the standard.

Data management followed this sequence. So did identity. So did messaging and observability. Enterprise AI reasoning is following it now.

7.1   Reasoning architectures as a new class of enterprise software

The claim of this paper is not that EARA is the only possible reasoning architecture. It is that reasoning architectures, as a class, are becoming a necessary component of enterprise AI. The capability is becoming important enough; the absence is being felt as a liability in the domains where AI decisions have consequences: healthcare, finance, security, infrastructure, compliance.

Enterprise AI is at the vocabulary stage. The terms, reasoning state, domain model, cognitive primitive, identification certificate, decision certificate, are not yet standard. This paper proposes them. Whether these specific terms persist matters less than whether the architectural concerns they name become first-class requirements in enterprise AI deployments.

7.2   The enterprise reasoning substrate

The claim is that enterprise applications should not manage their own reasoning, either. They should call a reasoning substrate that owns the reasoning state, maintains the domain model, invokes the cognitive primitives, produces the governance artifacts, and applies the policy. The application is a consumer of reasoning, not a provider of it.

This is not a prediction about when this will happen or which technology will provide it. It is an architectural observation about where the concern belongs. Whether the substrate is built on Bayesian networks, probabilistic programming, neuro-symbolic systems, or a formalism not yet named, the separation of concerns defined in this paper holds. The application layer calls the reasoning layer. The reasoning layer returns certified results. The governance layer records everything.

7.3   The conformance question

A reference architecture becomes a standard when it can answer one question precisely: what does it mean for an implementation to conform?

This paper has specified three non-negotiable requirements. An implementation conforms to EARA if and only if:

• The boundary is hard. No natural language crosses into the reasoning core. No inference result is produced by the language model. The language interface is confined to parsing and narration.
• The reasoning state is explicit. The implementation maintains a computational object that holds beliefs, uncertainty, causal structure, evidence, goals, constraints, candidate actions, and assumptions, and that object is the input to every cognitive primitive and the basis of every governance artifact.
• The governance artifacts are typed and versioned. Every reasoning episode produces a Scope Card, an Identification Certificate, a Decision Certificate, and an Audit Record in the schemas defined in Section 5. Refused queries produce an Identification Certificate with identified = false and an Audit Record. No certificate is issued without its predecessor.

Everything else, the domain model formalism, the inference engine, the cognitive primitive implementations, the policy rules, is implementation. A conforming implementation can use any technology that satisfies these three requirements.

A full conformance specification, defining the schemas precisely, specifying the interface contracts formally, and providing compliance tests, is the natural next step for EARA. This paper proposes the architecture. The specification will define what it means to build it.

7.4   The enduring claim

The central claim of this paper does not depend on the future capabilities of any specific AI technology. It does not depend on whether language models become more capable. It does not depend on whether Bayesian networks remain the dominant domain model formalism. It does not depend on any particular vendor, platform, or implementation.

The claim is architectural: enterprise AI will mature when reasoning is treated as a first-class architectural concern, with its own representations, services, interfaces, artifacts, and governance, and when language is restored to its proper role as the interface to that reasoning, not the reasoning itself.

That principle outlasts any particular implementation. It is the principle this paper has argued, specified, and illustrated. The architecture described here is one realization of it. Others are possible. The principle is not.