Open vs. Closed Enterprise Ontologies: Who Owns the Business Semantic Layer?

The short version: The business-definition layer that your apps, agents, auditors, and vendors all depend on should not belong to any one platform. It should be a neutral layer you hold in your own repository.

Start with how one company lost a customer over exactly this. The details are anonymized, but you have probably seen every step before.

Yuanfeng, the name we will give this industrial-equipment manufacturer, does a few billion in annual revenue and serves a few thousand customers. In 2024, it bet its data foundation on Microsoft, building a clean ontology in Fabric: what a “customer” is, which “devices” connect to a customer, and which “work orders” attach to each device. That year it became the model case repeated at vendor conferences.

In 2026, three things hit Yuanfeng almost at once:

The data-science team wanted to run a batch of renewal predictions on Gemini, because in that specific scenario it really was more accurate;
Compliance got notice that EU customer data had to stay in the EU and could no longer touch the US cloud;
An acquisition closed, bringing in an entire sales organization — several thousand customers — running on Salesforce.

So now Yuanfeng had three “customers”: one in Fabric, one in Salesforce, and one more in the compliance-isolated EU environment.

The turning point came over a key account we’ll call H Group. One day the sales director asked an agent, “How high is H Group’s renewal risk next year?” The agent answered, “Low.” It was reading the Fabric ontology, where H Group’s recent orders looked healthy and the numbers were pretty.

But what the agent didn’t see: in the Salesforce records (brought in by the acquisition), H Group had escalated complaints to the executive level twice in six months; in the EU-isolated environment, there was a 90-day-overdue payment dispute hanging open. Three sets of data belonged to three mutually unaware “customers,” and no layer anywhere knew they were all the same H Group.

A quarter later, H Group churned — millions in annual loss. The post-mortem was stark enough to leave the room silent: the agent had not technically erred. The slice of data it saw genuinely showed low risk. What was wrong wasn’t the model. It was the definition of “customer” beneath its feet, sliced into three.

This was not simply a Yuanfeng mistake. It is the predictable result of handing “the definition of your business” to a platform for safekeeping, when each platform only protects and understands its own slice.

Not an Isolated Case: Everyone Is Racing for This Layer

Yuanfeng’s predicament is common precisely because the whole industry is rushing toward the same layer at once.

A year ago, “business semantic layer” and “ontology” were still heavily associated with Palantir. Now the category is broadening. Analysts talk about semantic layers and knowledge graphs as infrastructure for agentic AI, and the major platform vendors are moving in: Microsoft with Fabric, Google with enterprise knowledge graph capabilities, and Palantir with Foundry and AIP.

Why now? Because agents exposed the weakness. The data pipelines of the last decade cared mostly about where the data flowed, not enough about what the data meant. There was always a human as the backstop. Agents have no such backstop: confronted with dozens of tables and “customer” fields defined a dozen different ways, they either answer incorrectly, as with H Group, or do not dare answer at all. Many agent pilots fail to reach production because this layer is missing.

So the three giants’ judgment is right, and remarkably aligned: for AI to reliably enter the enterprise, there must first be a layer of machine-readable, governed business definition. That point no longer needs arguing. What does need arguing is the next question: who should own this layer?

Three Right Directions, Three Different Locks

Lay the three approaches side by side and you find an awkward common thread.

	Where the ontology lives	Who can read it	Can you take it with you
Palantir Foundry	Inside the Palantir platform	On-site engineers + platform tooling	Bound to the platform; migration = rebuild
Microsoft Fabric IQ	Inside OneLake / Fabric	The 365 and Fabric ecosystems	Bound to the Microsoft stack
Google enterprise knowledge graph	Inside Google Cloud	The Vertex and GCP ecosystems	Bound to the Google stack

To be fair, each one does well on its own turf. Palantir’s ontology modeling quality is genuinely high. Microsoft connects the semantic layer with OneLake and Microsoft 365, which can be very smooth for an all-Microsoft company. Google has real depth in data scale and graph reasoning. They all help you organize your business more clearly, and then keep that clarity inside their own platform.

An experienced IT leader reading this might say: vendor lock-in again, same old problem.

But this time the main concern is not only lock-in. There is a worse problem: fragmentation. Before taking it apart, we should lay out the playbook by which closed platforms win, because it is not weak.

First, the Playbook by Which Closed Platforms Win

If all you can do is repeat “open is good,” that is preaching, not analysis. Closed platforms hold four real cards.

First, modeling quality. Turning twenty years of accumulated enterprise complexity into a clean, self-consistent ontology is heavy engineering. Palantir aligns it one concept at a time with on-site engineers, at a quality open-source communities cannot match quickly. With an ontology, building it badly can be worse than not building it at all.

Second, a single accountable party. When something breaks, someone picks up the phone, there is an SLA, and there is a contract behind it. For a CIO, “one vendor carries responsibility for the whole layer” has real value.

Third, a lot of companies really are “basically on one stack.” If 80% of your business already lives in one ecosystem, then “best within the ecosystem” may literally be the best option for you. The benefits of openness are harder to use if your business is not cross-system.

Fourth, integration depth. Within one ecosystem, data, identity, and permissions are all already there; the dirty work it spares you is measured in person-months.

All four cards are real. So the conclusion is not “closed platforms are all traps.” For companies that sit comfortably inside one ecosystem, they are often the right answer. The problem shows up in companies like Yuanfeng: the premise expires.

This Time, the Playbook Has a New Weakness: Fragmentation

With single-vendor lock-in, at least your business definition is still one complete copy — you just can’t move it. Painful, but whole.

Three giants each building closed ontologies produces something else: fragmentation. Yuanfeng’s “customer” was not merely locked up; it was sliced into three and stored in three mutually unaware platforms. This can be more painful than lock-in, because two mechanisms prevent it from healing on its own.

The first layer is incentives. You might think: just let Microsoft’s ontology understand Salesforce’s “customer,” problem solved. It will not be that simple, because each vendor’s ontology is part of its moat. If Microsoft unilaterally unified its “customer” semantics with Salesforce’s, it would help a rival move data more smoothly and reduce its own differentiation. Unification is strategically unattractive for every contestant in the race. This is not only technical oversight; it is rational platform behavior.

The second layer is technical. Even setting incentives aside, cross-ontology semantic alignment is hard: does System A’s “customer” equal System B’s “Account”? The field definitions, lifecycles, deduplication rules, and criteria for “the same entity” all differ across systems. AI cannot reliably infer this automatically either. Agents make mistakes precisely because this layer of definite definition is missing. Back to H Group: let the agent guess whether “these three records are the same company,” and the cost of guessing wrong is exactly the loss in the story.

Put together in one line: you thought you bought three tools; you actually bought three mutually unaware sources of truth. The more systems, the more acquisitions, and the more compliance isolation, the more severe this fragmentation becomes. The agent era amplifies the cost because a human can still manually reconcile across three systems, however painfully, while an agent needs one definite, cross-system-consistent layer of definition before it can reason.

To avoid fragmentation, the definition of your business cannot belong entirely to a platform competing in the race. It needs to be a neutral layer: a definition you hold yourself, that different vendors’ tools can read. Closed platforms structurally struggle to provide this, because they are contestants in the race and cannot also be neutral referees.

How to Tell You’re Being Fragmented

This is not abstract; it has concrete early symptoms. Check yourself against the list below. If three or more are true, fragmentation is already happening inside your company.

The same “customer / order / device” is defined differently across systems and doesn’t reconcile; every report requires manual stitching.
Ask an agent a cross-system question and it either equivocates or gets it half-right (saw one system, missed the other).
Every time you connect a new system, you have to re-teach the AI “what this is” and “what the fields mean.”
An acquisition closed over a year ago and the two sides’ master data still has not truly merged; each side reports its own version.
Compliance requires isolating a class of data, so the same entity is forced into several copies, none recognizing the other.

Before Yuanfeng lost H Group, four of these five were true. At the time, they were filed as “data governance to-dos,” and no one realized they were risks an agent would eventually expose.

First, Some Cold Water: Open Is Not a Silver Bullet

Pause here, because otherwise this turns into a sales pitch.

First, swapping the definition for an open protocol does not automatically merge Yuanfeng’s three “customers” into one. The semantic modeling, deduplication, and definition alignment still need to be done. There is no silver bullet here, and do not believe anyone who claims one. What open really changes is the ownership of this hard work: the definition you align today is written in your own repository, not buried in a platform backend. Next year, when you switch models, switch clouds, or get acquired, what you rebuild is the connection, not the definition itself.

Second, “open” itself does not guarantee winning. Historically, for an open standard to prevail, it usually also needs a good reference implementation and an active ecosystem. Publishing a protocol that no one makes pleasant to use will not be enough. So choosing open is a bet that someone will build it well. That is an execution risk, not a guaranteed win.

But note what these limits actually say: open also takes effort and carries risk. They do not say closed is always better. By comparison, the downside risk of locking your business definition into one platform, and then fragmenting it across several platforms, is larger and harder to reverse. Neither side is free; one of them keeps the core asset in your own hands.

Layers Everyone Depends On End Up Neutral

The pattern itself isn’t new, but it’s worth telling with fresh examples, because it keeps happening.

The “definition layer” that an entire ecosystem collectively depends on tends to become neutral. The oldest example is SQL: database vendors competed fiercely, yet the query language itself remained public. Two newer examples are OpenTelemetry, the observability data standard hosted by the neutral CNCF, and LSP (the Language Server Protocol), opened by Microsoft and adopted by many editors because it was open.

The LSP example is especially useful because Microsoft itself proved the pattern: opening the definition layer and competing on the best implementation can create more value than locking the layer down. The business semantic layer is the same kind of thing. In the future, it will be depended on simultaneously by your applications, your agents, your audit systems, and tools from multiple vendors. A layer depended on by so many parties cannot stay private to one of them without continuing to produce the kind of fragmentation Yuanfeng suffered.

What the Neutral Layer Looks Like

After all this, take a look at the real thing. The point is not the syntax; it is where the definition lives, whether you can take it with you, and whether it can pull the fragmentation back in.

Suppose Yuanfeng had originally built “customer” as one neutral definition: connect all three systems as datasources, model each as objects, then align them into one governed “customer” by a shared key (the tax ID) — a declaration in your own repo that is the single source of truth:

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Customer',
  fields: {
    name: Field.text({ label: 'Customer name', required: true }),
    tax_id: Field.text({ label: 'Tax ID' }), // a shared key to align "the same customer" across systems
  },
});

This definition lives in your Git repository: diffable, reviewable, migratable. What it can do next is the crux — turning “portable” into a demonstrable action, not a promise:

git add crm/*.ts          # The definition is in your version control: auditable, revertible
os start   # The same definition, running on your own infrastructure
# Then point any model at it — Claude, GPT, Gemini — the runtime doesn't change

Now ask the critical question again: “How high is H Group’s renewal risk next year?” The agent now sees one unified “customer,” with permissions and audit attached: healthy orders, overlaid with two executive-level complaints and a 90-day payment dispute. It answers, “High risk; recommend early intervention.” Same model, same question. Because the definition beneath it is no longer fragmented, the conclusion shifts from “lost millions” to “warned a full quarter early.”

This is the division of labor between ObjectStack and ObjectOS, and its answer to this race:

ObjectStack — the open protocol (Apache 2.0) for describing your business, living in your repository, readable by all three vendors’ agents;
ObjectOS — the runtime for that definition, running on your own infrastructure, enforcing permissions and recording audit.

The definition layer is neutral; the runtime layer is where products compete. It is the same relationship SQL has with database vendors, and LSP has with editor vendors.

Closing

This is not an ideological question of “open is good” or “closed is good.” It is a colder architecture question: when your vendor mix changes through multi-model adoption, multi-cloud strategy, acquisition, or compliance isolation, who is holding the definition of your business?

The major platforms have proved that this layer is worth building. They have also put the ownership question in front of every enterprise at the same time. Yuanfeng’s three “customers” were not a technical accident; they were the cost of handing the definition away. H Group, misjudged as “low risk,” was only the first bill.

A layer everyone depends on rarely stays with one company for long. There is no reason this one should be different.

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

Define your first business object, have its data come from two existing systems, then git commit it into your own repository. At that moment, the definition of your business is back in your hands, not in someone else’s backend.