Own the Model of Reality

Ontology is the branch of philosophy that studies existence.
If you don’t own your ontology, you don’t own your model of reality.
If you don’t own your model of reality, you don’t own the decisions you make.

AI makes this painfully clear.

Ontology Ownership Is Invisible Until It Fails

The HR system defines the employee.
The CRM defines the customer.
The project tool defines the assignment.

None of these are the truth.
They are system-specific representations of reality.

You own your data when you can answer questions like:

What do we actually know?
Where does that information come from?
What does it mean, according to our definitions?
How has that meaning changed over time?
Can we reproduce the reasoning behind a decision, in the context where it was made?

Loss of ownership rarely feels dramatic.
It shows up as friction.
As answers that depend on who you ask.
As “temporary” workarounds.

We usually notice something is wrong when we want to change systems.
But we rarely recognize it as a loss of ownership.

Humans are remarkably good at compensating for broken representations.
We squint.
We fill gaps with assumptions.
We rely on social capital.
We escalate.
We guess.

And when it fails, we tend to blame each other.
Rarely the model of reality we built our systems on.

Entities In Other Systems

Organizations rarely lose data ownership in a single decision.
They lose it slowly.
System by system.
Integration by integration.

It often starts innocently.
A better HR system.
A modern CRM.
A specialized project tool.

Each system is good at what it does.
But each also becomes the place where a core business entity is defined.

Your employees are defined in the HR system.
Your customers are defined in the CRM.
Your projects are defined in the project tool.

At that point, you don’t just use those systems.
Parts of your reality now live inside them.

If your core entities only exist through someone else’s schema,
and only through someone else’s API,
you don’t really own them.

You lease them.

APIs give access.
They don’t give authority.

They let you read and sometimes update data.
But they rarely let you define meaning.
They rarely let you control history.
They rarely guarantee reproducibility of past understanding.

This is where many organizations quietly lose something critical.
Not data.
Not functionality.
But semantic authority.

You usually don’t notice until you try to do something new.
Combine data across domains.
Train AI on historical context.
Audit decisions years later.
Explain why something was true then, even if it is not true now.

At that point, integration is no longer a technical problem.
It is an ontology problem.

Most integration focuses on moving data.
Very little focuses on moving meaning.

We build pipelines.
Mappings.
Transformations.

And then we are surprised when systems still don’t agree.

Because the problem was never transport.
Never format.
Never protocol.

It was ontology.

When two systems “share” an entity, they rarely share the same meaning.

An employee in HR is a legal construct.
In project systems, a resource.
In finance, a cost center projection.

Same word.
Different realities.

Integration tries to solve this with mapping tables, translations, and master data layers.

But mapping is not understanding.
And synchronization is not shared meaning.

You can move identifiers.
Copy attributes.
Synchronize updates in near real time.

And still not share ontology.

This is why integration complexity grows over time.
Each system adds another interpretation of reality.
Each mapping preserves differences instead of resolving them.

ETL moves data.
Ontology moves meaning.

If you don’t own the ontology,
integration becomes translation between partially incompatible realities.

And translation is always lossy.

The goal is not to make systems agree.
The goal is to make them disagree in controlled, explainable ways.

Because disagreement is normal.
Unexplained disagreement is organizational risk.

Centralizing identifiers is useful.
Centralizing meaning is what actually matters.

When you share entities without sharing ontology,
you are not integrating systems.

You are synchronizing misunderstandings.

Relations and History

A system that supports true ownership encourages long-lived entities.
It allows entities to exist through time.

It understands how entities evolve.
It allows new relationships to appear,
even ones not known when the entity was created.

An employee is not reborn when moving location.
An employee who leaves and returns is still the same person,
even if they receive a new employment number.

These changes don’t need careful design when History and Relationship are first class.
Then Attributes evolve, and the system knows when changes happened.

Such systems always know when changes occur.
They can represent reality before and after each change.

You can ask:
What did the world look like at any point in time?

Ownership becomes simpler when entities evolve naturally over time,
forming new relationships without schema revolutions.

These systems remain conceptually simple.
They don’t try to control reality.
They record it.

They preserve knowledge when systems fail.
Preserve meaning when organizations change.
Preserve ownership of data.

The Relational Database Is Not About Relations

Despite its name, most relational databases restrict relationships.
They enforce known structure.

New schema is often required for new entity types,
instead of allowing attributes and relationships to evolve naturally.

These systems must constantly adapt to reality,
but instead begin to dictate reality.

This makes data ownership hard.

Most relational systems do not treat time as a first-class concept.
They coordinate updates through transactions.
But once committed, transactions disappear,
leaving only the resulting state.

Previous values are overwritten.
Without additional design, there is no native memory these values ever existed.

This is not a model inherently built for data ownership.

Organizations can build ownership on top.
But it requires careful schema design,
careful process design,
and careful continuous coordination.

Relational databases are difficult whenever forgotten facts and predefined relationships is not the default

Programmers know this. They treat source code as something that must be understandable from any point in history. They expect to see what changed, when it changed, and why.

And yet, most systems they build for business data do not preserve reality with the same care.

Databases should record reality, not dictate it.

When Transactions Become Data

Most relational systems treat transactions as invisible infrastructure.
They ensure consistency.
Then they disappear.

But when transactions themselves become data,
they become part of the model of reality.

A transaction can describe:
What changed
When it changed
Why it changed
Under which assumptions it changed

And most importantly:
What we believed to be true at that moment in time.

Fact-based models make this simple.
Because when facts are first-class, transactions can become first-class too.

And when transactions are data, history stops being reconstruction.
It becomes an observation.

History is naturally preserved when the database becomes a sequence of transactions over time.

Towards Models Built For Ownership

If reality evolves through time,
and transactions become observable knowledge,
then facts must be stored without assuming all structure in advance.

A natural foundation for data ownership
is a model where facts are first-class.

Models such as triple stores treat data as:

Entity - Attribute - Value

Data represented as entities with attributes and values
where values are either simple values or other entities, relations.

This is not just a storage pattern.
It is a way of allowing reality to be described as it changes.

New attributes can appear.
New relationships can appear.
New entity types can emerge.

Without forcing schema revolutions.

This makes systems easier to live with over long periods of time.
Because reality does not change all at once.
It changes gradually.
Unexpectedly.
Across domains.

When Relationships Are Data

In traditional relational databases, relationships must be modeled in advance.
This works well when the structure is stable.

But schema evolution can turn uncertainty into false certainty.
Entities are retroactively forced to comply with relationships that were never part of their original reality,
that wasn’t a concern when they were created, and lived their life.

When reality evolves,
new relationships often appear before we have language for them.

When relationships themselves are data,
systems can adapt naturally to new meaning.
Not by removing structure.
But by allowing structure to grow from facts.

Ownership becomes simple when systems can:
Preserve entity identity through time
Allow relationships to evolve
Store history as observation, not reconstruction
Adapt to new meaning without rewriting the past

When relationships, attributes, and change are data,
ownership becomes much easier to maintain.

Relational schema evolution normalizes the past.
Fact-based models preserve what was actually known.

History should be observable, not reconstructed.

AI Makes This Non-Optional

For a long time, fragmented reality models were manageable.
Humans compensated.
We filled gaps.
We negotiated meaning.

AI does not.
AI reflects the reality model it is given.

If data is fragmented,
AI will be fragmented.

If history is incomplete,
AI will guess.

If ontology is inconsistent,
AI will scale that inconsistency.

AI does not just consume data.
It consumes meaning.

Without history, it sees snapshots.
Without ontology, labels.
Without ownership, fragments.

And fragments scale well.
Until decisions matter.

The real risk is not wrong answers.
The real risk is believable answers
built on incomplete reality models.

AI turns data ownership into decision ownership.

If you do not own:
Your entities
Your relationships
Your history
Your meaning over time

You do not fully own the decisions built on top of them.

For decades, storing correct state was enough.
Increasingly, we must store the evolution of understanding.

Not just what is true.
But how truth became true.

AI is not creating this requirement.
It is removing our ability to ignore it.