Why ontology matters when AI has to investigate, not just analyze.
Enterprises are putting enormous effort into making data ready for AI—integrating systems, improving data quality, defining business terms, and building semantic layers.
All of that matters. But access to business data is not the same as understanding the business.
ERP records orders and revenue. Planning systems hold demand and supply plans. MES captures production. WMS tracks inventory. These systems tell AI what was recorded.
They do not necessarily tell AI what exists in the business, what those things mean, or how they relate to one another.
That distinction matters when AI has to do more than answer a question. It has to investigate a problem.
Business data tells AI what was recorded. An ontology tells AI what exists, what it means, and how it is connected.
We Have Been Modeling Business Knowledge for a Long Time
Ontology may sound like a new idea. The underlying problem is not.
Consultants and business experts have spent decades taking knowledge that lives in people’s heads and making it explicit. Two familiar tools are the decision tree and the value driver tree.
A decision tree captures how an expert makes a decision.
Consider aging inventory. An experienced planner may evaluate its condition and economics, determine whether normal sales are still viable, consider a markdown or an alternative channel, and eventually decide whether disposal is the better option.
The value of the tree is not sophistication. It is clarity. Tacit judgment becomes an explicit decision path.
A value driver tree captures a different kind of knowledge: what drives a business outcome.
Profit is the obvious example. It can be decomposed into revenue and cost; revenue into price and volume; cost into materials, manufacturing, logistics, and other drivers. The tree makes visible how value is created, diluted, or destroyed.
Neither tool becomes obsolete because ontology exists.
They solve different problems.

A Decision Tree Tells AI How to Decide. An Ontology Tells It Where to Look.
Trees are effective because they are selective.
A value driver tree usually organizes its connections around contribution or decomposition: what drives what. A decision tree uses a consistent logic of conditions and subsequent judgment. By excluding relationships that are irrelevant to the question at hand, a tree makes the problem easier to understand.
The relationships that do not serve that particular question remain outside the tree.
Suppose a decision tree for excess inventory reaches the following question:
Is MOQ causing the problem?
That is useful reasoning knowledge. It tells AI what to investigate next.
But it does not tell AI which MOQ to inspect.
In a real business, there is no abstract “MOQ” floating by itself. There is a specific MOQ attached to a specific purchasing agreement for a specific SKU, negotiated with a specific supplier. The same agreement may include a minimum annual commitment, an expiration date, and other commercial conditions.
Meanwhile, the same SKU is sitting in a particular distribution center. Some of that inventory may already be committed to customer orders.
This is where ontology plays a different role.
The decision tree tells AI what question comes next. The ontology tells AI what business knowledge that question refers to, including the relevant objects, relationships, rules, and definitions.
The two are complementary.
One SKU, Several Relationships
A small fragment might look like this:
SKU_A ── supplied_under ──> Contract_102 SKU_A ── stocked_at ──────> Seoul_DC SKU_A ── committed_to ────> Customer_Order_88 Contract_102 ── contracted_with ──> Supplier_X Contract_102 [ moq = 20 pallets, expires = 2026-12-31 ]The same SKU participates in several different relationships.
If the decision tree says, “Check whether MOQ is causing excess inventory,” AI can follow supplied_under to the actual contract and inspect its terms. It can identify not only that MOQ may be high, but which agreement created that condition and when the agreement expires.
If the question becomes, “Can this inventory be rebalanced?” AI can follow stocked_at and examine inventory elsewhere in the network.
If it needs to determine how much stock is truly available, it can follow committed_to and account for existing customer commitments.
When decision logic is represented as part of, or linked to, the ontology, it can be grounded in the actual business objects, rules, and evidence involved in the decision.
A decision tree tells AI how to reason through a known decision. An ontology tells AI where to look as that reasoning moves across the business.
Value Driver Trees Connect in Much the Same Way
The same principle applies to value driver trees.
A good inventory driver tree might explain inventory through demand variability, lead time, MOQ, and safety-stock policy. It shows what can push inventory higher and where management intervention may have an effect.
Once an investigation begins, however, those abstract drivers must resolve to specific business objects: the contract and SKU behind the MOQ, the supplier and material behind the lead time, or the customer and channel behind a decline in demand.
The value driver tree identifies the operational or economic driver. The ontology connects that driver to where it actually exists in the business.
This gives us a useful distinction:
Decision tree — How do we decide?
Value driver tree — What drives the outcome?
Ontology — How are business concepts, objects, relationships, rules, and decision knowledge connected?
Decision trees and value driver trees are not alternatives to ontology. They are forms of business knowledge that can be represented within, or connected to, a broader business ontology.

People Already Investigate This Way
Experienced operators do this almost instinctively.
A planner who sees excess inventory rarely stares at the inventory number alone. They check whether demand has changed, whether more supply is coming, whether an MOQ or contractual commitment keeps replenishing the SKU, and whether the same product is short somewhere else.
Then they call procurement about the contract. They ask sales about future demand. They check another warehouse.
The relevant information may live in different systems, reports, spreadsheets, and people’s heads. The experienced operator knows how to move between them.
People already investigate across the business. AI usually analyzes what has been placed in front of it.
Give AI an inventory table and it may produce an excellent analysis of that table. But unless it knows that the SKU is connected to a purchasing contract, a supplier, another location, and customer commitments, it has little basis for deciding where the investigation should go next.
Ontology does not simply give AI more data; it gives AI paths to investigate beyond where the problem first appeared.
Without an ontology, AI analyzes the data placed in front of it. With an ontology, AI can investigate the business context around the problem.
Isn’t This Just an ERD?
It is a reasonable question.
An ERD also represents relationships among products, orders, suppliers, materials, and other entities. Cardinality and constraints can express meaningful business rules. Ontology is not valuable simply because it can draw connections between things.
The difference is primarily one of purpose.
An ERD is typically designed to describe how data is structured and referenced within a particular system. An ontology focuses on the business meaning of objects and relationships across systems.
A single product, for example, may appear as a material master in ERP, a planning item in an SCP system, and an inventory item in WMS. Those systems may store and identify it differently, even though the business regards it as the same product.
Building an ontology does not mean redrawing every ERD into one enormous model. It means establishing that the different representations refer to the same business object and making its relationships available across system boundaries.
The same business object may therefore be represented by multiple tables across multiple systems.
You Do Not Need to Model the Entire Enterprise First
This is where ontology can easily turn into an architecture project instead of a business project.
It does not have to.
Start with a decision you actually want AI to investigate.
For excess inventory, the first useful model might include only SKU, location, demand, purchase contract, supplier, customer commitment, and the relationships among them.
For a production disruption, the starting set might be product, material, BOM, production line, and the relevant constraints.
Much of the knowledge required to build these connections already exists.
Much of the ontology may already exist in fragments across the enterprise. Decision trees contain expert judgment. Value driver trees capture relationships between outcomes and their drivers. Process maps describe how work flows. KPI definitions, policies, and business rules encode meaning, constraints, and operating logic.
Building a business ontology does not mean discarding this knowledge and starting again. It means making these fragments explicit, connecting them to one another and to the actual objects of the business.
Ontology Still Does Not Tell AI How to Think
There is one final distinction.
Even with a well-connected ontology, AI still needs a method for choosing which relationships to follow, deciding what evidence is sufficient, testing alternative hypotheses, and knowing when to escalate the decision to a person.
Not every business problem can be reduced to a fixed decision tree.
Some investigations require several competing hypotheses. New evidence may force AI to revisit an earlier assumption. Operational and financial signals may conflict. A technically optimal answer may still require a commercial or strategic judgment.
This is where a broader Business Reasoning Model becomes necessary.
A Business Reasoning Model defines how AI should frame a problem, form hypotheses, gather evidence, traverse relevant relationships, compare alternatives, and determine when human judgment is required.
Decision trees can provide explicit decision logic. Value driver trees can capture how outcomes are driven. Both can become part of the business knowledge available to the reasoning model.
The relationship is simple:
Ontology defines the business world and the knowledge within it.
Business Reasoning Model defines how AI uses that knowledge to investigate and decide.
Companies do not need to discard the business knowledge they have built over decades.
The opportunity is to connect that knowledge to the actual objects and relationships of the business, so AI can use it the way experienced people already do—not merely to analyze what appears on the screen, but to investigate what is happening around it.
AI does not just need more business data. It needs a business world it can investigate—and a way to reason through it.
