While AI Chased the Latest Model, We Spent Two Years Building the Business Graph
For the past two years, at HASH by 2202, we have been doing something that, until very recently, sounded far less exciting than building another AI agent.
We have been quietly constructing enterprise ontologies for SAP and Oracle environments.
While much of the AI industry moved from one obsession to the next—larger models, RAG, vector databases, copilots, fine-tuning, agents, reasoning models, MCP and whatever came after—we kept returning to a much more basic question:
What exactly does the business mean? What is a customer? What is available inventory? What constitutes revenue? Which price is the relevant price? When is a sale economically complete? What relationship connects an invoice to a customer, a salesperson, a route, a warehouse, a product, a discount, a cost, a receivable and ultimately cash? Who is allowed to see each of those things? And if Finance, Sales and Operations give three different answers, which definition is authoritative?
Those questions are much less glamorous than model benchmarks. They are also the questions that determine whether enterprise AI actually works.
The model was never the whole problem
Large language models have improved at an extraordinary pace. That matters.
But enterprises are discovering that intelligence without institutional context has a surprisingly low ceiling.
An LLM can write beautiful SQL against the wrong field. An agent can calculate margin perfectly using the wrong definition of revenue.
It can identify a product correctly while misunderstanding whether the quantity represents units, boxes or pallets.
It can recommend purchasing additional inventory without realizing that existing inventory is committed, in transit, expired, reserved or sitting in the wrong warehouse.
It can reconcile transactions continuously, detect anomalies and explain variances in seconds—but only if the context underneath those transactions is trustworthy.
Finance still needs to know exactly what every customer, product, account, invoice, discount, inventory position and business metric means.
And those definitions need to remain consistent across systems. That is why we came to a conclusion relatively early at HASH:
AI readiness begins before the model.
It begins with reconstructing the business in a form machines can understand.
SAP and Oracle contain the transactions. They do not automatically contain the business.
Enterprise systems such as SAP S/4HANA and Oracle NetSuite are extraordinary systems of record.
They can contain decades of transactions, configurations, custom fields, pricing rules, material hierarchies, accounting structures, customers, suppliers, warehouses, purchasing activity and operational history.
But an enterprise does not operate as a collection of tables.
It operates as a network of entities, relationships, rules, definitions, permissions and decisions.
A customer belongs to a segment. It may be assigned to a salesperson and route. It receives particular credit conditions and pricing. It buys specific products. Those purchases become invoices. Invoices become receivables. Receivables eventually become cash—or do not.
A product belongs to a brand, category and packaging structure. It may be purchased from several suppliers, held across warehouses, tracked by lot and expiration date, sold using different units of measure and generate radically different economics depending on customer, channel, promotion and geography.
The ERP records pieces of this reality.
The ontology reconstructs the relationships that make those pieces meaningful.
That distinction became especially obvious in one recent HASH implementation involving a migration from Microsoft Dynamics to Oracle NetSuite. The data had moved, yet portions of its business meaning had become difficult to reconstruct. Internal identifiers had to be mapped back to commercially recognizable customer codes; quantities needed their operational meaning restored; and financial, inventory and sales records needed to be reorganized into business domains rather than simply replicated from the ERP schema.
The lesson was simple:
You can migrate the data without migrating the business.
The ontology is the missing layer
The word ontology can sound academic, but the idea is straightforward.
An enterprise ontology describes the things a company cares about, what they mean, how they relate to each other and what rules govern them.
Customer; Product; Supplier; Invoice; Warehouse; Lot; Account; Contract; Risk; Price; Margin; Inventory; Cash; and then the relationships between them.
A semantic layer adds governed definitions for the metrics and dimensions through which the business measures itself.
Together, they convert institutional knowledge into machine-readable business context.
This is the difference between giving an AI agent access to tables and giving it an understanding of the organization those tables represent.
Without that layer, the agent is primarily querying databases faster.
With it, the agent can begin to reason about the business.
That distinction is going to matter enormously.
AI requires three graphs
One way we increasingly think about enterprise AI is through what might be called
There is a graph of weights: the statistical relationships learned by the model.
There is a graph of doing: the workflows, tools, actions and decisions through which an agent interacts with the world.
And there is a graph of knowing: the customers, products, policies, contracts, risks, evidence, metrics and relationships that describe the enterprise itself.
The AI industry has invested astonishing amounts of capital into the graph of weights.
Agentic systems are now rapidly developing the graph of doing.
But enterprises still have to construct the graph of knowing.
That is where ontology becomes fundamental.
A model might know what an invoice is in the abstract.
It does not automatically know what your company considers a valid invoice, which documents supersede others, which discounts apply, what revenue recognition logic Finance has approved, which business unit owns the transaction, which customer hierarchy should be used or whether a particular employee is authorized to see it.
Those facts do not live inside the model’s weights.
They live inside the institution.
Someone has to engineer them.
This is why we spent two years doing the boring work
When foundation models were improving every few months, it would have been easy to chase the same layer as everyone else.
We deliberately went lower in the stack.
We spent time understanding SAP and Oracle structures, customizations, master data, transaction flows, relationships, business definitions and all the small inconsistencies that make enterprise systems extraordinarily difficult to reason over reliably.
Because those small inconsistencies are not small once AI enters the picture.
An ambiguous column that previously created a reconciliation problem for an analyst can now cause an autonomous system to make thousands of incorrect decisions.
A missing unit of measure can propagate through inventory planning.
Two definitions of margin can cause Finance and Sales agents to recommend contradictory actions.
An incorrect customer mapping can affect credit analysis, commercial reporting, pricing and collections simultaneously.
This is why data quality has to become observable.
Not simply:
“The report doesn’t reconcile.”
But:
Which column is wrong?
Which records are affected?
Which business rule was violated?
Where did the inconsistency originate?
Which downstream processes depend on it?
Who owns the correction?
In the NetSuite implementation we recently described, HASH reorganized ERP complexity into 12 business domains and surfaced 176 active data-quality alerts involving issues such as duplicates, missing fields and absent units of measure. Instead of treating data quality as a periodic cleanup exercise, those problems became visible operational objects that could be investigated, assigned and resolved.
That is not merely better data engineering.
It is part of the control system required for reliable AI.
One metric should mean one thing
The same problem exists with metrics.
Ask Finance, Sales and Operations for revenue, margin, active customers, available inventory or service level and many enterprises will quietly produce several different calculations.
That was tolerable when humans mediated every decision.
It becomes dangerous when software agents begin acting autonomously.
An enterprise cannot have three AI agents optimizing three different definitions of the same economic reality.
This is why HASH treats governed metrics as part of the ontology.
A metric needs an approved definition, source data, calculation logic, lineage, ownership and permissions.
In the implementation above, this led to a centralized metric library designed to prevent different functions from independently calculating ostensibly identical indicators using incompatible rules.
Once that exists, an AI system does not have to invent what “gross margin” means.
It resolves the approved definition.
That sounds almost trivial.
It is one of the most important architectural changes required for enterprise AI.
The LLM should not be the governance layer
This also changes how we think enterprise AI should be deployed.
In regulated or financially sensitive environments, the model should not be handed credentials and invited to explore the corporate database.
Governance should sit outside the LLM.
Identity should be resolved first.
Permissions should be enforced before retrieval.
The ontology should determine which entities, relationships and definitions apply.
Existing deterministic queries should be preferred when they already answer the question.
New SQL should be generated only when necessary and then validated before execution.
Results should be checked for integrity, units, definitions, freshness and reconciliation.
Only after that should an approved model be asked to explain, summarize or visualize what has already been established.
The model is enormously useful.
But it should operate inside a governed system, rather than being expected to govern itself.
At HASH, this is why we think about the architecture as separation of responsibilities: HASH governs meaning, permissions, definitions, metrics, SQL generation and validation; the analytical engine executes approved computation; and the inference layer runs the authorized model and version.
The probabilistic component does what it is exceptionally good at.
The deterministic components constrain the things that should never be probabilistic in the first place.
Hallucination is often an architecture problem
This leads to a subtle but important point.
When an enterprise AI system produces an incorrect numerical answer, people often describe it as an LLM hallucination.
Sometimes it is.
But frequently the failure began much earlier.
The model queried an ambiguous dataset.
The customer hierarchy was inconsistent.
The semantic definition was missing.
The historical snapshot had changed.
The permission boundaries were unclear.
The unit conversion was wrong.
The SQL was never validated.
Or two departments had been using different definitions for years and nobody had forced the company to decide which one was authoritative.
Calling all of this “hallucination” can obscure the actual problem.
Enterprise AI reliability is primarily an architecture, governance and context problem.
The goal should not merely be for the AI to usually produce the correct answer.
The system should be capable of demonstrating where the answer came from.
Every important numerical response should be reproducible through a canonical trace linking the user, permissions, ontology version, metric definition, SQL, data snapshot, model version, data-quality state, warnings and final output.
And if the system cannot establish that the narrative is faithful to the underlying evidence, it should regenerate the answer, qualify it or refuse to answer.
That is a very different standard from a chatbot.
It is closer to building institutional machinery.
The irony of the AI cycle
For the past several years, the easiest thing to sell in AI has been whatever sits closest to the model.
The newest model.
The newest wrapper.
The newest agent framework.
The newest orchestration protocol.
Many of those technologies are genuinely useful, and the models will continue to become more capable.
But models are also becoming increasingly interchangeable.
Enterprise context is not.
Your customer relationships are proprietary.
Your product hierarchy is proprietary.
Your pricing logic is proprietary.
Your operational history is proprietary.
Your credit policies, inventory rules, commercial relationships, financial definitions and accumulated institutional knowledge are proprietary.
That is the part no foundation-model provider can train for you.
It has to be extracted from the organization and turned into infrastructure.
In other words, the durable moat in enterprise AI may not ultimately be the model.
It may be the machine-readable representation of the enterprise itself.
From system of record to system of reasoning
SAP and Oracle will remain enormously important because enterprises still need systems of record.
But the next layer of enterprise infrastructure must answer a different set of questions.
Not merely:
What happened?
But:
Why did it happen?
What is connected to it?
Can I trust the data?
Which definition applies?
Who is allowed to know?
What should happen next?
That requires moving from records to relationships, from schemas to semantics, from dashboards to decisions and eventually from systems of record to systems of reasoning.
This is what we have actually been building at HASH for the past two years.
Not another chatbot.
Not another model wrapper.
A governed representation of the business that machines can safely reason over.
The AI industry spent the last several years making models astonishingly intelligent.
The next challenge is giving those models something equally important:
a trustworthy understanding of the business they are being asked to run.