Your Ontology Is Wrong the Moment You Finish It

Automatic ontology development isn't a feature you build. It's an emergent capability of the neurocognitive stack — and that changes everything about how enterprise intelligence gets made.

There's a quiet, expensive assumption buried inside most enterprise AI projects, and almost nobody says it out loud: that if you could just describe your business correctly enough — every entity, every relationship, every rule — the machine would finally understand it.

So companies try. They hire consultants. They run workshops. They spend months, sometimes years, and frequently millions of dollars building an ontology: a formal model of what things exist in their world and how they relate. A customer has orders. A deal belongs to a fund. An aircraft contains engines. Get the model right, the thinking goes, and you can pour your data into it and reason over the result.

Palantir built a remarkable business on exactly this premise. Their Foundry platform is, at its heart, an ontology engine — and it is genuinely good at what it does. But the premise has a flaw so fundamental that no amount of engineering can fix it:

The ontology is wrong the moment you finish building it.

Not wrong for doing it badly. Wrong because the world you modeled has already moved. The org restructured. A new business line appeared. A category of counterparty you'd never named — a continuation-vehicle co-investor, a regulatory body, a supplier-turned-competitor — walked into your data and found no box to sit in. Your beautiful, expensive map is now a photograph of a place that no longer exists.

And here's the part that should bother you most: you paid for the map up front, and reality invoices you for the corrections forever.

I've spent the last several months building an alternative, and I want to make an argument that I think will become obvious in hindsight: ontologies shouldn't be built. They should be grown. And the only thing we know of that can grow an ontology automatically — continuously, adaptively, from lived experience — is a brain. Which means the path forward isn't a better modeling tool. It's a system architected around the same memory structures the human brain uses.

Let me explain why and what it looks like when you actually build it.

What an ontology really is (and why declaring it is a category error)

Strip away the software, and an ontology is just structured knowledge about categories and relationships. It's the difference between knowing this specific dog, Rex, on Tuesday and knowing what a dog is in general.

Cognitive scientists have a name for that second kind of knowledge. They call it semantic memory — your store of timeless, decontextualized facts and categories. And it turns out the brain doesn't declare its semantic categories. It grows them, from the bottom up, out of accumulated experience.

You didn't learn what a "dog" is by reading a definition. You met dozens of them — episodes, each tied to a time and place — and somewhere in the anterior temporal lobes of your brain, a category quietly precipitated out of those repeated encounters. Neuroscientists can even watch it break: in a condition called semantic dementia, patients lose the categories themselves from the leaves inward. A "dachshund" becomes a "dog," then an "animal," then a "thing." The ontology decays in real time.

The lesson is profound, and almost nobody in enterprise software has internalized it: a category is not a thing you write down. It's a thing that emerges from experience and has to be maintained. The brain treats its ontology as a living hypothesis, constantly refit to new evidence.

Declaring your ontology up front is a category error in the most literal sense. You're trying to fix in stone something whose entire nature is to move.

The catch: you can't grow an ontology without the machinery to have experiences

Here's why "just make the ontology self-learning" isn't a feature you can bolt onto Palantir, and why almost no system on the market can actually do it.

To grow categories from experience, you first need to have experiences — and store them in the right forms. The brain doesn't run on one kind of memory. It runs on several, each doing a job the others can't, and the emergence of a stable ontology depends on all of them working together:

Episodic memory — events with a time and place. On April 29th, this deal closed. That call happened Tuesday. This is the raw material — the individual encounters from which categories precipitate.
Semantic memory — the timeless facts distilled out of those episodes. This company operates in aircraft maintenance. That fund owns these assets. This is where the ontology actually lives.
Procedural memory — the how. The recurring playbooks, the "this is the way we do things," often never written down anywhere. This is how an investment committee actually reaches a decision.
Working memory and consolidation — the offline process, running while you sleep, that replays episodes, finds the patterns across them, and promotes the durable ones into semantic and procedural knowledge.
A prediction-error signal — the alarm that fires when new evidence violates an existing category. This tells the brain that the map is stale and triggers a redraw. Without it, you don't have a living ontology; you have a fossil.

That last one is the crux. An ontology becomes self-developing precisely when the system can notice "this doesn't fit what I know" and reorganize its own categories in response. Neuroscience has a name for that reorganization — schema updating, driven by prediction error — and it's the single most important faculty the declared-ontology approach entirely lacks.

Now look at what that means for building software. You cannot grow an ontology automatically unless your system already stores its knowledge in these separable, brain-like forms. A pile of documents in a vector database can't do it — it has episodes of a sort but no semantic layer, no procedures, no consolidation, no prediction error. A knowledge graph with a hand-drawn schema can't do it — it has semantics but they're frozen, with no episodic substrate underneath to grow them from and no mechanism to notice when they've gone wrong.

Automatic ontology development is not an algorithm you add. It's an emergent capability of the neurocognitive stack — and I want to be precise about what "emergent" means, because it's the whole argument, not a flourish.

Emergent means the capability lives in no single layer. It is not the episodic store, or the semantic layer, or the consolidation pass, or the prediction-error loop. It is not written into any one of them and cannot be pointed to in any one of them. It appears only when all of them coexist and feed each other: episodes accumulate and consolidation distills them into semantic categories; those categories become expectations; prediction error fires when the expectations break; and that signal drives the whole structure to reorganize — which changes what the next episodes mean. The capability is a property of the loop, not of any station on it.

What it looks like when you build the whole stack

This isn't theoretical. The system I've been building — a permissions-aware memory layer that sits atop a firm's existing document estate — has each of these faculties as a distinct, first-class layer. And the payoff shows up in a way that surprised even me.

We never told the system the firm's operating procedures. Nobody sat in a workshop and diagrammed "how the investment committee decides." And yet, running its weekly consolidation pass over the corpus, the system discovered thirty-one distinct operating procedures — with their inputs, participant roles, and ordered steps — purely from behavioral patterns in the data. It reconstructed the investment-committee decision process, step by step, by watching how decisions actually left their traces across thousands of documents.

That is bottom-up schema induction. That is a machine growing a piece of its own ontology from episodic experience, exactly the way the anterior temporal lobe grows a category from encounters. No one declared it. It precipitated. And notice where it came from: not from a "procedure-discovery module" we wrote, but from the interaction between the episodic layer that recorded the events, the consolidation pass that replayed them, and the semantic layer that held the result. The capability emerged from the stack. We didn't code it; we assembled the conditions under which it appears.

And critically — because the system also has a prediction-error loop (a weekly process that re-scores what it believes and raises a flag when new evidence contradicts an established belief), those discovered structures don't calcify. When reality drifts, the system notices. It can tell you not just what it knows but what it knew is no longer holding.

Compare that to the declared-ontology world. In Foundry, the very first thing a CIO spends money on is transformation — restructuring the company's data into the shape the ontology models demand. Hundreds of thousands to millions of dollars, before a single insight. And the instant that transformation completes, it begins to rot, because the business kept moving while the consultants modeled it. You buy a snapshot and pay maintenance on it forever.

The neurocognitive approach inverts the entire economic model. You ingest documents where they already sit — no transformation, no forced schema — and the system grows its understanding from them, continuously, the way you grew your understanding of the word "dog." The map maintains itself.

Adaptive by default — and secured by choice

Here's where the argument turns from elegant to practical, and where I think the declared-ontology camp has it exactly backward.

They treat the fixed ontology as a feature: it's governed, it's stable, it's auditable. And a self-learning system sounds, by contrast, a little frightening — won't it drift into nonsense? Won't it invent categories you never approved?

Only if you build it naively. The right architecture gives you both — and this is the point I most want to land:

A self-developing ontology is adaptive by default and secured by choice.

The system is always proposing — always noticing a new category forming in the data, a new kind of relationship, a risk pattern nobody had named. That's the adaptive engine, running continuously. But between proposing and adopting sits a gate you control. In our system, a proposed change to the ontology is exactly that — a proposal, with its evidence attached — and a human curator approves it before it becomes part of the trusted structure. Approval doesn't even automatically trigger the change; adoption is a deliberate, separate, two-key act. Nothing rewrites your firm's category structure behind your back.

This is, again, borrowed straight from the brain. You have flashes of intuition constantly — the fast, adaptive, pattern-matching layer. But you don't act on all of them; a slower, deliberate faculty vets which ones become part of how you see the world. Fast proposal, governed adoption. The architecture mirrors the cognition.

So you get the thing the declared-ontology world claims as its exclusive advantage — governance, stability, an audit trail — without paying its crippling price of being frozen and stale. You can lock an ontology down hard when you need to (regulatory reporting, anything where the categories must not move). You can let it run loose and adaptive where discovery matters more than stability. And you can move the dial per domain, because the ontology is now data — versioned, governed, evolvable — rather than a million-dollar artifact carved once and defended forever.

And there's a layer beneath all of it that the transformation-heavy approach struggles with: because knowledge is grown from the source documents rather than copied into a new structure, permissions come along for the ride. Every derived piece of intelligence inherits the access rules of the documents it came from. If you can't see the source, you can't see what the system learned from it. The ontology is secure not as an afterthought but because it never left the security perimeter of the data it grew out of.

The shift that's coming

Two years ago, "memory" wasn't a word people used about enterprise AI. Then retrieval-augmented generation made everyone realize that a model without access to your data is a very articulate stranger. Then the smart teams learned that retrieval plus a knowledge graph beats retrieval alone. The frontier is moving fast, and it's moving in one direction: toward systems that don't just retrieve, but remember, and don't just remember, but learn.

The declared ontology was a reasonable idea for a world that held still. But that world doesn't exist, and it never did. Every ontology you commission is a bet that reality will stop moving long enough for the model to stay true. It won't. It's wrong the moment you finish it.

The alternative isn't to draw the map better. It's to build a system that draws its own map, checks it against the territory every week, and quietly redraws the parts that have gone wrong — while giving you a firm hand on which changes are allowed to stick. Adaptive by default. Secured by choice. Grown, not declared.

We didn't get there by inventing a clever new database. We got there by taking the one system seriously we already know can do this — the brain — and building each of its memory faculties as real architecture: episodic, semantic, procedural, consolidation, prediction error. And then something happened that is the entire point of this essay: with the whole stack in place, automatic ontology development stopped being a feature we had to invent and started being something the system simply did. It emerged. Not from a part — from the whole.

That's the thing to hold onto as this field moves. The winners won't be the teams that draw the best map, or even the teams that build the cleverest single component. They'll be the ones who assemble the full neurocognitive stack and let the hardest capability — a living, self-correcting understanding of your world — emerge from it. You don't engineer that directly, any more than you engineer a mind neuron by neuron. You build the conditions, and it wakes up.

Which, when you think about it, is exactly what you want it to do for you.

The author builds enterprise memory and predictive-intelligence systems. The system described here is in production use.