Why the Enterprise Needs Dynamic Ontology
Illustration comparing United States and Japanese traffic signals.
A Japanese traffic signal can be green to an American observer and ao, blue, to a Japanese speaker. The older word ao covered a broader blue-green range. Modern Japanese distinguishes green as midori, but the traffic signal retains the older name.
The light is the same. The categories used to describe it differ. Measuring its wavelength does not tell us which word belongs in a translation of a witness statement.
Suppose that statement becomes a knowledge graph: the car ran a blue light. A system that stores only the normalized color may lose what the witness actually said. Whether that distinction matters depends on the question someone later asks.
Enterprises make similar choices whenever they bring together records created by people who use the same words differently. An ontology defines the categories and relationships a system uses to describe its world. Those definitions make information usable, but they also determine which distinctions survive.
Different definitions, different work
Consider a medical instrument manufacturer that grew through acquisitions. Leadership asks how many patient samples the company processed last quarter. Three business units return numbers that cannot be added meaningfully.
The first counts records called samples. The second calls what it receives specimens. The third distinguishes both: a specimen arrives from a clinic, and portions of it become samples loaded into instruments. One specimen can produce six samples.
The third unit needs that distinction for traceability. The first operates a process where it adds little value. Each vocabulary reflects the work it supports.
Some disagreements like this are ordinary modeling problems. Clear definitions and explicit relationships can resolve them. But even a well-modeled system must answer another question: what does leadership want to count? Incoming material, instrument runs, and patients served are different measures.
The same issue appears with customer. Sales may count a parent company once, Finance may count its separately paying subsidiaries, and Compliance may distinguish legal entities by jurisdiction. A precise model can represent all three. It cannot choose the purpose of a report for us.
One enterprise vocabulary
The manufacturer launches a vocabulary project. Architects run workshops, publish a glossary, and select an official definition of sample.
If the official model cannot express the specimen-to-sample relationship, the third unit must preserve it elsewhere. A spreadsheet appears beside the system intended to unify the records. The apparent agreement has moved a necessary distinction out of view.
The useful question is: Which definition applies to this process, for this purpose? Agreement is still necessary, especially for a published report or regulatory obligation. It should identify the definition authoritative for that purpose while preserving the distinctions other work requires.
Software architecture already recognizes part of this problem. Domain-Driven Design uses Bounded Contexts to let different areas maintain their own models and translate between them. That provides a place for different meanings to coexist. Reproducing earlier interpretations also requires a record of how those meanings changed.
When definitions change
An instrument can remain physically unchanged while a regulator reclassifies its permitted use, marketing renames it, or an acquisition places it in a new product category. A classification appropriate for one date may no longer apply at another.
Updating the current category is useful. Overwriting the only record of the earlier category makes it harder to explain past decisions. Which instruments qualified for a program last year? Which definition did the report use? The current answer cannot reconstruct the earlier one by itself.
We therefore face two distinct requirements: several definitions may apply at the same time, and each may change over time. A system needs to record both the context of a definition and its history.
The Dao De Jing opens with “道可道，非常道。” Often translated as “The dao that can be spoken is not the eternal dao,” it offers a useful reminder here: a description has limits. In engineering, we can make those limits explicit and preserve the evidence needed to reconsider them.
Why AI makes this practical problem harder
A language model can write a valid query without resolving what the question means. Asked to count customers, it may select a plausible table and return an exact number while leaving the parent-company versus subsidiary distinction unstated.
A human analyst may know which definition the requester expects. An automated system needs that context recorded somewhere it can consult. More capable query generation makes this requirement more visible: producing the query and choosing the right meaning are separate tasks.
Extraction creates a related problem. A document contains more context than most schemas retain. A graph built for one purpose may omit a distinction that another question needs. Keeping the source accessible allows us to revisit that choice.
Dynamic Ontology
Dynamic Ontology is the discipline of managing changing definitions while preserving the evidence used to apply them.
For the manufacturer, this means retaining the specimen and sample distinction, naming the measure used in each report, and recording changes to its definition. Last quarter’s report stays tied to last quarter’s definition. A revised interpretation can be computed from the underlying records without erasing the earlier result.
Each definition needs a purpose, a scope, a version, and an owner. That owner must resolve conflicts and accept changes. The meeting still happens; its decision becomes an artifact the next analyst or system can use.
Parts of this discipline already exist. Event sourcing preserves events. Bitemporal databases distinguish when something was valid from when it was recorded. Definition history is an additional requirement: preserving changes to records does not automatically preserve the rules used to interpret them.
These requirements can be implemented with relational databases, RDF, property graphs, or other representations. The storage choice matters, but no format establishes the discipline by itself.
The practical test is straightforward: when a definition changes, can we identify which answers change, explain why, and reproduce the answers previously published? If we cannot, the meaning of our data depends on knowledge the system has not preserved.
What color do you see?
Look at the Japanese signal again, without its American counterpart. Tell us what color you see →
The essay has already influenced what you expect to see, so this is an informal reader exercise. We will report the responses by the languages readers grew up speaking at the end of the series. No sign-in is needed.
Next: Every Ontology Has a Boundary, on how a useful model becomes insufficient for a new question.
Part 1 of the Dynamic Ontology series. Parts 2 and 3 are forthcoming.