Genie Ontology: A Real Knowledge Graph, or Mostly Clever Context?

On Reddit an architect asked a question that sounds short and is not: is Genie Ontology a real ontology or knowledge graph, or mostly marketing? And how does it compare to the Palantir Foundry ontology?

The question behind the question was more practical. The poster wanted to inspect the ontology and show colleagues how the knowledge graph is used. He wanted to be able to point out that an answer came together through customer, order, product and supplier, and therefore which relationships took part in the reasoning.

That is a fair requirement. Anyone who has to defend a semantic layer to an auditor or a risk manager ends up at exactly this question sooner or later. It is also where the confusion starts, because the word ontology sets an expectation that does not match what Databricks built.

The replies varied, but pointed the same way.

One participant noticed that answer quality had improved since the ontology came into play, without being able to say why. Another asked the obvious follow-up: if the ontology really takes part in the reasoning, should you not be able to see which relationships contributed?

Several replies described Genie Ontology as an automatically inferred ontology rather than something a business user designs. They consistently added that you can steer the underlying semantics, through metadata, descriptions and comments, metric views, dashboards, glossary and the Genie environments themselves. One participant summarised it practically: you strengthen the context by defining the semantic metadata and the business context properly, and AI then does the finding and ranking.

One reply introduced the term OntoRank, with the comparison that it works the way a search engine decides which source carries the most authority. Another participant noted that there were still few public benchmarks showing how much better it actually gets.

The sharpest point came from the participants who turned the Foundry comparison around. In their reading the two do not share a purpose: one models the business explicitly and executes operations on it, the other supplies context so that an AI system understands the business better. That is not a quality difference but a difference in architecture pattern.

On three points the documentation is ahead of the discussion.

The first point matters most. Genie Ontology is not only inferred. The documentation describes the context layer as a combination of two kinds of context. The first is Unity Catalog semantics: modelled context that you define, govern and certify yourself, through metric views, domains and Pages. Those components are ordinary securable objects in Unity Catalog, with the privileges and management that come with it. The second is inferred context: snippets that Databricks extracts automatically from your existing assets and usage, such as metric views, dashboards, SQL queries and Genie Agents. Examples Microsoft gives are a metric definition ("an active user is a distinct user, deduplicated across all platforms"), an authoritative source ("revenue questions should be answered using the curated Finance Genie Agent") and a business rule ("a qualified lead only counts once a demo is booked").

Describing the ontology as purely inferred therefore drops the half you can actually steer as an architect. In the same documentation, certification and deprecation exist explicitly as the signal that steers Genie One toward the assets your organisation vouches for.

The second point is how conflicts are settled. Each inferred snippet gets an authority score based on where it was generated from, how often it is used and how fresh it is. Snippets are also gated by Unity Catalog permissions. When you ask a question, Genie One ranks the most relevant snippets, resolves conflicts and answers using only the sources you are permitted to see. Databricks describes that weighting in the announcement as an approach similar to PageRank, which also factors in the authority of the source's author and how closely a definition ties to certified and widely used assets. The term OntoRank from the discussion does not appear in the documentation we were able to verify, though it does appear in third-party coverage. The mechanism is documented, the name for it is not.

The third point addresses the poster's core question directly. You can in fact see which knowledge sources were used: an answer carries citation icons that point at the sources behind it. That is not a browsable graph and it is not an inspection of nodes and edges, but it is not nothing either. Per answer there is a trail.

Three further facts belong in your planning. Genie Ontology is in Public Preview on Azure Databricks. Genie Spaces are now called Genie Agents. And the remark in the discussion about missing benchmarks has been overtaken: Databricks published its own measurement in which Genie answered 84.5 percent of questions correctly on the first attempt, against 52.4 percent for the strongest general-purpose coding agent, at roughly half the latency. Read those numbers for what they are. It is an internal Databricks benchmark, 28 questions, with the competitors anonymised. That is an indication, not an independent comparison.

Finally the cost, because it moves. Databricks currently charges nothing for curating ontology snippets, with the explicit note that pricing may change. User consumption of Genie One and Genie Agents is free through 31 January 2027, with service principals expressly excluded from that promotion and billed. Genie Code moved to a pay-as-you-go model with a free monthly per-user allowance on 8 July 2026.

The Foundry comparison is useful, but not in the way the discussion runs it. For Databricks we rely on the documentation from Databricks and Microsoft. For the other product we do not have that basis, so we describe the pattern rather than the brand.

Two patterns sit opposite each other.

The first pattern is the explicitly modelled business ontology. A designer defines object types, relationships and actions. The model is visible, accessible and governable, and actions hang off objects. That is the shape you need the moment you build operational applications: state, authorisation, write-back to source systems and workflows.

The second pattern is the inferred context layer. Tables, metadata, metric views, dashboards, glossary and external sources feed a semantic layer, which is ranked and then lets an AI system answer better. That is the shape you need for enterprise analytics, where the gain sits in understanding rather than in executing.

"The question is not which ontology is better. The question is whether you want to model and govern your business, or have it understood."

Genie Ontology sits squarely in the second pattern, with a modelled core in the first. And that is where most teams skip the actual architecture decision: which part of your semantics do you deliberately pin down, and which part do you let be inferred?

That is not a matter of taste, because the two halves behave differently the moment something goes wrong. A modelled metric view has an owner, a definition, privileges and a history. If the number is wrong, you know who changes it and what changes with it. An inferred snippet has none of that directly. It came out of a dashboard somebody once built, and the only lever you have on it is indirect: improve the source, certify the alternative or mark the old one deprecated.

For every definition that genuinely matters to your business, revenue, margin, active customer, qualified lead, that is the difference between governance and hoping. Hence the order we recommend: define those concepts as metric views and Pages, certify them, and let the inferred layer do the rest. The inferred layer is then not a replacement for your governance but an accelerator on top of it.

The audit question deserves separate attention, because that is where the discussion breaks down. The citation icons show which sources were used per answer, and the user's permissions determine what can appear at all. For the question "why did this user get this answer", that is workable. For the question "show me the full semantic model and where it drifts", it is not. Anyone who needs the latter has to get it from the modelled half, and that is precisely the half you build yourself in Unity Catalog.

Finally, take the preview status seriously. Public Preview means behaviour and pricing can change, and the documentation already names a limitation: workspaces with many Genie Agents might experience reduced routing accuracy. That matters if you plan to give every team its own agent. Glossary too, which the discussion mentions as a way to steer the semantics, has been announced with a preview that is still to come. Build your plan on what is generally available today and treat the rest as direction.