The Ontology Goes Native: What The 2026 Platform Shift Really Means

Summary:

• Enterprise ontologies are becoming platform-native. Databricks, Microsoft, Snowflake, SAP, Salesforce and ServiceNow are embedding semantic and ontology capabilities directly into their platforms to provide AI agents with business context.
• AI needs meaning, not just data. Semantic layers help agents understand business definitions, relationships and rules, reducing the risk of inaccurate outputs caused by ambiguous or inconsistent data.
• Harvesting is not reconciliation. New tools can generate candidate ontologies from existing data and assets, but aligning definitions, resolving inconsistencies and meeting industry standards still requires human governance.
• The next challenge is cross-platform context. Most ontology capabilities are strongest within a single platform, leaving enterprises to solve how meaning is reconciled and shared across complex, multi-platform technology estates.

Introduction

Through 2026, the major analytics platforms have all been heading in the same direction. Databricks, Microsoft and Snowflake have each added an ontology or semantic layer as an important new capability, and the same idea is now appearing across the wider enterprise software market at SAP, Salesforce and ServiceNow. These capabilities sit at very different levels of maturity, so this is not a product comparison. It is about what the collective shift reveals: enterprise ontologies are moving from bespoke artifacts to platform-native capabilities.

The old way was top down. You started from an industry reference standard, Financial Industry Business Ontology (FIBO) in banking, The Association for Cooperative Operations Research and Development (ACORD) in insurance, MortarCAPS in higher education and decided what your enterprise semantic model should look like, possibly aligned to that standard but augmented to suit your own needs and business reality, and then bound it to your data.

The new platform capabilities invert this. Rather than starting from a standard, they harvest meaning from what you already have and surface it as a candidate ontology built from your existing data, artifacts and assets.

What follows explains that shift and then takes on the two questions clients raise almost the moment they understand it:

1. “Can these tools actually bridge the gap between our current inconsistencies and a future standard, or do they simply encode the mess they find?”
2. “How far do they reach beyond their own platform, given that larger enterprises almost always run on more than one?”

This is, in short, is a look at what is being sold as the easy solution to a complex challenge, and at what still has to fill the gaps.

The Shift in 2026

The pattern is hard to miss. Within weeks of one another, Databricks shipped Genie Ontology, Microsoft shipped Fabric IQ, and Snowflake brought together Horizon Context with Cortex Sense and its semantic views. The same idea then surfaced across the broader market, with SAP's Knowledge Graph, Salesforce's AI Context inside its Agentforce and Headless 360 architecture, and ServiceNow's Context Engine all building something equivalent, or at least something similar.

The offerings vary a lot in maturity, and it would be premature to look too closely into any of them. What matters is the shared thesis underneath all of them: the most valuable enterprise AI asset is not the model, and it is not the raw data. It is the layer that tells agents what the data means.

Why This is Happening Now

AI agents read, reason and act differently from a person clicking through a dashboard. A human brings years of context to a report and quietly fills in the gaps. An agent does not, and raw schema alone does not give it enough to work with. Without a semantic layer, agents fabricate business logic, because a term like "total sales" means different things to different teams, and the agent has no way of knowing which meaning you intended.

This is also why the role of ontology and semantics is changing. Data dictionaries, business glossaries and ontologies were long treated as documentation: useful, tidy and firmly in the back office.

With agents in the loop, that same semantic definition stops being documentation and becomes a live, load-bearing component. If it is wrong or missing, the agent gets the wrong answer.

The problem is that “just clean the data” addresses the symptoms, not the underlying issue. Our data systems can tell an agent what exists and what has happened, subject to the usual quality caveats. What they rarely capture completely is the business context: why something happened, how the organization interprets it and which rules should govern the next action.

That knowledge is distributed across code, processes, workflows and people’s heads. Without it, an agent fills the gaps with an intelligent guess. The problem is therefore not simply that the data needs fixing. The data needs explaining. That is the job of a semantic or ontology layer.

The Old Paradigm: Specification First, Top Down

In the past, you took the standard as your skeleton, aligned your enterprise semantic model to it, augmented it for your own business reality and then bound it to physical data.

Meaning was authored first, against an external blueprint, largely independent of the data that would eventually populate it. The standard did double duty. It was both the starting point and the quality bar, so you inherited a degree of rigor simply by beginning from something that had already been well thought through. Whether “well thought through” always amounted to “correct” is a fair question, but the direction of travel was clear: design the meaning, then bind it to the data.

Even the top-down world is now in motion. In mid-2026 Databricks introduced Vibe Data Modeling, which generates a governed model from a plain-English description of your business rather than from a standard, on the argument that a generic industry template is the average of a sector and so nobody's actual business. It is neither specification-first nor a pure harvest, but a third path, prompt-first generation and a sign that every side of this discipline is being reworked at once.

The New Paradigm: Data-First, Bottom Up, Harvest and Surface

The platforms reverse that original top-down direction. Instead of starting from a standard, they start from what you already have and induce a candidate ontology upward. Fabric IQ generates ontologies from your existing Power BI semantic models and schemas. Genie Ontology extracts and continuously updates business knowledge from connected data and applications. The input, importantly, often includes your existing curated semantics rather than starting from raw data alone, so years of prior BI and semantic modeling work become a seed asset rather than something now made obsolete.

The honest description of what these platforms do is that they harvest meaning from your existing assets and surface it as a candidate ontology. Their own language gives the game away. It is dominated by automatic extraction, and where a harder verb like “resolve” does appear, it turns out to mean automated tie-breaking between sources, not reconciling the business disagreement underneath. The work of reconciling conflicting definitions, and of aligning to an industry standard, stays with the human. The vendors concede this when they describe definitions as “co-curated by humans”.

That word “harvest” is doing deliberate work. These tools harvest, and they surface. The verbs that describe the harder job - reconcile, resolve, align - are conspicuously absent, and that absence is the whole point of the next section.

Discussion Points

1. The Bridge They Do Not Cross

Start with what the data layer can and cannot reliably provide. A harvest will readily identify the nouns of the business, such as “client” and “policy”. It may also identify declared relationships between them. But the verbs, that a client holds a policy, that the policy was underwritten and later endorsed, are harder to recover with their meaning intact.

Evidence of those actions may exist in foreign keys, state changes, transactions or event histories. What the data often does not reveal is what the relationship means, why the action occurred or which business rules governed it. That context is distributed across systems, transformations, processes, workflows and people. A harvest can therefore recover the entities and some of their links, but the nature and meaning of those links often have to be inferred or supplied by a human.

The harvest is also bounded by the modeling decisions already baked into your data. Fabric IQ, for instance, can infer relationships from relational foreign keys. But formal foreign-key constraints are often absent from de-normalized datasets, wide tables and Lakehouse layers, while relationships in star schemas may be represented in the semantic model rather than enforced in the underlying data. Relationship harvesting can therefore degrade quietly where those relationships are neither physically enforced nor explicitly represented, and no tool can recover a relationship that the data model has already discarded.

A separate concern with a data-first approach is that it faithfully harvests existing inconsistencies. If three teams define “active customer” three different ways, the induced ontology may encode all three. But divergent definitions across domains are not automatically a failure. You want finance’s meaning of revenue when working within the finance domain, and forcing every team to adopt a single global definition is usually the wrong move. Within a domain, faithful local semantics are a strength, not a defect.

The reconciliation problem only really bites at domain overlaps and at the enterprise level, where one term has to carry one agreed meaning across boundaries. A harvest that encodes three definitions of “active customer” is only a problem if you need a single enterprise answer that spans all three. Inside each domain, all three can be perfectly correct.

That points to a layered answer, and to a principle I would put above the technology: use the least complex solution that meets the use case reliably, and do not boil the ocean. In practice that means four levels, reached for only as far as the problem demands. Most data products already have a semantic layer. When that is not quite enough, a light “semantic-plus” extension, provided privately to the LLM through context files, is often the first move. Where a data product needs its language and relationships captured properly, a bounded ontology does that within the context of that one domain, faithful to how the domain actually speaks. And only where domains overlap do you add an enterprise ontology on top, navigating between the bounded domains and providing enterprise context where, and only where, it is genuinely needed.

This reframes reconciliation entirely. You are not flattening every domain into one master model. You are preserving bounded local ontologies and adding an enterprise layer above them only at the seams.

With that shape in mind, the industry standard does not disappear under the new paradigm. It relocates. It moves from being the blueprint you start from to being the validation and alignment layer you reconcile the induced ontology against. The platforms help prevent new drift, through governed definitions, data quality checks and provenance, but they do not reconcile your model to an external standard. There is no known native FIBO, ACORD or MortarCAPS mapping capability today, and even importing an existing business glossary is largely manual. Crossing the bridge - from an inconsistent current state to a standard-aligned target state - remains a human, governance-led act of judgement.

The trap to flag for clients is that the ease of the harvest step can crowd out the harder reconciliation discipline. “We have an ontology now” quietly gets mistaken for “we have a correct, standard-aligned ontology”, and those are not the same claim.

More importantly, alignment is not the same as fitness for purpose. Even a model that aligns cleanly with FIBO does not guarantee that the LLM will return the right answer. I have seen cases where loading a catalog that matched the data model actually made the agent’s answers worse. It was structurally aligned, but it did not help the agent reason. “Aligned to the standard” must therefore never be mistaken for “correct and useful”.

This raises the question that really matters: how do you know an ontology is actually correct, or fit for purpose?

Increasingly the honest answer is empirical. You test the agent's answers for accuracy and completeness, rather than trusting structural alignment on its own to tell you the job is done.

2. Platform Versus Enterprise Reach

There is a pattern in client conversations that is almost too consistent to be a coincidence. Clients grasp the use case immediately, and then, within a minute or two, they ask about platform independence.

They are right to. Each ontology is strongest inside its own walls, and the analyst framing is blunt: the context layer follows data gravity. Most enterprises will adopt the layer that matches where their data already sits. The boundary is explicit in the products themselves. Snowflake's context is confined to data inside Snowflake unless you first ingest the external data. Genie Ontology learns from Databricks and its connected applications, not from the whole estate. The meaning a platform can harvest is only ever the meaning visible to that platform. An ontology that stops at the platform boundary therefore risks recreating the very fragmentation it set out to solve, the AI era equivalent of data silos.

Approaches do differ in philosophy, and that caveat is important because the platforms are evolving quickly, but two camps appear to be forming on openness. Snowflake, Salesforce and ServiceNow lean towards portability and open access. Databricks, Microsoft and SAP lean towards keeping context inside their own ecosystem. A genuinely cross-estate context layer, one that spans Databricks, Snowflake, the Microsoft stack, the major SaaS systems and SAP, is the open frontier, and it is exactly where third-party vendors are now positioning.

Lineage Worth Acknowledging

None of this is entirely new. It is essentially the bet Palantir has been making for years with Foundry Ontology, binding data, business logic and actions into a single semantic model. The wider market is now chasing the same idea. That is both a validation of the concept and a reminder of how much work the phrase “enterprise-wide” really implies.

What This Means for Enterprises

In the years ahead, the organization with the best context layer may gain a larger AI advantage than the one with the most data. If that is right, two cautions follow:

• Harvest is the start, not the finish: Budget for the reconciliation work against your industry standard, or for other validation such as empirical agent testing for the accuracy and completeness of responses.
• Interrogate the platform boundary before you commit: Because your enterprise is almost certainly bigger than any single platform.

The technology to harvest and surface is largely here. Reconciling to what you ought to mean, and making meaning travel across the whole estate, are still yours to solve.

The closing implication is that the platforms alone are unlikely to be enough. You may still need to build or buy a capability that sits above them, one that reads the platform-specific ontologies and assesses them against your chosen industry standard, so that you can shape an enterprise model landing somewhere between the sum of the platform ontologies and the standard itself. That same capability is where you offload some of the reconciliation heavy lifting the platforms leave to you. A dedicated cross-estate capability would therefore have two jobs: reconcile meaning against the chosen standard and carry that meaning across platform boundaries.