What an Ontology Brings to Enterprise Artificial Intelligence

A taxonomy orders concepts. An ontology explains how they work. And that difference is what separates a glossary a human reads from a representation an agent can reason about.

Introduction

Yesterday we left semantics halfway: a glossary is the minimum viable, a formal semantic model is the destination. Today we walk toward that destination. Along the way, there is a word that shows up in every enterprise AI conversation, often used as a synonym for “data model” or “list of categories,” and almost never defined: ontology.

It is worth defining it once, with rigor, because the rest of the series assumes it.

The problem

An insurance company has had its “insurance data model” for two years: well-named tables, a glossary of 40 terms, and a data mart. When the AI project arrived, the team built a RAG over the documents and an agent over the data mart. On simple questions it worked. On real questions it fell apart:

• “What happens to this policy if the claim is more than a year old?” — the agent did not know that the coverage for one type of risk expires after 12 months and another does not.
• “Is this claim within the aggregate limit?” — it did not know that limits are applied per line of business, not per individual policy.
• “Can I endorse this policy if there is an open claim?” — it did not know that an endorsement depends on the claim’s status and the type of coverage.

The glossary defined “policy,” “claim,” and “endorsement” separately. But the real questions are not about definitions: they are about how the things relate and what rules govern those relations. And that, the glossary did not say.

The concept

The canonical definition, from Tom Gruber (1993), is still the best:

An ontology is an explicit specification of a shared conceptualization.

Let’s break down the four words that matter:

• Specification. It is not intuition: it is a formal representation, with rules, that a system can process.
• Explicit. The concepts, the relations, and the constraints are written down, not implicit in an application’s code or in an analyst’s head.
• Conceptualization. It does not describe tables: it describes the domain — the classes of things that exist (policy, claim, insured, endorsement), their attributes, and how they relate.
• Shared. It is an agreement: several applications, several systems, and today several agents, use it as a common reference.

An enterprise ontology, in practice, has five pieces:

1. Classes. The categories of the domain: Policy, Claim, Insured, Endorsement, Supplier.
2. Instances. The concrete objects: policy P-2024-118, claim S-2026-007.
3. Attributes. The properties of each class: a policy has a start date, a premium, a line of business.
4. Relations. How they connect: policy → has → claim, claim → affects → policy, endorsement → modifies → policy.
5. Constraints and rules. What the domain allows or requires: a claim must be associated with exactly one policy; an endorsement is not valid if there is an open claim in the affected line; limits are applied per line of business.

Now, the distinction most conversations confuse, and the heart of this article:

Four different things, four different jobs. A product taxonomy is useful for ordering the catalog; it tells you nothing about what happens when a product goes out of stock. A database stores your claims; it does not tell you that an endorsement with an open claim is invalid. An ontology gives you the rules of the domain; a knowledge graph gives you the concrete facts of the business, connected. The ontology is the skeleton of meaning; the graph is the body of facts. (We will develop the graph on its day.)

The decisive contribution of the ontology to AI is the verifiable constraint. An LLM can say “an endorsement should not be applied if there is an open claim,” but it does not know it: it is guessing from what you have read. If that rule is in an ontology, the system can verify that a proposed endorsement respects it, before the model generates a single word. That is the difference between an agent that seems to understand the domain and one the organization can entrust a decision to.

Architecture

In the series diagram, the ontology sits inside the knowledge column, as the formal specification of the semantics:

                KNOWLEDGE
                     ↑
          ┌──────────┴──────────┐
          ↓                     ↓
      ONTOLOGY             (instances, facts,
   (classes, relations,    concrete relations →
    constraints)           KNOWLEDGE GRAPH, day 6-7)
          ↓
       SEMANTICS
          ↓
        DATA

The ontology is the layer where yesterday’s semantics stops being “an agreement written in a document” and becomes “a representation a system can check.” It is, in the terms of the series, the point at which the cognitive infrastructure starts to be verifiable, and not only readable.

Use case

The insurance company, with its underwriting domain. We break it down:

1. Problem. Adjusters lose time manually checking whether a claim or an endorsement respects the policy’s rules, and inconsistencies are detected late, sometimes after paying.
2. Decision. Accept or reject a proposed endorsement on a specific policy.
3. Necessary knowledge. What rules govern an endorsement; what an open claim is; what lines of business exist and their limits; what coverage expires and when.
4. Data. Policies, claims, endorsements, insureds, and lines of business in the insurance core; terms in PDF documents.
5. Relations. Policy → line of business; policy → claims; claim → status (open/closed); endorsement → policy; coverage → expiry period.
6. Context. The endorsement is requested on the 30th day of the period; the policy has two claims, one open in the affected line.
7. Memory. A similar endorsement was rejected in 2025 by the same rule; the decision and its justification are in the adjuster’s history.
8. Reasoning. Apply the constraint: endorsement invalid if open_claim in affected line → the proposed endorsement is invalid; propose the alternative (wait to close the claim or apply the exceptions clause, if it exists).
9. Action. Reject the endorsement citing the rule, or queue the alternative for approval.
10. Infrastructure. The ontology of the domain (classes, relations, constraints) + the facts of the graph (this policy, this claim, its status) + the reasoning that crosses both. Without the ontology, the agent “figures out” the rule; with the ontology, it verifies it.

The case shows the exact value of the ontology: it is not that the agent knows more, it is that the system can check that the agent respects the domain.

Trade-offs

• Cost. Formalizing a domain ontology is expensive: it requires business experts and time, and the first model always comes out incomplete.
• Complexity. A very rich ontology (full OWL, with heavy inference) can be overengineering for many cases. The practical rule: start with RDFS (classes and properties, no complex logic) and add constraints only where the business requires them.
• Maintenance. The domain changes: a new line of business, a rule modified by the regulator. The ontology must have an owner and a change process, or it becomes an outdated map that gives false confidence.
• Latency. Inference over large ontologies adds time. In practice, the verifications that matter are selective and cheap; what cannot be verified all the time is a graph of millions of instances, but that is a problem of the graph (days 6–7), not of the ontology.
• Adoption. An ontology that neither the applications nor the agents consume is a dead document. Its value is born the day a system uses it to verify.
• Honest limitation: the ontology captures the expressible rules. The underwriter’s judgment that says “this claim looks weird” does not go into the ontology. The ontology formalizes the domain; it does not replace it.

Implication for the business

For the CDO, the ontology is the organization’s executable semantic asset: the glossary is for humans, the ontology is for systems. And because it is a shared agreement, it needs an owner with business authority, not just technical.

For the AI team, the ontology changes the kind of trust you can ask of an agent: from “it gives plausible answers” to “it respects rules the system can check.” That is what turns a pilot into something that can support decisions.

For the executive team, the message is economic: every business rule that today lives in an expert’s head and in a PDF, and that an agent can violate without anyone noticing, is a latent risk. The ontology does not eliminate it, but it makes it visible and verifiable.

Conclusion

An ontology is an explicit specification of a shared conceptualization: classes, relations, attributes, and constraints that make the domain verifiable. It is not a taxonomy (which only classifies), it is not a knowledge graph (which stores facts), and it is not a database (which stores and queries). It is the skeleton of meaning on which the rest of the series will rest.

But an ontology tells us what class of thing a policy or a claim is. And there the next question appears, the most practical of all: if we know what class of thing each record is, do we know which concrete entity it represents? Because in the real company, the same entity appears under ten different names.

Next article

Tomorrow: Before you can reason, you have to know who is who. We will see what entity resolution is, why it is the prerequisite for reliable enterprise knowledge, and what happens when “ACME,” “ACME LTD,” and “Customer 49281” are, for all practical purposes, the same company.

Sources

• Gruber, T. (1993). “A Translation Approach to Portable Ontology Specifications.” Knowledge Acquisition, 5(2). — The canonical definition of ontology.
• W3C: RDF, RDFS, OWL 2. — Representation and ontology standards.
• Working definition of the ECI: see the series, Day 1.