Eight minute read. Written for executives who keep hearing the word and want a working definition that survives a board meeting. We use no jargon you have not earned.
An ontology is a written, machine-readable definition of the things in your business and how they connect. The word comes from philosophy, where ontology is the study of what exists. In a software context it means the same thing, scoped to your organisation: what entities exist here, what we call them, and how they relate.
A retail bank ontology might say: a customer holds one or more accounts, each account is governed by a contract, contracts have renewal dates, customers raise tickets, tickets have SLAs. Each of those bolded words is a class. Each “holds”, “governed by”, “raises” is a relationship. The whole thing is the ontology.
Ontologies are not new. Researchers have been writing them since the 1990s. For most of that time they were academic curiosities, kept alive by life sciences and aerospace where the cost of getting an entity wrong was a recall or a crash. Most enterprises ignored them.
What changed is that we now have software (large language models) that can speak. They can describe, summarise, and reason in natural language. The thing they cannot do is know what your business is. They have no map.
Without a map, the LLM falls back on what looks plausible. With a map, it can reason. Suddenly the boring discipline of writing down what a customer is becomes the difference between an AI that hallucinates and one that helps.
The kinds of thing in your business: Customer, Product, Transaction, Claim, Asset. A class is a category, not an instance. “Customer” is a class. “Customer #4192” is an instance.
The attributes a class has. A Customer has a name, an email, a date of birth. Properties have ranges (a date of birth must be a date, not a string).
How classes connect. A Customer holds an Account. An Account is governed by a Contract. Relationships have direction and cardinality (one customer, many accounts).
The rules that hold the model together. A Customer must have at least one Contact. An Account cannot have a renewal date in the past. The constraints are what make the ontology enforceable.
Subclassing. A Premium Customer is a kind of Customer with extra properties. A Joint Account is a kind of Account. Inheritance keeps the model compact and legible.
Plain-English labels and definitions, stored alongside the formal model. The auditor reads the annotation. The agent uses the formal class. They never go out of sync.
A database schema describes how data is stored: tables, columns, foreign keys. It is shaped by storage and performance concerns. An ontology describes what the data means, independent of where it lives. The same ontology can be served from a relational database, a graph database, a JSON file, or all three at once. That is the point.
A glossary lists terms and definitions in plain English. Useful, but not machine-readable. An ontology is structured: classes, properties, relationships, constraints. A computer can reason against it. A glossary cannot do that.
The ontology is the model: the schema of meaning. The knowledge graph is the data: the actual instances populating that model. The ontology says “Customer holds Account.” The knowledge graph says “Customer #4192 holds Account #88210.” You need both.
The biggest mistake we see is enterprises trying to model everything at once. They commission a 200-class enterprise ontology, three years pass, nobody uses it, the consultancy moves on. Do not do this.
Start with one painful question. “Why are renewals slipping?” “Which customers are churning?” “Which models are inside EU AI Act scope?” Build the smallest ontology that lets you answer that question well. Ten classes, twenty relationships, four constraints. Ship it. Use it. Add the next question.
An ontology that answers one question well is more valuable than one that aspires to answer everything. Compounding takes care of the rest.
Two weeks. We map your existing data into a working draft and identify the entities your AI keeps getting wrong.
Book a meeting →