A few weeks ago a LinkedIn post crossed my feed making a sharper argument than the usual “ontologies are hard” complaint. It singles out Palantir’s Foundry platform as the paradigm case of what it calls declared ontology, and argues the whole category has a flaw no engineering process can fix: model your business formally, and by the time you’re done, it’s already changed shape underneath the model. A restructuring here, a counterparty of a kind you never named there, and the ontology describes a company that no longer exists. The author’s phrase for the ongoing cost is memorable: “reality invoices you for the corrections forever.” [1]
The proposed fix isn’t a better modeling process. It’s a different architecture: a system built around distinct episodic, semantic, and procedural memory layers, loosely modeled on the brain, with a “prediction-error” process that periodically checks existing beliefs against new evidence and flags what no longer holds. Ontologies, in this framing, shouldn’t be declared. They should grow out of accumulated experience, the way a category for “dog” precipitates out of hundreds of encounters rather than from someone writing down a definition first.
I’ve spent two posts arguing the opposite direction: ontology, then semantic model, then dimensional model, each a narrower projection of the layer above it. If this challenge is right, it doesn’t just complicate that argument. It breaks it.
Steelman First #
An ontology built once and never revisited is a liability, not an asset. I’ve watched it happen: a model ships, gets applause in a steering committee, and nobody touches it again until the definitions stop matching how the business actually operates. At that point it’s not documentation. It’s archaeology.
This gets worse with tools that make ontology creation easier. Fabric IQ can bootstrap one from an existing Power BI semantic model — useful as a starting point, but it also lowers the barrier to producing something that looks authoritative without anyone responsible for maintaining it.
A polished, unmaintained artifact is more dangerous than an obviously rough one, because nobody questions it — so the failure mode is real. Where I think it goes wrong is the diagnosis.
The Photograph Problem #
The argument assumes an ontology is one flat snapshot, one clock ticking toward obsolescence from the moment you’re done. On that model, yes, you’ve built a photograph and reality keeps invoicing you.
But that’s not how serious ontology engineering has to work, and it isn’t a new problem the field has never encountered. It’s partly a question of scope.
Basic Formal Ontology (BFO), created in 2002 and subsequently standardized as ISO/IEC 21838-2:2021, is deliberately domain-neutral. [2] It defines extremely general categories such as process, event, boundary, and continuant. Nothing about customers, revenue, investment committees or shipments. Those categories don’t move every time your organization restructures, because they were never assertions about your organization in the first place.
ISO/IEC 21838-1 specifies requirements for top-level ontologies, and BFO is one ontology built to conform to that standard. [3] The design intent: provide a stable conceptual foundation to which more specific domain ontologies can attach. When the business-specific concepts change, you revise the branch rather than rebuilding the tree. [4]
That doesn’t make the domain ontology permanent — it means different parts of the model move at different speeds. That’s a materially different answer to “the world moved” than either choice the LinkedIn post presents.
It’s not:
Build once and pretend it is permanent.
And it isn’t:
Never formalize. Let the model emerge from usage.
It’s:
Separate what is genuinely stable from what isn’t, and govern each layer accordingly.
What the Pitch Actually Claims #
I want to apply the same scrutiny here I apply to other AI claims, engaging with the whole argument, not just the aphorism at the top.
This is a product pitch. That’s not an accusation, but it means we should be careful about treating the product’s vocabulary as evidence for the product’s architecture.
The headline evidence is striking: the vendor says its weekly consolidation pass over one company’s document archive inferred thirty-one distinct operating procedures, including how that company’s investment committee reaches decisions, without anyone specifying them up front.
That’s an interesting claim, but it’s still just a claim — a single self-reported case study from the vendor, with no published methodology, no independent replication, no definition of how “distinct operating procedure” was counted, and no sense of how much human judgment shaped that count.
And then there’s the neuroscience vocabulary. Episodic memory. Semantic memory. Consolidation. Prediction error. The analogy is appealing, but it’s doing rhetorical work. A system that stores timestamped records and periodically re-clusters them is doing something, but calling that consolidation doesn’t make it neuroscientific, and calling a discrepancy “prediction error” doesn’t establish that the system does what a brain does.
What happens when the system discovers something new? This is where the proposal becomes much less revolutionary than the headline suggests.
The system isn’t ungoverned. Proposed changes go through a two-key process: an automated proposal followed by approval from a human curator before the change becomes part of the trusted structure. That’s sensible. It’s also telling, because once a human has to decide whether a concept is valid, whether it belongs, and whether the evidence justifies changing the model, we’ve arrived right back at ontology governance.
The system can propose.
The human decides.
That may be useful, but it isn’t the abolition of declared ontology — it’s a different way of getting proposals onto the table.
Discovery Is Not Authority #
There are two separate questions here: how do we discover that our model may be incomplete, and how do we decide what the authoritative model should be? The first is an excellent place for automation — a system that reads thousands of documents and flags undocumented terms, patterns, or contradictions could be genuinely valuable.
But discovery isn’t authority. A pattern appearing repeatedly in documents doesn’t automatically deserve to become an ontology class. It might be an exception, sloppy language, a local process, or a workaround the organization is actively trying to eliminate.
The documents may say what people do; the ontology may need to say what the organization means, and those aren’t always the same thing. That’s why the human gate matters: it does the part pattern matching can’t infer from frequency.
So the real disagreement isn’t governed versus ungoverned — both approaches need governance. It’s about where the initial structure comes from: do domain experts declare it and revise it deliberately, or does a system discover candidates bottom-up and ask a human to ratify them? That’s a genuinely interesting design question, and a much smaller—and more honest—one than “ontologies shouldn’t be built.”
The Palantir Problem #
The Palantir framing deserves more skepticism than the underlying technology does. Palantir has spent years making the ontology central to its product story, which makes it convenient to blame the explicit model for brittleness and present continuous inference as the alternative.
But if the replacement system still requires an authoritative ontology, still needs humans to approve changes, and still needs someone to decide which discovered structures are meaningful, the fundamental problem hasn’t disappeared.
The proposal mechanism has changed.
The governance problem hasn’t.
“Machines can help us discover changes to an ontology” is plausible and useful. “Therefore ontologies should not be declared” does not follow. The more capable the discovery system becomes, the more important the authoritative layer becomes, because someone still needs to decide which proposals are signal and which are noise. Otherwise you haven’t eliminated drift. You’ve automated it.
Drift Is a Scope Error #
So here’s where I land. Ontology drift isn’t evidence that formal ontologies are the wrong approach. It’s evidence that many ontology efforts are scoped wrong: one undifferentiated layer is being asked to be both permanently stable and constantly current. That’s an impossible job description for a single artifact.
The fix isn’t abandoning the ontology-first hierarchy from the first post in this series. It’s taking versioning seriously at the layer that’s supposed to be authoritative.
A top-level, domain-neutral layer should change rarely. A domain layer underneath it should change when the domain changes, with an owner, a version, and a review process. A semantic model then projects that ontology into whatever shape a use case requires, and the physical data model changes at whatever pace implementation needs.
These layers don’t need to move together. The “ontology drift” argument treats change as evidence that formalization failed. I think change is evidence that we failed to distinguish between things that were supposed to be stable and things that weren’t.
Not a photograph.
Not free-floating growth.
A managed structure with different parts moving at deliberately different speeds.
Here’s the irony: the declared and grown camps agree more than either side’s marketing admits. Neither ships a definition change without somebody deciding it’s justified — the difference is only whether the candidate started as a workshop output or a machine-discovered pattern.
It may turn out to be a real improvement in how we maintain ontologies. It isn’t the revolution the pitch initially suggests.
The More Interesting Future #
I think there’s a useful synthesis here. Start with an explicit ontology. Use machines to challenge it: feed documents, events, and operational data into systems that flag concepts the model doesn’t explain, definitions used inconsistently, and procedures that exist in practice but nowhere in the formal model. Let the system generate proposed changes, then make those proposals visible, reviewable, and governed.
In other words:
Declare the model. Let reality argue with it.
That’s more interesting to me than pretending we can avoid declaring anything. It also makes “prediction error” genuinely useful — not as a replacement for formal modeling, but as a mechanism for finding where it’s gone stale. That’s a meaningful engineering problem, and a far more modest claim than the one the pitch opened with.
You don’t need to throw away the ontology. You need to build tooling that’s good at telling you when it’s wrong.
That raises a practical question I’ve been circling for two posts now: if versioning discipline is the actual fix, what does that discipline look like day to day, and does Fabric IQ specifically support it yet?
That’s worth checking properly. That’s where I want to go next.
What is your experience with documentation being “legacy code” even before it is finished? I’d like to hear about it, so please reach out on LinkedIn or BlueSky.
References #
[1] Dr. Jerry A. Smith, “Your Ontology Is Wrong the Moment You Finish It,” LinkedIn, July 2026. https://www.linkedin.com/pulse/your-ontology-wrong-moment-you-finish-dr-jerry-a-smith-hopqe/
[2] ISO/IEC 21838-2:2021, Information technology — Top-level ontologies (TLO) — Part 2: Basic Formal Ontology (BFO). https://www.iso.org/standard/74572.html
[3] ISO/IEC 21838-1:2021, Information technology — Top-level ontologies (TLO) — Part 1: Requirements. https://www.iso.org/standard/71954.html
[4] Arp, R., Smith, B., & Spear, A.D. (2015). Building Ontologies with Basic Formal Ontology. MIT Press.
Photo by Harvey Tan Villarino: https://www.pexels.com/photo/exciting-car-drifting-action-in-san-simon-35683173/