Enterprise AI post-mortems have changed character. The older ones read like RAND’s catalogue of failure causes, misunderstood problems and data that could not carry the weight, feeding a failure rate the researchers put above 80 percent (Ryseff, De Bruhl and Newberry, 2024). The ones crossing my desk in 2026 name a different trio, over and over. The agent behaved differently today than it did yesterday, same inputs. The model asserted a purchase order, a clause, a valuation model that does not exist. And when the auditor asked why the system did what it did, nobody could produce an answer that survived scrutiny.
Determinism failures. Hallucinations. Compliance gaps.
Three symptoms, one defect. A model invents entities when nothing machine-readable tells it what exists. Runs diverge when nothing pins down which actions are permitted, under what conditions, against which objects.
Compliance evidence cannot be produced when authority and auditability were never encoded anywhere a system could enforce them. The older definitional fights still contribute: nobody could agree on what a “customer” was, or whether a work order and a maintenance event were the same thing. A real factor, but no longer the largest. That ambiguity is the human-speed version of the disease that now presents as invented valuation models and unreproducible runs. Each failure is a failure of meaning, and the artifact that fixes all of them has an old name from knowledge engineering: an ontology, an explicit specification of a conceptualisation (Gruber, 1993). Strip the philosophy and it is three registers. What things exist in our business. How they connect. What actions are allowed against them, by whom, with what trace. One register grounds the model, one constrains the behaviour, one produces the evidence.
Everyone rediscovers this eventually. The interesting question in 2026 is not whether you need one. It is who ends up owning it.
The market has already priced this
You do not have to take my word for the value of the thing. Watch where the money went.
Palantir spent roughly two decades as a bespoke integration house before posting its first GAAP-profitable full year in 2023 (Palantir Technologies, 2024). The product that emerged from those years is not a database and not a model. Palantir’s own documentation describes the Foundry Ontology as the layer that sits on top of datasets and models and binds them to their real-world counterparts, with object types, link types, and action types as the primitives (Palantir Technologies, 2026). Entities, relationships, permitted actions. The three registers, productised.
Founder-facing commentary has caught up. A recent essay in a series on durable moats holds Palantir up as the template, casting the ontology, accumulated through years of on-site engineering, as the defensible asset that AI-era startups should now race to build inside their own customers (FounderCoHo, 2026). As advice to vendors, I think it is broadly correct, and that is exactly why it should stop enterprise architects mid-coffee.
Read the same claim from the other side of the table. The moat is not the vendor’s algorithms. The moat is a machine-readable description of your operations, extracted from your subject-matter experts, refined against your edge cases, on your payroll’s time. When a platform’s defensibility is defined by how much of your meaning it has captured, the polite word for that is partnership. The accurate word is leverage.
Workflow lock-in is dying, semantic lock-in is replacing it
For twenty years, SaaS retention rested on two things: workflow habit and migration pain. Both are collapsing at once. Coding agents have gutted the cost of the unglamorous work that used to make replatforming a two-year programme, the schema translation, the connector rewrites, the dual-running reconciliation that nobody budgets for and everybody pays for. And data portability has hardened from courtesy into law. Regimes such as the EU Data Act oblige providers to remove obstacles to switching and to hand over exportable data in a structured, machine-readable format (European Parliament and Council, 2023).
So the tables come with you. Here is what does not, unless you engineered for it: the object model that says a rebuild and an overhaul are different events with different warranty consequences. The link that ties a specific invoice line to a specific contract rate table. The action definition that says who may write off a variance and above what threshold a second approval kicks in. The validation logic encoding ten years of hard-won exceptions. None of that is “your data” in the export-a-parquet-file sense. It is your meaning, and in most platforms it is expressed in proprietary configuration that has no life outside the walls.
That is the substitution under way in the AI era. Vendors can no longer hold your rows hostage, so the compounding asset moves up a layer. Every workshop where your maintenance planners explain the difference between a failure and a defect to a vendor’s deployed engineers, every bespoke pipeline that encodes a rule your own wiki never captured, deepens a semantic dependency that a data export will never discharge. You can leave with your tables and still be unable to leave, because the map of what the tables mean stays behind.
The stakes compound from here. That same map is what grounds your agents, pins their behaviour, and generates your compliance evidence. Surrender it and you have not just made switching expensive. You have made someone else the landlord of your determinism, your accuracy, and your auditability.
Notice what actually trapped you in that scenario. Not the platform. The location of the definitions. Meaning that exists only as someone else’s configuration is meaning you have already surrendered. Which points directly at the counter-move: put the definitions somewhere you control, in a form any platform can consume.
What owning it actually looks like
This is not an argument for refusing the platforms. Ontology-driven platforms are productive precisely because the pattern works, and I will not pretend otherwise. The argument is about what you bring to them. Author the ontology yourself. Version it, govern it, and let platforms compile it. Never accept it as a by-product of a deployment, recoverable only by re-running the workshops.
Concretely: the master copy of your semantic layer lives in a repository you control, in a neutral, boring format, reviewed like code. It does not need to be clever. It needs to be explicit. For a model risk domain in a bank, the skeleton fits on one screen.
entities:
FinancialModel:
keys: [model_id]
properties: [purpose, tier, owner_desk, last_validated] # tier: 1 | 2 | 3 by materiality
ValidationReview:
keys: [review_id]
properties: [outcome, review_date, open_findings]
ModelChange:
keys: [change_id]
properties: [category, submitted_date, status] # category: recalibration | methodology | data_source
MarketDataFeed:
keys: [feed_id]
properties: [provider, asset_class, snapshot_frequency]
relationships:
- FinancialModel owned_by TradingDesk
- ValidationReview assesses FinancialModel
- ModelChange applied_to FinancialModel
- FinancialModel consumes MarketDataFeed
actions:
approve_model_change:
target: ModelChange
guard: latest_validation_outcome == approved && open_findings == 0
authority: model_risk_officer
grant_production_use:
target: FinancialModel
guard: months_since(last_validated) <= 12
authority: head_of_model_risk
audit: mandatoryListing 1. A fragment of a vendor-neutral ontology for a financial services model risk domain: entities, relationships, and permitted actions, in plain YAML under version control.
Nothing in that fragment is sophisticated. That is the point. A head of model validation can read it and object to it, which is the property that matters most. From a file like this you can generate platform configuration, warehouse semantic models, API contracts, agent tool definitions, and access policies. When you change vendors, the file comes with you and the regeneration is mechanical. The workshops do not have to be re-run, because their output was never trapped in a console.
Now run the three failure modes against it. An agent whose tools are compiled from this file cannot hallucinate a fifth entity type; it can approve a model change that exists or fail loudly, because the entity register bounds what it may talk about. Its behaviour stops drifting between runs, because the guard on approve_model_change is a versioned expression, not a paragraph of prompt the model interprets differently on Tuesday; the judgment lives in the file, and the model’s job shrinks to invoking it. And when the auditor arrives, authority: head_of_model_risk and audit: mandatory are not aspirations in a policy document. They are enforced properties of the system, with the trace to prove it. Grounding, determinism, evidence: one artifact, three failure modes retired.
Three disciplines follow from treating the ontology this way. First, the neutral form is written before the platform is configured, not reverse-engineered afterwards; if a definition exists only inside a vendor tool, it does not exist. Second, changes go through review by the people who own the business concept, not just the people who own the pipeline, because an ontology nobody disputes is an ontology nobody read. Third, exportability of semantics becomes a procurement gate: ask the vendor to demonstrate, before signature, how object types, links, action definitions, and their guards leave the platform in a documented format. The demonstration is more informative than the answer.
The important bit
Enterprises do not drift into renting their ontology out of stupidity. They drift into it because extracting a real ontology is slow, contested, and politically expensive. It means adjudicating between the plant’s definition of downtime and finance’s definition of downtime in a meeting neither side enjoys, with a decision at the end that one of them will resent. A vendor’s deployed engineers solve a problem your org chart cannot: they are paid outsiders with the standing to sit in that argument until it resolves, and no career at stake in the outcome. Look past the software and that is a large part of what the invoice buys. Arbitration, packaged as engineering.
Buy it if you need it. It is often worth every dollar. But contract for the output, not just the relief. The resolved definitions, the entity registers, the action guards, the exception logic: name them as deliverables, in the neutral form, landing in your repository as they are produced. The vendor keeps the generalisable patterns, as vendors always will. You keep the specific asset your people’s time created. That is the difference between hiring a facilitator and donating your institutional knowledge to someone else’s balance sheet.
The founder-side essays are right about the destination. Durable advantage now accumulates in meaning, not storage, and whoever holds the authoritative description of an operation holds pricing power over everyone who needs it. Those essays simply address the party that hopes to hold it. I am addressing the other party. Your organisation has spent decades learning how it actually works, and most of that knowledge still sits in the heads of people who are very good at their jobs and very close to retirement. Turning it into explicit, versioned, portable form is the most valuable data engineering your team can do this decade. It is the same artifact, remember, that retires the three failures filling your post-mortems: it grounds what your agents may assert, fixes what they may do, and proves both to anyone who asks. Where that artifact lives when the work is done decides who banks the value.
Build the map. Let the platforms render it. Never let them own it.
References
European Parliament and Council (2023) Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data (Data Act). Official Journal of the European Union. Available at: https://eur-lex.europa.eu/eli/reg/2023/2854/oj (Accessed: 10 July 2026).
FounderCoHo (2026) How ontology became a moat: Palantir’s FDE model, demystified. Substack, 8 July. Available at: https://foundercoho.substack.com/p/how-ontology-became-a-moat-palantirs (Accessed: 10 July 2026).
Gruber, T.R. (1993) ‘A translation approach to portable ontology specifications’, Knowledge Acquisition, 5(2), pp. 199-220.
Palantir Technologies (2024) Palantir reports its fifth consecutive quarter of GAAP profitability; fourth quarter GAAP EPS of $0.04. Business Wire, 5 February. Available at: https://www.businesswire.com/news/home/20240203047330/en/ (Accessed: 10 July 2026).
Palantir Technologies (2026) Ontology overview, Foundry documentation. Available at: https://www.palantir.com/docs/foundry/ontology/overview (Accessed: 10 July 2026).
Ryseff, J., De Bruhl, B.F. and Newberry, S.J. (2024) The root causes of failure for artificial intelligence projects and how they can succeed: avoiding the anti-patterns of AI. RAND Corporation, RR-A2680-1. Available at: https://www.rand.org/pubs/research_reports/RRA2680-1.html (Accessed: 10 July 2026).