Enterprise AI Ontology: Why the Definition and Runtime Should Be Open

The short version: this post argued in June 2026 that both the typed application definition and the runtime that executes it should be open. The industry has since conceded parts of that argument on its own. Palantir’s Ontology MCP went generally available the week of 16 June 2026 — four days after this published — making an ontology’s objects and actions callable by any agent over an open protocol; in August, Palantir began moving ontology definitions into a versioned repository. Three layers decide portability — interface, definition, runtime — and 2026 opened the first, started opening the second, and left the third exactly where it was. The runtime is the last closed layer, and it is the half of this argument still worth having.

Let me start with a story you have probably watched happen.

A company kicks off an “AI assistant” project. Week one, the demo is stunning: someone exports a copy of the customer data, feeds it to a model, and it really can answer “which accounts in the East region are at renewal risk?” Leadership sees it and immediately approves a bigger pilot.

Month three, it’s time to connect production data. The security team walks in and asks three questions:

• What data can the AI see? If sales rep A asks for “company-wide performance rankings,” will it reveal everyone else’s commissions?
• It’s going to take actions — change a discount, send a contract. Whose permissions apply? When something goes wrong, who is accountable?
• When audit asks “who approved this discount,” where is the record for the part the AI did?

The project team has no answers. Not because they didn’t try — because the architecture has no layer capable of answering those questions. The data is scattered across a dozen systems. Permissions live inside each application’s code. The rule for “discount approval” exists mainly in one senior employee’s head. The AI is staring at raw tables and raw endpoints, and no amount of intelligence can read a company’s rules from a place where they were never written down.

Month nine, the pilot quietly ends. The model didn’t lose on capability. It lost because nobody was willing to sign off.

The industry has a name for what was missing: an ontology — a structured, machine-readable semantic layer that explicitly defines what business objects exist, how they relate, who is allowed to do what to them, and where every action gets recorded. The last two clauses are what separate it from the two layers it gets confused with; ontology vs semantic layer vs knowledge graph draws that line precisely, and it is the reason a metrics catalogue could not have answered the security team’s questions either.

Palantir Turned This Idea Into a Category

The company that turned the ontology from a research concept into a commercial category is Palantir. It is worth looking honestly at why it succeeded: the fairer the look, the sharper the question that follows.

Palantir Foundry does two core things. First, it integrates an enterprise’s scattered data into a unified ontology: customers, equipment, and orders stop being dozens of tables and become typed business objects with relationships and properties. Second, it funnels every write operation through governed Actions — each one validated, permissioned, and fully audited. After 2023, AIP pointed this architecture squarely at large language models: the LLM never touches the database; it can only call governed tools exposed by the ontology layer. Models can be swapped. The boundary stays.

Why is it expensive? Because the problem it solves is genuinely expensive. Untangling twenty years of accumulated legacy systems into one clean ontology takes forward-deployed engineers working through those systems one at a time, reconciling concepts one at a time: labor-intensive engineering in the most literal sense. Its customers are governments, defense, banks, and energy companies, for whom “every AI step inside permissions, every step on the record” is a hard requirement with a budget to match. Contracts can reach the millions, and customers renew because the architecture answers the three questions a CISO cares about most. They are the same three questions from the opening story.

So Palantir’s success is not just proof of a sales machine. It is proof of an architectural judgment: for AI to enter the enterprise, a governed business semantic layer has to exist first. That judgment no longer needs defending — three more platform vendors have since shipped their own version of the layer, and the cell-by-cell comparison shows how far each one goes before it stops describing the business and starts changing it.

What needs rethinking is the next question: what form should this layer take? Because a few things are changing.

Software Is Increasingly Written by AI

The first change is the most visible: applications themselves are increasingly written by AI.

“Build a custom expense-approval system for a 50-person team” used to be economically absurd — the development cost outweighed the pain. Today an AI agent delivers it in an afternoon. Custom business software is going from a scarce good to a commodity, and total demand is about to explode.

Notice where it explodes: in the long tail. In teams that will never appear on any enterprise software vendor’s prospect list — no procurement process, no implementation budget, no POC review meetings. They just tell an agent to “build something that works,” and start using it the same day.

A model that runs on forward-deployed engineers and million-dollar contracts structurally cannot reach this market. That’s not a criticism; they are simply two different markets. But every system in this new market will slam into the same three security questions from the opening — except when it happens, there’s no forward-deployed engineer standing nearby.

The Next Technology Selector May Be an Agent

The second change is quieter but cuts deeper: the act of choosing technology is itself moving from humans to AI.

Ask an agent today to “build a customer management system,” and it will most likely reach for Next.js and Postgres. Why? Nobody bought ads inside the model. Those technologies are open, thoroughly documented, and massively present in its training data. The agent has seen hundreds of thousands of examples and has learned the common failure modes.

This creates something that didn’t exist before: for developer-facing technology, public protocol text and open-source code are now the distribution channel itself. The more open a protocol is — the more it gets discussed, the more code there is to learn from — the better the next generation of models understands it, and the more agents default to it. The loop feeds itself.

A closed platform has two ways out of that. The expensive one is to open the format, so models learn it and agents reach for it unprompted. The cheap one is to keep the format closed and adopt an open protocol at the edge — agents can then call the platform even though they still cannot learn it.

When this post first ran, it claimed a closed platform simply could not enter the loop. Within a week that was too strong: the incumbents took the cheap way out, and it worked. What survives is the narrower claim, and it is the one that matters — an interface an agent can call is not a definition an agent can learn from, and neither one is a runtime you can take with you. What the incumbents actually did about that — and the one thing they did not do — is below.

Wait, Haven’t Closed Platforms Won Before?

By now a serious objection should have surfaced: openness does not always win. The cloud era was won by AWS. Mobile was won by the iPhone. Both are controlled platforms.

The objection deserves a serious answer, because answering it exposes the actual pattern.

Look at how AWS makes money: it hosts Linux, Kubernetes, Postgres — open standards, all the way down. The iPhone is closed, but every packet it sends rides on TCP/IP and HTTP. Go back further: database vendors fought each other to the death while SQL, the language itself, stayed public; the container-orchestration wars ended with everyone running the same open OCI image format.

The pattern is remarkably consistent: the portable substrate an ecosystem depends on tends to end up open — both the definition and the baseline runtime that interprets it. Vendors still earn recurring revenue, but from the operated production experience: hosting, upgrades, security packaging, performance, support, and accountability. AWS itself is the biggest proof. Linux, Kubernetes, and Postgres remain open; AWS charges to operate them reliably.

A business semantic layer is a textbook case. Your object model, permission rules, approval flows, and the runtime semantics that enforce them will be depended on by your applications, your agents, and your audit systems. The more things depend on that substrate, the less either half should live inside one vendor’s platform. The definitions should be readable, version-controlled files in your repository, and a compatible runtime should be self-hostable and replaceable. An open file that only one paid engine can execute is not actually portable.

Enterprises spent twenty years liberating their data from one closed system after another. They should not spend the AI era locking up something even more fundamental — the definition of the business itself — all over again.

Ontology MCP Opened the Interface. The Runtime Stayed Shut.

That pattern got tested almost immediately, and the result is better evidence than the prediction was.

Four days after this post first published, Palantir’s Ontology MCP became generally available across Foundry enrollments, beginning the week of 16 June 2026 (Palantir’s documentation). Object types, action types and functions are projected into Model Context Protocol tools, so any MCP-compatible agent can read the ontology and set its workflows in motion with no integration code written per agent framework. Microsoft is previewing the same interface on Fabric IQ. How that projection works — and why the read half and the write half of an ontology behave nothing alike once exposed — is the subject of Ontology MCP and agent tools, and is not restated here.

Then, in August, Palantir shipped ontology-as-code in beta: object types, links, interfaces and actions declared in TypeScript in a monorepo, those code definitions being the source of truth. The cell-by-cell platform comparison sets that beside what Microsoft, Databricks and Snowflake shipped over the same nine months.

Put the two moves together and the substrate argument from the last section holds — but not for the reason it was written. The substrate is opening. It is opening because the incumbents opened it themselves, in the order that cost them least:

Layer	What it is	Where 2026 left it
Interface	How an agent calls the ontology	Open. MCP, adopted by the platform vendors themselves
Definition	The objects, actions and permissions	Opening in form. Declared as code in a repository — still materialised onto one vendor’s platform
Runtime	What executes an action and enforces the rules	Unmoved. No vendor shipped one you can run somewhere else

Read the third row slowly, because it is the entire argument.

An open interface makes an ontology callable. Definitions in a repository make it readable and reviewable. Neither one makes it runnable anywhere else. The comparison post states the limit in a single clause worth quoting: portability of the definition is not portability of the system — a monorepo of ontology code still materialises onto a Foundry enrollment. And because the tool surface is projected from the definition, whoever runs the projection decides what the tools are. A definition file does not execute anything by itself.

That is the number this refresh turns on. Apply Palantir’s documented projection rule to a mid-sized application — 12 object types, 30 action types, 6 exposed functions — and you get 37 MCP tools speaking an open protocol, with exactly one engine underneath that can answer any of them. The interface became portable. The dependency did not move an inch.

The strongest objection, stated fairly: most of what a team wants from portability is now on the table. You can read your model, review it as a diff, point any agent at it, and — for analytical semantics — exchange it through a vendor-neutral spec that reached the Apache Incubator in 2026. If your ontology only ever answers questions, that is close enough to enough, and this post would be dishonest to pretend otherwise.

The answer is the same line that separates a semantic layer from an ontology to begin with: it holds right up until something has to happen. The moment an exposed action changes a record, everything you actually care about — the permission check, the transaction, the approval above a threshold, the audit trail row — is a property of the engine, not of the file and not of the protocol. You can export the sentence. You cannot export the enforcement.

Call that gap the last closed layer. It is not an accusation; it is a description of where the category stopped. Two of the three layers opened in nine months, largely under their own momentum. The third did not move at all — because it is the one layer a platform business cannot open without changing what it sells.

What This “Definition” Actually Looks Like

Enough abstraction. Here is a sales-opportunity object in the ObjectStack typed application definition, abridged from a real example:

export const Opportunity = ObjectSchema.create({
  name: 'crm_opportunity',
  label: 'Opportunity',
  fields: {
    name: Field.text({ label: 'Opportunity Name', required: true }),
    account: Field.lookup('crm_account', { label: 'Account', required: true }),
    amount: Field.currency({ label: 'Amount', min: 0 }),
    probability: Field.percent({ label: 'Probability', defaultValue: 50 }),
    expected_revenue: Field.formula({
      label: 'Expected Revenue',
      expression: cel`amount * probability / 100`,
    }),
    discount_percent: Field.percent({ label: 'Discount %', max: 100 }),
  },
});

// Permissions are declared the same way: sales can read and write, never delete
export const SalesUser: Security.PermissionSet = {
  name: 'crm_sales_user',
  objects: {
    crm_opportunity: { allowRead: true, allowCreate: true, allowEdit: true, allowDelete: false },
  },
};

The point is not the syntax. The point is that these few dozen lines are the system. The open-source ObjectStack runtime reads this definition, derives the database tables, REST API, admin UI, and MCP tools, then enforces permissions and audit on every call. Discounts above 30% need finance approval? That’s a flow definition attached to this object: equally declarative, equally in version control. ObjectOS adds the commercial production experience around the same application — browser-based Build and Ask, team review and approval, managed cloud or private deployment, SSO, operations, and support — without turning the definition or execution engine into a proprietary dependency.

Three consequences follow directly:

1. The three security questions from the opening get structural answers. What can the AI see — it’s written in the permission set. Whose permissions apply when it acts — it acts as the signed-in user, enforced by the ObjectStack runtime, not pleaded for in a prompt. Where’s the audit trail — humans and agents write to the same ledger: who, what, when, why. Compliance reads one log, not two.
2. Business change becomes code review. The AI wants to add a renewal reminder? What it submits is a metadata diff — which fields changed, which permissions moved, all visible at a glance. And because definitions are versioned, mistakes roll back.
3. The whole system fits in one agent’s context window. A typical enterprise module collapses from tens of thousands of lines of CRUD and glue into a few hundred lines of declarations — small enough for an AI to read every dependency end to end, then safely refactor across data, API, UI, and permissions in a single change. That is the line between “AI as co-maintainer” and “AI as autocomplete.”

The Definition and Portable Runtime Belong to the Community; Operations Are the Business

Now the argument closes on itself.

The ontology judgment is correct — Palantir proved it for the whole industry. When this post first ran, “open definitions, exclusive paid engine” was a failure mode worth warning about in advance. Nine months later it is not a warning. It is a fair description of where the category settled, reached one reasonable decision at a time by vendors who opened everything except the part they sell. That makes the alternative easier to state, not harder: the typed business definition and a portable governed runtime belong to the open ecosystem; the paid product is the operated production experience around them.

That is the division of labor between ObjectStack and ObjectOS:

• ObjectStack is an open business ontology: the typed application definition together with the open-source runtime that executes it (Apache 2.0). Objects, relationships, permissions, flows, APIs, UI, and AI tools are defined once in your repository; the runtime derives the database, REST API, rendered UI, and MCP server, then enforces permissions and audit on every call. Both the definition and the engine are diffable, self-hostable, and portable — the second half being the one the rest of the category left closed.
• ObjectOS is the commercial production platform around those same ObjectStack applications. It sells the browser-based Build and Ask experience, team review and approval, managed cloud or private deployment operations, SSO, enterprise controls, and support. It is not a closed execution engine that takes the ontology back out of your hands.

On one side: an application definition and portable runtime any team or agent can understand, self-host, and take with them. On the other: the production experience enterprises genuinely pay for — collaborative authoring, approvals, hosting, private deployment, SSO, support, upgrades, and operational accountability. The application and its baseline runtime are yours. Operating them reliably for a team is the business.

Closing

That AI pilot that died in month nine never lost to model capability. It lost to the absence of a semantic layer a security team could sign off on. The industry has spent years proving how much that layer is worth, and 2026 spent nine months proving something narrower and more useful: the parts of it that were cheap to open are now open. The interface is a public protocol. The definition is a file you can read. What is left is the engine that turns the second into the first and enforces the rules while it does — and on that layer, nothing opened.

So the question this post asked in June has a sharper form now. Not “should the ontology be open?” — that is settled, and the vendors settled it. It is: when the last closed layer is the one that executes your business rules, whose engine do you want that to be?

If you want to test whether any of this is real:

npm i -g @objectstack/cli && os start

Five minutes from now, define your first business object — then watch the open ObjectStack runtime turn it into a database table, an API, an admin UI, and a tool an AI can safely call. Every call carries permissions. Every call writes the ledger. If your team wants browser-based Build and Ask, shared review and approvals, managed cloud or private deployment, SSO, and support, ObjectOS operates that same ObjectStack application; it does not replace it with a proprietary format or exclusive engine.