WhatIsanEnterpriseOntologyforAI?

A language model is extraordinarily capable at language and knows nothing about your organisation. It has never seen your asset register. It does not know that a transformer belongs to a substation which belongs to a region operating under a particular regulatory regime. It cannot tell that the word "customer" means one thing in your billing system and something narrower in your contract database, and it will confidently produce text that assumes they are the same.

Retrieval closes part of the gap. If a fact is written down somewhere and indexed, a retrieval system can find it and a model can cite it. This works well for questions about documents: what the standard requires, what the contract says, what the procedure is.

It does not supply structure. Ask a well-built retrieval system which assets are affected by a particular constraint and it will return documents that mention constraints and assets. It cannot traverse from the constraint to the assets behind it, to the work orders already scheduled against those assets, to the crews qualified to do the work — because nothing in an embedding index knows those relationships exist. Similarity is not the same as connection.

An enterprise ontology supplies exactly that structure. And because it does, it makes two further things possible that are easy to overlook.

Six things, and the distinction between them matters because most projects that stall have modelled only the first two.

Objects are the types of thing the organisation deals with: assets, customers, contracts, work orders, incidents, locations, risks, policies, decisions. Each has typed attributes rather than free-text fields, and each has a system of record — one place that holds the truth, with everything else understood as a copy.

Relationships are named connections with cardinality: a substation contains transformers; a work order targets an asset; a contract obliges a party. Named relationships are what make traversal possible, and traversal is what turns a question into an answer rather than a search.

Events are things that happened, typed and timestamped against the objects they affected. An inspection finding is an event on an asset, not a document in a folder. Modelling events is what allows a question about change — what happened since, and why does it matter — to be answered at all.

Actions are the operations that may be performed: schedule an inspection, propose a work order, escalate an incident. Each has preconditions, an owner and a consequence. This is the part most often missing, and its absence is why so many agent deployments end up improvising tool calls.

Rules are the constraints that apply: an asset above this criticality requires that approval; work in this window requires that clearance. Making them explicit converts tacit organisational knowledge into something a system can check.

Metrics are how the organisation measures itself, defined once. Two departments disagreeing about what availability means is an ontology problem long before it is a reporting problem.

A data catalogue documents what data exists so that people can find it, assess its quality and understand its lineage. It is a human-facing discovery tool, and a good one is valuable.

An ontology defines what things are so that systems can reason and policy can be enforced. The audience is machines first and people second. The two coexist well, and in practice an existing catalogue is often the best starting inventory for ontology work — it already tells you where the systems of record are.

An agent without an ontology has to infer structure from whatever it is handed. It guesses which system holds the truth, guesses what an identifier refers to, and improvises tool calls. It will often be right, which is the dangerous part: there is no way to distinguish a correct guess from a confident one after the fact.

An agent with an ontology is given a mandate expressed in the same vocabulary as the business: you may read these object types, within this scope, and you may propose these declared actions. Three things follow. Its plan becomes checkable, because the steps refer to real objects and declared operations rather than to arbitrary API calls. Its permissions become reviewable by the business, because they are written in terms a business owner recognises. And its evidence becomes attachable, because the decision belongs to an object that exists in the model rather than to a chat transcript.

This is why an ontology is a governance prerequisite and not only a quality improvement. You cannot write a useful permission for data you have not defined.

Decision intelligence is the practice of treating a decision as a designed object: what is being decided, by whom, on what information, against what criteria, with what consequence, and how the outcome is measured. It has existed as a discipline for far longer than the current AI cycle.

An ontology is what makes it implementable. Once objects, rules, metrics and actions are modelled, a decision can reference them: this decision, about this asset, under this rule, measured by this metric, taken by this owner. The recorded decision becomes part of the model, which means precedent accumulates in a queryable form rather than in people's memories.

The compounding effect matters more than any single decision. An organisation that has recorded a few thousand decisions against typed objects, with the reasoning attached, has built something a model can learn from and an auditor can inspect — and it did so as a by-product of doing the work.

The decision: which of eleven ageing transformers to replace in the next capital cycle.

Objects: transformer, substation, feeder, region, work order, inspection, constraint, connection request, obligation. Relationships: a transformer sits in a substation; a substation serves feeders; a feeder has connection requests against it; a constraint applies to a region. Events: inspection findings, load excursions, outages. Rules: criticality thresholds that determine approval routing; clearance requirements for work in constrained regions. Metrics: expected unserved energy, asset health index, connection queue length.

Before the ontology, answering the question means an engineer opening a geographic information system, an asset management system, a historian and a folder of inspection reports, and reconciling four identifier schemes by hand. The judgement takes ten minutes; the assembly takes two days.

After it, the question is a traversal. An agent assembles condition history, network consequence, pending connection requests, applicable constraints and prior decisions on comparable assets, and presents a ranked proposal with the reasoning and the evidence. The engineer still decides — but now spends the two days on the eleven decisions rather than on one.

The decision: how to handle a recurring class of settlement failure with a particular counterparty.

Objects: counterparty, legal entity, account, instruction, position, limit, contract, obligation, incident, decision. Relationships: an entity holds accounts; instructions reference positions; limits apply to entities within a contract. Events: failures, breaches, amendments, notifications. Rules: authority thresholds and four-eyes requirements; segregation of duties between proposal and approval. Metrics: fail rate, exposure at close, days to resolution.

The value here is less about time and more about explanation. Without the model, an explanation of a decision is a narrative assembled after the fact. With it, an explanation is a traversal: this decision, about this counterparty, under this contract, against this limit, given these events, reviewed by this person, on this date. That difference is whether the explanation survives a supervisory conversation.

The decision: whether a quality deviation on a production line warrants stopping it.

Objects: equipment, line, batch, specification, deviation, inspection, supplier, part, order, obligation. Relationships: equipment belongs to a line; batches are produced on a line against a specification; parts come from suppliers. Events: deviations, maintenance interventions, supplier changes, inspection results. Rules: specification tolerances; escalation thresholds; customer-specific quality obligations. Metrics: first-pass yield, deviation recurrence, cost of a stop.

This example shows the value of modelling actions rather than only objects. "Stop the line", "quarantine the batch", "raise a supplier deviation" and "request a concession" are declared operations with preconditions, owners and consequences. An agent can propose one, and the proposal is checkable because the operation exists in the model. Without declared actions, the same agent would be inventing tool calls against whatever systems it could reach.

Modelling the enterprise before shipping anything. This is the dominant failure mode. A semantic model built as a standalone architecture exercise takes a year, satisfies nobody, and loses its sponsor before it is used. Modelling driven by a decision produces something in weeks that someone depends on.

Modelling objects but not actions or rules. An ontology of nouns is a data model. The verbs and the constraints are what make it useful to an agent and enforceable by a control plane.

Treating it as a data migration. The ontology defines meaning over systems of record; copying everything into a new store adds a synchronisation problem and does not add semantics.

Letting it become a committee artefact. Definitions need an owner who can decide. An ontology negotiated to consensus by every department tends to encode whatever nobody objected to, which is rarely what anybody needed.