In short
A quick test of whether a company has a definition problem is to ask three departments what an active customer is. Sales usually answers that it is anyone with a signed contract. Finance counts whoever paid the last invoice. Customer Success looks at who used the product in the last thirty days. All three answers are reasonable, and they produce different numbers for the same question. The data ontology is the record that settles that difference. It is one of the three components of the Company Brain, the layer that knows the company: what data exists, where it lives, how it relates and who can see what.
The term comes from philosophy, where it describes the study of what exists. In computing it took on a practical sense: an explicit specification of the concepts in a domain, the attributes of each concept and the relationships allowed between them. At Strattum we call this specification the business ontology, because it describes how one specific company works.
For each term, the data ontology answers four questions:
Active customer now has a written definition, a calculation rule, a list of the systems where it appears and an accountable department.
Many companies already have a business glossary or a data dictionary. The glossary describes terms in natural language and is meant for people to read. The dictionary describes the columns and tables of a specific database. The data ontology links the two: it starts from the business concept, points to where it is represented in each system and records the rule that calculates it in a format a machine can apply.
That last feature is the one that matters for AI. A well written glossary helps a new hire understand the company. An AI agent needs the rule in executable form to apply the same definition in every answer. Standards such as the ontology language published by the W3C exist to express this kind of specification so that different systems can interpret it.
Maintaining a data ontology does not require business teams to learn a formal language. The definition is written and validated by the people who know the process, and the technical team translates it into the format the systems can apply. The knowledge stays with the department, and the rule applies everywhere the term appears.
When a language model is asked how many active customers the company has in the South, some definition of active customer will be applied. Without a recorded definition, the model follows the most frequent interpretation in the text it received, which may be the sales one in one answer and the finance one in the next. Both answers sound right, and the gap only shows up when someone compares the numbers in a meeting.
The problem grows with agents that take actions. A policy that grants a discount to customers in good standing depends on the definition of good standing. If collections takes the renegotiation agreement into account and finance looks at the original due date, two agents that check the same policy reach opposite results for the same customer.
A data ontology only works if the definitions are maintained. Each core term needs an accountable department, a review date and a version history. When finance changes the criterion for default, the change is recorded with a date, and answers start to state which version of the definition was used.
Versioning also protects historical analysis. Last year's report can still be explained by the definition that applied at the time, even after the criterion changed, and a comparison between periods makes it clear when a difference comes from the business and when it comes from the rule.
This also resolves a common deadlock. It is not always necessary to choose a single definition for the whole company. Active customer for sales and active customer for finance can coexist as distinct terms, with distinct names, as long as each question is linked to the right term. The mistake is using the same word for both without recording the difference.
In the Company Brain, the three components work together. The knowledge graph stores the entities and the relationships between them. The data ontology says what each entity and each relationship means and which rules apply. The semantic layer uses that vocabulary to translate a natural language question into the right query, with the permissions of whoever asked.
When someone asks for the active customers in their own portfolio, the semantic layer identifies the term, checks the ontology to see which definition applies to that department and walks the graph with that rule. The answer, served to the model via MCP, cites the definition applied and the source systems.
Trying to model every concept in the company before the first use case usually produces a long document nobody reads. The shorter path is to list the terms that appear in reports from different departments with numbers that do not match. Active customer, revenue, churn, order delivered and ticket resolved are frequent candidates.
Each resolved term then applies to every agent and report that queries the Company Brain. The data ontology grows with the use cases, and each new project inherits the definitions the earlier ones already agreed on.
