---
title: "When the company changes, the ontology has to change with it"
url: "https://hurukan.com/blog/when-the-company-changes-so-must-the-ontology"
description: "A company adds a service line, splits a region or buys a competitor, and its model of the business goes stale. How to change an ontology without breaking what depends on it."
---

# When the company changes, the ontology has to change with it

July 21, 2026·3 min read·Editorial team

Two people seen from the side rearranging white cards on a large wall board of connected boxes in a bright workspace, one new card marked with a strip of blue tape

A company that has always sold products starts selling service contracts alongside them. A service contract does not fit the idea of an order: there is nothing to deliver, it is billed monthly, and it comes with response times the company has to meet. The fastest fix is an order with a special type code and a few free-text fields for the contract terms.

A year later, the reports count service contracts as orders and inflate the order book. The warehouse sees orders with no items and asks what to pick. An agent asked to prepare delivery notes for the week produces one for a maintenance contract. Each problem gets its own small patch, and each patch makes the next change harder.

The cause is that the model of the business was treated as fixed infrastructure, designed once and then defended. But an ontology is a description of how the company works, and the company changes all the time: reorganisations, new products, acquisitions, new regulations, new ways of selling. If the model cannot be changed safely, people will change it unsafely, one type code at a time.

## How a model of the business goes stale

**Overloading.** An existing object is reused for something new, distinguished by a flag. It is quick, and it means every report, rule and agent that reads the object now has to know about the flag.

**Free-text escape hatches.** Structure moves into notes fields. “Contract no. … valid until …” is typed by hand in a fixed pattern because the model has nowhere to put it.

**Silent redefinitions.** A region splits in two, and the old name now covers less territory than it did. Year-on-year comparisons quietly compare different things.

**Big-bang remodelling.** Changes are saved up for a large project “next year”. In the meantime, workarounds pile up, and the project has to unpick all of them.

**No record of why.** Nobody remembers why customer type 7 exists or whether anything still uses it, so nobody dares remove it.

**Agents learning the workaround.** An agent working from the current model reproduces its workarounds faithfully and at scale. A human eventually learned to ignore the phantom orders. An agent will not, unless the model says so.

## Change the model the way you change code

**Every change is versioned.** Each change to objects, relations or rules has an author, a reason, a review and a version number, with the same discipline applied to source code. The history can be read later by someone who was not there.

**Add first, then migrate, then retire.** Introduce the new object, the service contract, with its own relations and rules. Move the existing records across. Mark the old path as deprecated, and remove it only when nothing depends on it. Never redefine an existing meaning in place.

**Use effective dates.** A region split takes effect on a date. History keeps the old structure, reports know which one applied when, and comparisons across the boundary are made deliberately.

**Show the impact before approval.** Before a change is approved, list everything that depends on what is being changed: reports, rules, agents, integrations, documents. The approver sees the blast radius, not just the diff.

**Let agents propose; let people approve.** An agent can notice a workaround, for example that orders of one type never have items, and propose a new object to replace it, with the evidence. A person who owns that part of the business decides.

This is how Hurukan’s [Ontology layer](https://hurukan.com/system/ontology) is designed: objects, relations and rules described and versioned, and extended as agents extend the system. Proposals go through the approval rules of the [Agentic Logic layer](https://hurukan.com/system/agentic-logic), and every change is audited as made by a person, an agent or the system, as described under [Security and Sovereignty](https://hurukan.com/system/security-and-sovereignty). It is in build. Where the first version of such a model comes from is covered in [your company already has an ontology](https://hurukan.com/blog/your-company-already-has-an-ontology).

## A test you can run today

Find the three most-used “type”, “category” or “status” fields in your main system. For each:

1.  List every value it can take.
2.  For each value, find out when it was added, by whom and why.
3.  Mark the values that are used for something other than what their name says.

Then search your records for free-text fields that people fill in using a fixed pattern, such as “PO: …”, “contract no. …” or “valid until …”. Each pattern you find is an object or a relation your model does not have yet.

The two lists together are a backlog of changes the company has already made in reality and not yet made in its model. Working through them, one versioned change at a time, is cheaper than the big remodelling project they would otherwise become. [Hurukan](https://hurukan.com/) is designed to keep that backlog short.

-   ontology
-   versioning
-   change management
-   data model

## 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)