Every Business Is Already an Ontology

You think you don't have an ontology. You have five. The word sounds like something for philosophers or software architects, so most people who run businesses assume it has nothing to do with them. It has everything to do with them. An ontology is just the answer to a question every business answers a thousand times a day without noticing: what kinds of things exist here, and how do they relate to each other?

What counts as a customer. What counts as a job, an order, an account, a project. When one of those things turns into another. What has to be true for something to count at all. You have answers to all of these. You must — you couldn't operate for a single day otherwise. The trouble is that you've never written them down. And because you've never written them down, every system and every person in your business has quietly invented their own version. You don't have one shared model of what your business is. You have several private ones, and they don't quite agree.

Strip away the jargon and an ontology is three things: the kinds of things in your world, the relationships between them, and the actual instances — the specific ones that exist right now.

Your business is full of kinds. "Customer" is a kind. "Order" is a kind. "Employee," "vendor," "site," "contract" — kinds. The relationships are the rules that connect them: a customer places orders; an order contains items; an employee is responsible for accounts. And the instances are the real, particular things: this customer, that order, this contract signed last Tuesday.

None of this is abstract. It's the most concrete thing about your company. When someone in your business says "the client is unhappy," everyone in the room instantly knows what kind of thing a client is, what relationship the word implies, and roughly which instance is meant. That shared understanding — invisible, instant, assumed — is your ontology doing its job. You just never see it, the way you never see the grammar you use to speak.

When a business is one person, the ontology lives entirely in that person's head, and it's perfectly consistent — there's only one author. The trouble begins the moment the business is bigger than a single mind, which is to say almost immediately.

Now the model has to be shared across people and, increasingly, across software. And here's the thing nobody decided on purpose: every tool you adopt is forced to make its own ontological commitments before you ever log in. To function at all, your accounting system had to decide what a "customer" is. Your operational software had to decide what a "customer" is. The person who closes your deals carries a third definition that they've never spoken aloud. None of them consulted the others. They couldn't have.

So now you have three definitions of the same word, living in three places, built by people who never met. Most of the time they overlap enough that the gaps are invisible. The accounting "customer" and the operational "customer" point at mostly the same real-world people, so everyone assumes they're the same thing. They are not the same thing. They are two different models that happen to mostly agree.

The places they disagree are exactly where your hardest questions go to die.

Picture a single real thing in your business — call it a relationship with someone who pays you. In one system, that relationship is one record. In another, the same relationship was entered as two, because the work happened under two names. A third system never recorded it as a relationship at all; it only knows about the individual transactions. And the person who manages the account knows something none of the systems know: that those two records and that pile of transactions are all one thing, and that it's more important than its numbers suggest because of a handshake agreement made two years ago.

Four versions of one reality. Each internally sensible. No two identical. And the only place they're reconciled is inside one person's head — which means the true model of your business isn't written anywhere. It's distributed across your tools as fragments and held together by human memory.

This is why pulling a clean answer out of your own company feels like detective work. You're not retrieving a fact. You're reconciling competing ontologies in real time, by hand, every single time.

Here is the part that reframes everything. The choice was never whether to have an ontology. You have one the moment you have a business; it's not optional, any more than a language is optional for a conversation. The only choice you actually have is whether your ontology is explicit or implicit — written down and shared, or scattered and assumed.

Implicit is the default, and it's free, and it works astonishingly well right up until it doesn't. It costs you nothing until the day it costs you everything: when the person holding the real model leaves, when two systems disagree about something that matters, when you try to put any kind of automation or intelligence on top of a business whose own definitions don't line up. At that point you discover that the thing holding your company together was never the software. It was a shared understanding that lived mostly in people, and was never actually written down.

Making it explicit doesn't mean buying another tool. Another tool just adds a sixth private ontology to the five you already have. It means doing the thing none of the tools could do for you, because none of them could see the whole business: deciding, deliberately and once, what the kinds and relationships of your business actually are — and then giving your systems and your people a single shared model to point at instead of each quietly inventing their own.

That's the whole move. Not more data. Not more software. One agreed-upon answer to what kinds of things exist here, and how they relate — made visible, made shared, made real. You already have an ontology. The only question is whether it's written down, or trapped in the heads of people who could leave.