> Site index: [llms.txt](https://ortelian.com/llms.txt) with all pages and descriptions.

# What is an ontology?

Source: https://ortelian.com/notes/what-is-an-ontology/
Markdown: https://ortelian.com/notes/what-is-an-ontology.md
Author: Laurens Nys
Published: 2026-06-07
Updated: 2026-09-23

An ontology says what exists in a business, what each thing means, how things relate and what can be done with them. The graph then holds the particular companies and people.

Every company already has a picture of what exists in its business. A rep knows a hospital is not the same kind of thing as the integrator that sells into it, and that a regulation applies to some facilities and not others. That picture lives in people’s heads and nowhere else. It worked while people did all the work. It stops working when an agent has to act on the same picture, because an agent cannot read anyone’s head. An ontology is that picture written down. It says what exists in the business, what each thing means, how things relate and what can be done with them.

## An ontology names the kinds of things, not the things themselves

Take the sales territory we built for a deep-tech company that sells into hospitals through integrators. The ontology for that territory has five kinds of thing: Company, Person, Facility, Regulation, Event. Each kind has attributes. A Company has a domain and a size. A Facility has an address. A Regulation has a date it took effect.

Between the kinds run relationships, each named and each with a direction. A Person works at a Company. A Company supplies a Facility. A Facility is regulated by a Regulation. An Event happened to a Company. And for each kind, the ontology says what can be done with it: a Person can be added to the CRM, a Company can be ranked, an Event can start a task.

*Diagram: Top band, the ontology: five kinds, Company, Person, Facility, Regulation and Event, with named directed relationships between them. Bottom band, the graph: the same shape populated with particular things, an integrator, its sales lead, a hospital, a state rule, a permit filed.*

*The ontology is the schema; the graph holds the particular companies and people. The 2,700 partner rows and the 64 ranked accounts live in the bottom band. One deep-tech company, first cycle.*

None of that names a single hospital. The particular hospitals live in the graph. The ontology is the schema; the populated graph holds the particular companies and people. [Tom Gruber’s 1993 definition](https://doi.org/10.1006/knac.1993.1008), “an explicit specification of a conceptualization”, is the academic version of the same split. Together the schema and the graph are what we call a [world model for knowledge work](https://ortelian.com/notes/what-is-a-world-model-for-knowledge-work/).

## Your tools hold the pieces and the ontology holds the stitching

If the company already has a CRM, why does it need this? The CRM has accounts and opportunities. Slack has the decision from Tuesday’s thread. The call recording has the promise the rep made. Each tool holds its own kind of thing well and knows nothing about the others. The company runs because people stitch those pieces together in their heads. A good rep knows an account is stalled because the champion left, and that the champion now works two rows down the list. The CRM does not know that. It has two contacts with two account IDs. The ontology is that stitching made explicit, so software can use it.

Take the territory above. Whether a hospital was worth calling depended on which integrator already supplied it. That is a relationship between two companies, one of which is not a customer and may never be. The CRM had no field for it. The partner list was a spreadsheet of about 2,700 rows and the supply relationships lived in the rep’s memory. We built the territory as a graph from government sources, hospital lists and integrator registries, normalised it and linked it to their CRM, with “supplies” as a named relationship. The list collapsed to 64 ranked accounts. The ranking came out of the relationship, and the relationship needed somewhere to exist first.

A second case, from a planning-software company. They wanted the companies still running an end-of-life open-source planner. GitHub knows which people committed to which repositories. The graph knows which company each person works at. Chain the two and you get “this company uses this software”, a fact no source states directly. Several people from one company committing was a reasonably safe bet they ran it internally. Stars alone were not; people star things to bookmark them. That inference is only possible because Person, Company and Repository are distinct kinds with named links between them.

## Palantir built this for governments, and a 50-person company now needs it too

Palantir made the idea operational. [Foundry’s Ontology](https://www.palantir.com/docs/foundry/ontology/overview/) puts objects, properties, links, actions and security into one model, and people and AI act on the same business objects through it. It was built for governments and the largest enterprises, with budgets and engineering teams to match.

The problem does not scale with headcount. A 50-person software company whose territory is built from public registries has the same problem as a ministry: the facts it acts on sit in sources that do not know about each other. What changed is the cost of building and keeping the model. Language models can read a registry, match a company across three sources on its domain and propose the link, and one person can check the result. In a Belgian climate-reporting build we matched 4,437 companies from a public CO2 register that way, after company names proved too unreliable to deduplicate on. What used to be a large programme is now within reach of a company with one sales team, and that company needs it for the same reason the ministry did.

## An ontology is not a wiki, a dashboard or the agent

A wiki attaches knowledge to the page where someone wrote it. An ontology attaches knowledge to the thing: a note about a regulation goes on the Regulation, and every Facility it covers sees it without anyone linking the pages. A dashboard shows people what is happening. It does not tell an agent what a row means or what it is allowed to do about it.

And an ontology is not the whole agent system. Agents still need evaluations, permissions and tools. When our meeting-prep agent runs at 9am, the ontology tells it that today’s meeting is with a Person who works at a Company that has a deal history and similar companies nearby in the graph. The CRM tool pulls the previous calls and emails. The permissions say which systems it may write to. The evaluations decide whether the brief met the standard the team agreed. Take the ontology away and each of those has to rediscover the company from scattered context on every run.

Without an ontology, an agent has every piece of the company and no idea how they fit.

## Follow the work.

Roughly monthly. Notes only. Unsubscribe anytime.

Email address