--- title: "Your company already has an ontology. It lives in people's heads" url: "https://hurukan.com/blog/your-company-already-has-an-ontology" description: "Every company runs on a shared model of customers, orders and exceptions that nobody wrote down. How to find where that model lives and how to get it out of people's heads." --- # Your company already has an ontology. It lives in people's heads May 8, 2026·4 min read·Editorial team An experienced employee seen from behind explaining something to a new colleague at a whiteboard covered in hand-drawn boxes and connecting lines, one line traced in blue marker, soft daylight in a plain meeting room A new sales coordinator joins the company. In her first week she learns that “active customer” means three different things. In sales it is anyone who has ordered recently. In finance it is anyone with an open credit limit. In logistics it is anyone with a verified delivery address. Nobody is wrong; each team needs its own meaning for its own work. She also learns that a priority order may jump the production queue only if the account manager agrees, that a certain group of customers must never receive a partial delivery, and that the parent company in the system is not the one that pays. None of this is in the software. It lives in the heads of three experienced colleagues and in a spreadsheet tab called “do not delete”. That is an ontology: a description of what exists in the business, how those things relate and which rules govern them. The word sounds academic. The thing is ordinary, and every company has one. The problem is that it is tacit, carried by people, passed on by apprenticeship and encoded only partly in field names and spreadsheet formulas. Software stores fields. People hold the meaning. For years that was tolerable, because the people doing the work could absorb the meaning over months. An agent cannot. It can only follow what has been written down. Ask an agent to prepare this week’s deliveries and it will cheerfully send a partial delivery to exactly the customer everyone knows must never get one. ## Where the hidden ontology shows **Words that mean several things.** Active, customer, delivered, closed, done. Each team uses the same word for a different state, and every report that crosses teams quietly mixes them. **Rules held as reflexes.** “We never quote below cost for a new account, except when…” The exception is real and important, and it exists only as a habit of the person who usually prepares quotes. **Relations nobody modelled.** The group that owns the customer, the site that places the order, the address that receives the goods and the entity that pays are four different things. The system has one customer record with a notes field. **Exceptions as folklore.** The list of special cases is held by the longest-serving staff and handed on in conversation. When they are on holiday, the exceptions are handled wrongly. **Spreadsheets as a shadow schema.** Extra columns appear wherever the system had nowhere to put a fact the business needed. Each one is a piece of the model that grew outside the model. ## How to write it down without a two-year project Do not start with a workshop on taxonomy. Start with decisions, because decisions are where the meaning is used. **Pick one process and collect its decisions.** For each decision, ask the person who makes it three things: what did you look at, what rule did you apply, and what would have made you decide differently. **Name the objects and relations the decisions use.** Customer, site, order, delivery, credit limit. Then write the relations plainly: a delivery belongs to an order, goes to a site and is billed to an entity. **Write the rules next to the objects they govern**, each with an owner and a reason, so the rule can be questioned later by someone who was not in the room. **Make disagreements explicit instead of resolving them by force.** If finance and sales mean different things by “active”, keep both under different names. The aim is one meaning per word, not one word for the whole company. The same discipline applied to metrics is described in [one definition of revenue](https://hurukan.com/blog/one-definition-of-revenue). **Let it grow from use.** Every time an exception is handled, ask whether it is really a new rule. If it is, it goes into the model with its owner. This is the job of the [Ontology layer](https://hurukan.com/system/ontology) in Hurukan: a described, versioned model of objects, relations and rules that every module and every agent reads. It is designed to develop itself as the system is extended: an agent proposes a new object or rule, a person approves it, and the change is recorded. Because the company keeps changing, the model has to be able to change safely, which is the subject of [when the company changes, the ontology has to change with it](https://hurukan.com/blog/when-the-company-changes-so-must-the-ontology). ## A test you can run today Pick three words your company uses every day. “Customer”, “order” and “done” are good ones. Ask one person in sales, one in finance and one in operations to define each in a single sentence, separately and in writing, without conferring. Put the nine sentences side by side. Every difference is a piece of your ontology that lives in someone’s head. Then sit for half an hour with the most experienced person in one team and ask a single question: what do you know that the system does not? Write down everything they say. That list is the first draft of your company’s model, and it is more accurate than most specifications written for a new system. When it exists on paper, it can become something software and agents can read, which is where [Hurukan](https://hurukan.com/) starts. - ontology - tacit knowledge - business rules - agents ## Keep reading - [One identity for people and agents: who may do what](https://hurukan.com/blog/one-identity-for-people-and-agents) - [The live state and the record: two memories of a company operating system](https://hurukan.com/blog/the-live-state-and-the-record-two-memories-of-a-company-operating-system)