The term describes something a business already has
Every mid-sized company already operates an ontology. It lives in the shared vocabulary of a sales team, the way finance defines revenue, the distinction an operations team makes between a return and a rejection, the categories the compliance function reviews against. What it lacks is explicitness, ownership and a place to live. Two people mean the same thing by 'active customer' and neither can say where it is written down; a rule about when an order is binding lives in the mind of a credit manager, applied consistently and never written.
Making it explicit is not an academic exercise. It is the difference between a business whose logic is transferable to a machine and one whose logic must be re-explained, in a meeting, to every system that needs it. For an architect or a CDO the pitch is simple: this is the specification layer, it is currently implicit, and every AI project will either use it or reconstruct it badly.
Five kinds of thing an ontology holds
The content of an ontology falls into five categories, and confusing them is the usual reason a first attempt produces a data catalogue.
- Entities: the things the business recognises as distinct — a customer, a site, a contract, a product, a shipment — each with the fields that make one instance distinguishable from another.
- Relationships: how entities connect, with the conditions and dates that govern the connection, and the cases where it does not hold.
- Events: what happens to entities over time — an order placed, a goods received, a credit note raised — distinguished from the states those events produce.
- Rules: the conditions under which the business acts, expressed so that condition and outcome are separable. 'Below X, needs approval' is a rule; 'approve it' alone is not.
- Permissions: who may see, change, trigger or approve, expressed against the entity rather than the screen.
Events deserve attention because they are the part most often left out, and they are what turns a description of the business into something that can respond. A customer is a state; one who has not ordered in nine months is still a customer, but a different one from a customer who ordered yesterday. Systems modelling only the current state cannot answer questions about change, and most operational questions are about change.
Rules are the part that reveals the organisation
Writing rules down usually produces uncomfortable findings, and they are findings worth having. Three patterns recur.
The first is that the rule the people follow is narrower than the rule the policy document states: the document permits discretion up to a limit, the team applies roughly half of it, and the limit was set for a different risk profile two years ago. Once written down, the discrepancy becomes a decision somebody has to make, which is precisely the value. The second is that two teams apply different rules to the same situation without either knowing — usually the mechanism behind a department boundary problem, and a data problem only after somebody documents it.
The third is that some rules are not rules at all but compensations for missing data: a check that exists because two systems disagree and nobody has resolved why. Mark these explicitly, because they identify the next piece of data work rather than the next piece of process work.
Who owns it, and how it survives a change of personnel
The governance question matters because ontologies fail in a consistent way: they are built by a well-meaning team, they are accurate at launch, and they are wrong within two release cycles because the people who validated them have changed roles. The controls that work are unglamorous — a versioned entity definition, a named business owner per entity, a change request the owner must approve, and a review that is genuinely a review.
One useful convention is to record, for each rule, who raised it and who authorised it, as described in building auditability into AI-enabled processes. When a disputed output appears, this turns an argument about data into a short conversation with the business.
Where AI is the wrong tool for this work
An ontology should not be generated. It is tempting to have a model read a warehouse schema and propose entity definitions; the output will look plausible and will encode the existing inconsistencies as though they were decisions. A model can draft a candidate glossary for review and suggest relationships to be checked. It cannot decide that a disputed term has one intended meaning, and it cannot own the answer, as argued in why AI cannot fix data problems the business has never defined.
A model is also right at the edges: reading a contract for the terms that populate an entity, classifying a message against an existing event type, flagging a record matching no declared entity. The ontology constrains those uses rather than being produced by them.
The order in which the ontology gets built
The categories above do not build in the order people expect. The sequence below reflects what each stage needs in order to be finished, and it front-loads the parts that require a business decision.
- Choose a single process that already has a named owner, and describe it in terms of entities, events and the rules that govern them. Resist covering the whole business at this stage.
- Write the disputed terms down as explicit definitions with an owner each. The disputed ones are the value: an uncontested term costs nothing to record and changes nothing.
- Extract the rules that currently live in individual judgement, recording for each the condition, the outcome and who authorised it.
- Mark every rule that exists only to compensate for missing or unreliable data, because each is a named item of future engineering work.
- State entitlements as rules over entities, and have the accountable executive approve them.
- Publish the set with versioning and a change process, then revisit it when a source system changes rather than when someone remembers.
Steps two and three are where the effort goes and where the value sits. They cannot be accelerated by adding people to a data team, because the missing knowledge sits with a few individuals whose time has to be requested deliberately.
How to know it is working
Three measures are enough, and all three are observable by the business. Count the questions that require two systems and are currently answered by email. Count the terms with two live definitions after publication. Third, and most diagnostic, count the operational disputes that could be settled by pointing at a rule — if that number rises at first, the ontology is surfacing real ambiguity previously absorbed by people, and that rise is the early sign of value.
The practical test is whether a system that has never met your organisation can be given the ontology and reach the decisions your organisation reaches. If it cannot, the gaps are almost always in the rules and the permissions rather than the entity list. The engineering that consumes this layer is described in enterprise agent engineering.