AI Trend Research
EN

← Deep dives

Deep dives · 2026-11-04 · Advanced · By bombong

Ontology: Hype vs. Reality — Moat or Fad, and What to Weigh Before Adopting

Ontology is becoming a standard feature of large data platforms, so the concept itself no longer sets anyone apart. This final part separates hype from real value, compares semantic layers, knowledge graphs and platform ontologies, and sets out a checklist for starting small.

Contents
Key points
  • Microsoft Fabric IQ includes ontology (preview) as a core item, and the dbt Semantic Layer connects metrics to AI tools through an MCP server. What remains a differentiator is therefore not the concept of ontology but who owns the definitions and keeps them up to date.
  • The 'hype' is the expectation that agents will act correctly on their own once an ontology exists, the single enterprise-wide model, and the habit of leaving maintenance costs (the 'ontology tax') out of the calculation.
  • The 'reality' is defining business terms once, giving agents rules and context, and keeping the data lineage that regulators require continuously up to date. Actually enforcing the rules, however, is the job of a deterministic execution layer.
  • Failure usually comes after the build, not during it. Typical patterns are graphs with no owner, the urge to expand scope to the whole enterprise, and static artifacts built once and then abandoned.
  • Start with one use case and a list of questions it must answer. Expose only entities with stable definitions and clear owners, and set an update cycle from the start.

Wrapping up the series: questions left by Parts 1–3

This is Part 4, the final installment of the 'Ontology: Hype vs. Reality' series. The previous three parts looked at what an ontology is, why companies want one, and what uses and costs arise in heavily regulated sectors such as finance. Part 3's conclusion can be summarized as follows. Grouping customers and products, which each system defines differently, under shared concepts has clear benefits. But those benefits come only in proportion to the cost paid in mapping, terminology management and accountability structures. So it is better to start small, with one business process or one report.

This part generalizes that conclusion. There are three questions. First, once ontology, long seen as Palantir's signature, becomes a standard feature of general-purpose data platforms, what remains as a differentiator? Second, among the expectations around ontology, which are hype and which are real value? Third, should our organization adopt one, and if so, where should it start?

This article does not recommend any particular product. The comparisons and checklist below are criteria to weigh equally whichever platform you choose.

The competitive landscape: when ontology becomes a standard feature

Microsoft presents Fabric IQ as part of an 'enterprise intelligence layer.' Fabric IQ consists of two core items. One is the ontology (marked as preview in the documentation) and the other is the Power BI semantic model source. According to the documentation, the ontology defines entity types, properties, relationships, rules and metrics and binds them to real enterprise data. People, applications and AI agents then use the same vocabulary sourcesource. The ontology is not a separate data store. It is a 'virtual context layer' that holds only definitions and bindings, and actual queries run on the source data systems source. Ontologies can also be created from existing semantic models, and open standards such as RDF and OWL can be imported source. The previous ontology experience is announced to be retired on January 31, 2027 source. This means the feature is still changing quickly.

The same trend appears on the semantic layer side. The dbt documentation explains that moving metric definitions from BI tools into the modeling layer lets every department use the same definitions. It also states that when AI tools such as Claude and ChatGPT connect to the Semantic Layer through the dbt MCP server, they use governed metrics instead of guessing at raw tables source. In effect, products at several layers now share the promise of 'giving agents business meaning.'

In this situation, the concept of ontology alone does not create a moat. A blog post source by database engineer Vonng makes a stronger claim: Palantir's Ontology is technically database modeling (object types = tables, links = foreign keys), and its real moat comes from elsewhere, such as political networks, security clearances and forward deployed engineers (FDEs). This should be read as one critic's argument. Still, the practical lesson is clear. Once a concept becomes generic, the differentiators that remain are an organization's ability to actually agree on and maintain definitions, the quality of its connections to source systems, and the people who do that work.

Where a platform ontology sitsSource data → Ontology(Binding); Semantic model → Ontology(Generate · align); Ontology → Graph; Ontology → AI agents(Context); AI agents → Source data(Query execution)Source dataLakehouse · warehouseSemantic modelMeasures · KPIsOntologyEntities ·relationships · rules· metricsGraphOptionalAI agentsDashboards · appsBindingGenerate · alignContextQuery execution
Where a platform ontology sits Structure drawn based on the Fabric documentation. The ontology does not copy data; it stores only definitions and bindings. Actual queries run on the source systems.

Comparison: semantic layers, knowledge graphs and platform ontologies

A Thoughtworks article source treats schemas, controlled vocabularies, semantic layers, ontologies and knowledge graphs as a single continuum. Moving up the continuum increases expressiveness. In exchange, cost and governance burden grow, and someone has to take active ownership. The article distinguishes the ontology as the 'blueprint (classes, relationships, rules)' and the knowledge graph as 'that blueprint filled with real data, the thing agents actually query.'

Looking first at purpose, the differences are clear. Semantic layers are strong at standardizing metrics and definitions. However, they are limited in capturing the relationships or logic an agent would follow source. Build cost is relatively low, and maintenance is usually handled by the data team as modeling code. Ways to connect agents already exist, such as dbt's MCP server source. Knowledge graphs are strong at multi-step relational reasoning. But because entity resolution (finding and merging records for the same thing) and relationship extraction must be done continuously on real data, they carry the heaviest maintenance burden sourcesource. Platform ontologies (the Palantir type, Fabric IQ) bundle definitions, rules, metrics, bindings and graphs inside one platform. They are easy to start with but assume that platform's data foundation. The Microsoft documentation source also states that you cannot start at the IQ layer without a unified data foundation.

Lock-in risk needs to be weighed separately. Vonng's post source cites the 2017 case in which the New York City Police Department, when ending its relationship with Palantir, publicly complained that it could not obtain its analysis results in a portable format. By contrast, the Fabric documentation states that open standards such as RDF and OWL can be imported source. So before signing a contract, check whether definitions can be exported in standard formats and whether rules and metrics are locked inside a specific engine. Thoughtworks source notes that graph databases, data catalogs, master data tools and semantic layer platforms already cover parts of this area, and recommends deliberately deciding 'where building your own model is better than configuring the tools you already have.'

The 'hype': four inflated expectations

First is the expectation that 'once you build an ontology, AI will do the work on its own.' Thoughtworks source draws a line: an ontology does tell an agent what is allowed before it acts, but that is only knowledge, not enforcement. Rules become binding only when a deterministic runtime checks them, acts on the result, and can show that the check took place. Many operational rules, it argues, belong in a policy engine. The same goes for retrieval quality. The value comes from a graph filled with real data, not from the schema. The blueprint is the relatively easy part.

Second is the single enterprise-wide model. Thoughtworks source calls the enterprise master model 'a boil-the-ocean trap with a tidy name.' It points out that projects trying to model all of reality usually end after about a year without showing value. An Atlan article source likewise writes that a graph trying to abstractly represent 'the entire business' has no stopping point and no clear owner.

Third is the habit of leaving maintenance costs out of the calculation. Atlan source calls the cost of ongoing schema management the 'ontology tax.' Citing a 2026 roundup by Improvado, it also reports that fewer than 15% of enterprise knowledge graph projects get past the pilot stage. Fourth is data modeling marketing under a new name. As Vonng source points out, data modeling and system integration are genuinely valuable work. The problem is crediting that value to the word 'ontology.' The first line of defense is to ask concretely how a feature a vendor calls an 'ontology' differs from existing schemas and semantic models.

The 'reality': three lasting sources of value

The first is a single definition of business terms. An example from Microsoft training material source makes this easy to grasp. The sales team's 'customer' includes resellers, while the service team's 'customer' means only direct buyers. A data agent querying both models then cannot tell which definition to use. An ontology solves this by declaring one agreed definition that all semantic models follow. Things that are meaningful only inside a report, such as date filters or calculated columns, stay in the semantic model. Thoughtworks source stresses that this value comes less from the mapping itself than from the agreement behind it and from ownership that keeps it updated as meanings change.

The second is the context of rules, metrics, permissions and auditing that agents need when they act. According to the Fabric documentation source, rules can be written in natural language and attached to entities. This removes the need to copy the same business instructions into every prompt, agent and app. Metrics are brought in while the source semantic model keeps ownership, so agents use the calculations the organization has defined instead of inventing new formulas. Permissions and lifecycle are managed through Fabric's permission system. Changes by the ontology agent follow a 'proposal-first' approach and are applied only after human review sourcesource. As the previous section showed, however, a separate mechanism is still needed to actually block and log execution source.

The third is data lineage for regulatory compliance. A DataHub article source cites the Basel Committee's November 2023 progress report. Of the 31 G-SIBs (global systemically important banks) assessed, only 2 fully met all 14 principles of BCBS 239. The report noted that many banks still lack a common taxonomy and complete data lineage. The article also reports that the European Central Bank finalized its guide on risk data aggregation and risk reporting (RDARR) in May 2024. Its key point is that a lineage diagram drawn once for an audit goes stale before the next review. Lineage can serve as audit evidence only if it is continuously updated from real operational metadata. The article argues that the same lineage foundation also serves AI agent governance, but this should be read with the understanding that it reflects the view of a lineage tool vendor.

Failure patterns and responses

Atlan source observes that enterprise knowledge graphs rarely fail at the build stage. They collapse afterward, along three overlapping lines. On the organizational side, there is no owner, scope or sponsorship. On the technical side, ontology drift, schema rigidity and Entity Resolution failures appear. On the economic side, the ontology tax becomes a problem. The common cause is that the graph was left as a static artifact filled in by hand, rather than kept as a layer that is continuously updated on top of governed metadata. In a 2025 survey cited by the article, 67% of abandoned projects named a lack of in-house graph expertise as the main cause. The article reads this as meaning 'not so much that the skills were missing, but that no one was assigned to keep the graph populated.'

The remedy for an ownerless graph is to treat ownership like a product. Thoughtworks source recommends treating the ontology as 'a product, not a project.' This requires decision rights over disputed terms, version control, a fixed cadence for reconciling with systems of record, and a process for retiring concepts that are no longer useful. It warns that without stewards and regular reconciliation, the model goes stale within two quarters.

Scope creep is handled by limiting scope to a single use case. Thoughtworks source estimates that the traditional approach of building an enterprise-wide model all at once takes 12–24 months to deliver value. By comparison, a product approach that starts from one high-value use case takes 4–8 weeks per iteration. Atlan source relays practitioner reports that once there are more than 10–15 source systems, a break-even point arrives where entity duplication and schema mismatches make integration fragile. The problem of graphs left as static artifacts is handled by setting an update cadence and an owner to catch drift. When a table is renamed or customers are merged in the CRM, no error is raised. So without defined validation, the graph quietly returns incorrect facts source.

Adoption checklist and a 90-day starting sequence

The first question in deciding whether to adopt is, in Thoughtworks' source words, not 'Do we want an ontology?' but 'What is the minimum semantic structure that solves the problem in front of us?' The article holds that a well-managed semantic layer and thorough metadata already deliver much of the value needed for analytics and search. It names multi-step reasoning, automated constraint checking and cross-domain integration as the areas where an ontology justifies its cost. So if the current problem is 'every department has a different revenue number,' it makes sense to start with a semantic layer. If it is a question that can only be answered by following relationships, such as 'order → shipment → temperature sensor → cold-chain breach' (the example in w1), a graph and ontology are worth considering.

The sequence for starting small is as follows. The article treats the first 90 days as a single validation period. 1) Pick one business use case and have the business side write down, themselves, the questions the current systems cannot answer. Thoughtworks source makes this a condition for budget approval and recommends tying each question to a decision or a monetary amount. If no questions can be produced, the issue is not a missing semantic structure but unclear value. 2) Select entities. Publish only those whose definitions are stable, that several teams need and that have a clear owner source. 3) Use an LLM to draft from existing schemas, semantic models and wikis, and have experts only review source. People must check the names, keys and relationship directions in auto-generated output source. 4) Bind to source data and test the answers with real questions. Each product, such as Fabric, has its own data-binding requirements, so check them in advance. According to the training material source, answering directly from bound data requires Direct Lake mode, while Import and DirectQuery modes support definitions only. 5) Set an update cadence and an owner for drift checks, and run through to the first scheduled check.

At the end of the 90 days, check three things. How many of the questions written down at the start can now actually be answered? Have cross-department numerical discrepancies for the same term decreased? When a source system changed, who fixed the definition, and within how many days? If no one can answer the third question, the ownership structure must be rebuilt before the scope is widened.

90-day starting sequence

  1. 1
    Question listUnanswerable questions, written by the business side
  2. 2
    Entity selectionOnly stable definitions with clear owners
  3. 3
    Draft generation · reviewLLM draft, expert review
  4. 4
    Binding · testingCheck answers with real questions
  5. 5
    Update cadenceAssign a drift-check owner
A sequence that starts with one use case and runs once through to the update cadence.

Pre-adoption checklist

Need

  • Does the question require following relationships?
  • Is a semantic layer not enough?
  • Is each question tied to a decision or amount?

Ownership

  • Does each term have a definition owner?
  • Are decision rights for disputed terms set?
  • Is there an update cadence and an owner?

Control · portability

  • Is there a separate execution layer that enforces rules?
  • Do people review changes?
  • Can definitions be exported to open standards?
Items to check the same way whichever platform you choose.

Further reading

To get a map of the concepts first, the Thoughtworks article source is the best place to start. It covers, in one piece, the continuum from schemas to knowledge graphs, the three causes of failure and the five principles of the product approach. Next, use the Atlan article source to see what breaks down after the build, along three lines: organizational, technical and economic.

What a platform ontology actually does can be seen in the Fabric IQ overview source and the ontology overview source on Microsoft Learn. The training module source briefly covers what to put in the ontology and what to leave in the semantic model. Reading the dbt semantic layer documentation source alongside it as a point of comparison clarifies the roles of the two layers.

A critical perspective is in Vonng's article source, and the regulatory requirements for lineage are in the DataHub article source. Both authors have clear positions (a critic and a tool vendor), so it is best to read their claims separately from the facts they cite. This concludes the 'Ontology: Hype and Reality' series. In one sentence: the value of an ontology comes not from the vocabulary but from the people and processes that maintain the definitions.

Related terms

Semantic layer Knowledge graph Ontology Data lineage Data governance Entity Resolution MCP GraphRAG

References

Further reading (official docs and engineering posts)

Written by AI from the listed references and reviewed. Please check the original sources for details.