The AI hallucinations that make headlines are the lurid ones: the invented court case, the confident biography of a person who does not exist. Those failures are embarrassing and easy to catch because they are wrong in ways a human recognises on sight.
The hallucination that damages an enterprise system is quieter and almost nobody notices it.
An agent invents a field that sounds plausible. It assumes a relationship that holds in every system like yours but not in yours. It reads a business rule written as a firm constraint and handles it as a suggestion. It sees a customer_status field and infers, reasonably and wrongly, what the values mean.
None of this looks like hallucination. Every one of these outputs is fluent, well-formed and consistent with the documents the agent was given. Each would pass a casual review.
That is exactly the problem: the agent is not failing to reason. It is reasoning correctly over a description of the domain that is stale, partial or simply not the domain.
In the first essay in this series, I argued that agents commit before they can be corrected, and that reliability therefore has to come from the quality of what the agent commits against. This essay is about what that thing has to be: not a better prompt, not a larger document base and not a more elaborate retrieval layer, but a live world model at the commitment boundary.
A live model is not a better description of the business. It is the governed model the system can query, enforce, observe and correct while work is actually happening.
GroundingThe description is not the domain
A human operator builds a domain model over years, corrected by colleagues, by practice and by consequence.
An agent has whatever it was handed: schemas, documentation, prompts, retrieved text. That is not the domain. It is a set of descriptions of the domain, written at different times, by different people, for different purposes, with no reliable marker distinguishing the ones that are still true.
The standard remedy is retrieval augmented generation (RAG): connect the agent to the document base, and the descriptions at least become plentiful.
RAG genuinely helps. It is also not enough.
Documents go stale, and staleness is invisible: a two-year-old design note and yesterday's incident report can look equally authoritative to RAG. Documents contradict each other. They mix current fact with aspiration. Much of the enterprise corpus describes the system somebody intended to build. No document can push back.
RAG answers the question: what did we write down about this?
The question the agent actually needs answered at the moment of commitment is different: what is true, here, now?
A pile of descriptions, however well ranked, cannot answer that by itself, because the answer is not reliably in any one of them. The fix is not more documents, and it is not better retrieval over the same documents. It is a live domain model: typed, queryable, authoritative and, most importantly, close enough to the systems of action that the platform can enforce it.
Not one universal model of the whole enterprise. That is the trap, and it is precisely the ambition that killed the canonical models. What matters is the governed model at the commitment boundary: the thing the agent must act against, and the thing the platform can refuse to violate. Commitment boundaries arrive one path at a time. You do not model the business before you begin; you govern the first path an agent touches, then the next. Each governed path stands on its own.
The graveyardThe objection that deserves an answer
At this point, every experienced enterprise architect is entitled to interrupt.
We have heard this before. The enterprise ontology. The canonical data model. Master data management. The SOA service registry. Every generation of enterprise architecture has produced some version of the authoritative shared model, and every version has ended the same way: magnificent at the kick-off, stale within a year, quietly routed around within two, and eventually maintained only by the team whose job depended on pretending otherwise.
The graveyard is real, and any argument for a live domain model that does not engage with it is not a serious argument. It even contains the tools that promised exactly what I am describing: the CASE generation kept the model and the running code as two artefacts with a synchroniser between them, and the synchroniser is where the promise died.
Let me engage with it directly, because I think the graveyard teaches a precise lesson. It is not the lesson usually drawn.
Those systems did not fail because modelling the enterprise is impossible. Most of them were substantially right on the day they shipped. They failed in maintenance. The world moved, the model did not and this is the crucial part: nothing in the architecture could tell anyone how far apart the two had drifted.
Divergence was invisible until it surfaced as an incident or an integration failure; people stopped trusting the model, stopped updating it, and the spiral only ends one way.
The lesson is not "don't build the model." Build the model as part of the live state the system executes against, so that the enforced model and the executing software are no longer separate artefacts trying to stay synchronised.
The old canonical models failed because they were treated as documentation to be completed, not systems to be continuously corrected. They also floated: a model with no enforcement consequence pays no price for vagueness, so it rises to the level of abstraction where nobody can disagree, which is also the level where nobody can use it. A model the system actually executes against cannot afford that: vagueness admits garbage today, and precision pays off today. Enforcement disciplines abstraction: a definition that must decide real cases cannot afford to be vague, and a definition nobody enforces can afford nothing else.
One distinction is worth making precise here, because everything that follows depends on it. In the governed path, a live model cannot drift from the system it governs, because the definitions being enforced are part of the running state rather than a description held beside it. "The model says a field exists but it doesn't" is a sentence that cannot be constructed inside that governed path. What the model can drift from is the business the system serves. No model of a living enterprise is ever finished, and none is ever fully right. Drift between the model and the world is not a defect to be prevented. It is guaranteed, structurally, for as long as the enterprise keeps changing.
The design question is therefore not: how do we build the correct model?
It is: how does the model notice, localise and repair its own divergence?
A model built to be correct rots the moment its authors look away. A model built to be correctable gets better every time it is caught being wrong.
The disciplineCorrect versus correctable
Three properties. They are requirements, not aspirations.
First, divergence has to be observable: a measured quantity, not a boolean discovered during an outage. If the system cannot answer "how far has this definition drifted from the behaviour it governs?" with a number and a trend, then drift is being managed by anecdote.
Second, divergence has to be localisable. "The model is stale" is useless. "This definition's boundary moved, and here is the case that crossed it" is actionable.
The awkward cases matter most. A schema tells you what a Customer record looks like; a boundary case such as "a trial account is not a Customer" tells you what a Customer actually is. Facts like that are exactly what silently change when a business pivots. A live model keeps its boundary cases as executable data, so when sales quietly starts treating trial accounts as paying customers, the change surfaces as a finding against a named example rather than as a broken automation at month end.
Together, the first two properties amount to something the monitoring industry does not yet sell: semantic observability. Every dashboard in your estate watches what the system does. Nothing watches what it means.
Third, divergence has to be repairable through the front door.
Changes to the model must travel the same governed, evidenced path as changes to the data the model governs: proposed, validated, admitted and traceable. Repairs must be additions to history, not edits of it: a model that can be corrected must be able to remember being wrong, because the record of its past mistakes is exactly what makes its present claims worth trusting. The moment fixing the model is harder than routing around it, the graveyard spiral begins.
This applies with special force to the model's own machinery. In our own build, the most instructive early findings were cases where the governance layer caught defects in its own definitions and fixtures.
That is not the mechanism embarrassing itself. That is the mechanism working.
A model that can be caught being wrong about itself is the only kind that stays worth trusting about anything else.
Notice what this reframing does to the hallucination problem we started with. An agent hallucinates domain facts when the gap between description and domain is invisible. A correctable model is one where that gap is measured, attributed and closed as routine operation.
The agent still reasons over a description; everything does. The difference is that this description's distance from reality is monitored rather than taken on faith.
The substrateWhat this asks of the substrate
The consequences are concrete.
Definitions must constrain, not merely describe. A type with no laws is a labelled hole, and an agent will fill a labelled hole with something plausible.
They must also constrain in one place. Every enterprise system I have ever opened contains the same rule implemented five times: in the form, in the API, in the ORM, in a stored procedure and in the integration layer, written by different teams in different years, agreeing on the happy path and quietly disagreeing at every edge. That is not defence in depth. It is the same check re-guessed five ways, and the variance between the guesses is a bug class of its own. A live model is enforced once, at the boundary everything must cross.
The examples, and more importantly the counterexamples, must be executable. Conformance has to be something the system runs, not something a committee remembers.
Every change to the model must be a governed operation with evidence attached, because a model changed by side channels is a model whose history nobody can trust.
Finally, divergence must surface as findings with owners, not as incidents with victims.
There is one more objection waiting, and it is the other headstone in the graveyard: who is going to author and maintain all of this?
Hand-maintaining a rich model of a large enterprise has never been economically viable, and no amount of architectural virtue changes that. The short answer is that agents can propose candidate structure; only governed admission can make it part of the model. That changes the economics without weakening accountability. The full version of that argument deserves its own essay, and will get one later in the series.
The corollaryThe model you commit against
The first essay ended with a claim: the throw (the action, once committed) is only as good as the model you commit against.
This essay adds the corollary that the graveyard spent thirty years teaching us.
The model you commit against is only solid if someone, or something, is allowed to notice when it stops being true. Not eventually, in a post-incident review, but continuously, as a property of the substrate.
Agent safety does not require a perfect enterprise model. It requires a governed model that can notice, localise and repair its own drift before agents commit against fiction.
That, in the end, is what it takes to close the Agentic Commitment Gap: not agents that never err, but a substrate that keeps the distance between description and domain measured, attributed and repairable at the moment of commitment.
Correctness is a snapshot. Correctability is a discipline.
Between the two, only one survives contact with a living enterprise.
The next build post in this series will show what such a model looks like from the inside: a single definition, its laws, its boundary cases and (the part no schema diagram has ever shown) what happens when an agent tries to cross a boundary and the system explains, precisely and repairably, why it refused.
Mark Norman has spent thirty years building production systems across robotics, safety-critical infrastructure, financial systems and enterprise AI, with an earlier research background in biological motor control. He is the founder of FluidIntent, building the substrate this series describes. This is the third essay in the series; the first, "Agents Commit Before They Can Be Corrected," sets out the full argument.