The problem is that nowhere in the warehouse is there a record of which column the business is referring to when someone references, “invoiced revenue”. An AI assistant will confidently return an answer, but not the version the CFO needed. Why? Because the information required to make that choice is not documented. And, that problem is not unique to “invoice date”; every term in your operating plan has the same level of ambiguity.

For example, what qualifies as an active customer depends on whether you mean contracted, billed, or served in the last ninety days. Whether a service line corresponds to what the ERP calls a ‘division’, or to what branch managers schedule against is a question that no column answers.  

Cleaning and producing higher quality data will never close this gap. 

Why documentation won’t solve the need for an ontology 

The formal name for this missing layer is an ‘ontology’. An ontology is an explicit statement of the concepts a business operates on, the properties they carry, and the relationships that connect them. For example, a customer holds the contract; the contract authorizes the work order; the work order posts to the GL account. When documented properly, this sequence tells a system what your data rows represent instead of leaving this to interpretation from schema names. 

The first mistake is treating an ontology as a static document. We suspect that a large percentage of ontology work never makes it past a diagram. A written definition only works if the system answering your questions reads it, which means the model must be connected to your live systems.  Without this connection, the system works out its own path, and every step is another chance to take a wrong turn. While loading the model inside your organization is necessary, that step alone is not sufficient: it must be rebuilt when new mart tables arrive, which happens whenever a business adds a new system, site, or entity. 

Lastly, someone must own the question of which version is current. The process is iterative by design. 

The second mistake is building the ontology on the wrong layer. An ontology inherits the character of whatever layer it gets built on. For example, our early drafts pulled from everything available – source tables and transform layers included – so the resulting models included some artifacts that carried little meaning for an operator.  

Our domain experts pushed back on this, and the rule we adopted in response continues to hold: 

• The model builds only on the mart layer, and every concept and relationship inside cites a named mart table 
• If something is not inside a mart, it’s not added to the model

That constraint improved the output significantly because what belongs inside a mart is a question that the business has already debated (and resolved). 

Judgment is the expensive part 

For an ontology to work, a human-in-the-loop must decide which tables become concepts, and which become properties of a concept that already exist. Someone must also decide how deep the hierarchy runs, since an organization can be modeled as: a branch and a region; a branch, district, and a division. Both options are defensible, so a human must decide whether a customer operating under two acquired brands is one customer with two relationships, or two customers that happen to have the same parent company. The two models report different retention rates despite having the same data, and nothing in the data conveys which version is accurate. 

Here’s an example of how this can go wrong.  

An early ontology draft for one of our clients promoted “Status” to a business concept, a node holding open, closed, and cancelled, with every work order linking to it. On a diagram it looks tidy. Our team removed it, because “closed” is not a thing the business interacts with; it is a property of a work order. Modeled as a concept, it becomes one of the most connected nodes in the graph while carrying no meaning of its own, and the model gets denser while saying less about how the business runs. 

While “Status” has a somewhat obvious answer, the same question gets harder when it turns to whether a service visit ends when the technician leaves the site or when the invoice clears, or whether cost of goods decomposes in three ways or four. None of those answers are retrievable from the data. There is no query that returns the correct one because the answer depends on how the business is run and what management needs to measure, which is why the work requires someone who can read a database schema and hold their own with a head of operations.  

Those two skills rarely live inside the same person. 

What our team automated is everything around the judgment component of an ontology, so that a decision is made once, then holds across every subsequent run.