Genie Ontology Ranks Trust, Not Correctness

Every time you spin up an agent session, the agent starts by exploring code, files, schema, and documentation just to figure out what the heck things mean. That costs time and tokens, and it can drastically affect the accuracy and consistency of the answer. With coding agents, we work around this with things like data dictionaries or definitions in AGENTS.md. But when we're building agents to answer questions about company data, we'd rather have those definitions live somewhere centrally, stay consistent across users, and not require someone to manually maintain all of them.

Databricks' Genie Ontology, announced at DAIS 2026, aims to solve this problem: instead of guessing at business meaning from schema fragments, Genie queries a living graph that understands what 'revenue' means at your company, who defined it, and who relies on it. The engine behind this is OntoRank, which solves the problem of trust while leaving the problem of accuracy almost entirely untouched.

This is a genuine step past plain retrieval, since a RAG-style layer matches text to a query and hands back whatever looks relevant with no way to tell multiple competing definitions of revenue apart. OntoRank actually adjudicates between them using usage and authority signals, and Databricks backs the approach with a benchmark showing Genie answering 84.5% of real-world data questions correctly on the first attempt against 52.4% for the strongest general-purpose coding agent tested. That figure comes from a vendor-reported, internal 28-question suite rather than an independently audited result, but even with that caveat, ranked context is clearly doing real work.

Genie Ontology's OntoRank

Genie Ontology draws from two kinds of context. The first is modeled context, meaning governed definitions you've explicitly certified through Unity Catalog Business Semantics, metric views, domains, and Pages. The second is inferred context, which Genie extracts automatically from tables, queries, dashboards, pipelines, and more than fifty connected apps like Slack, Jira, and Salesforce. Both feed the same graph, and the graph updates continuously as those sources change rather than staying fixed at some snapshot.

OntoRank exists to handle disambiguation once that graph gets built, since finance and sales often define revenue differently and two teams frequently count active users with different rules. Rather than surfacing every candidate definition and letting the agent or the user sort it out, Genie Ontology ranks them and serves the top one. Databricks describes the approach as PageRank-like, weighing five signals: where a definition came from, the authority of whoever created it, how often people rely on it, how closely it ties to certified and widely-used assets, and how fresh it is. Permissions get checked too, so an agent only ever surfaces definitions the requesting user is actually allowed to see.

Why ranking authority isn't the same problem as checking math

The framing needs to be precise: conflating 'Genie found the most trusted definition' with 'Genie's answer is correct' is a dangerous error. They are two different claims resting on two different sources of truth: one based on social authority (usage, certification) and one based on logical validity (transformation code).

OntoRank's graph is built from observed authority and popularity: who created a definition, how certified it is, how often it gets used. That graph answers which definition the company trusts most, but it says nothing about whether a given calculation on top of that definition is mathematically valid. Whether a metric can be safely summed, averaged, or rolled up across a coarser grain depends on how it was built in the transformation code underneath it, and that's a layer OntoRank never reads. A metric view can be certified, widely used, and ranked first by every trust signal Databricks tracks while still being arithmetically wrong for the question being asked.

The failure mode is concrete and common: monthly active users defined as the sum of daily distinct-user counts. Each daily count is a legitimate distinct-user count, and summing looks safe on its face since it's just addition over a time dimension. But a user active on multiple days in the same month gets counted once per day, so the sum systematically inflates the true monthly figure, and the correct number instead comes from a fresh distinct count taken over the full month's raw events rather than an aggregation of the daily rollups. This error stays invisible in the metric's name, its popularity, and its certification status, since it only shows up in the transformation logic that produced the daily table in the first place, several steps removed from the metric view Genie actually reads.

OntoRank selects a definition but doesn't validate it

This matters more once an agent is the one running the query instead of a human, since a person building a dashboard might know from experience not to sum daily active users while an agent querying a governed, top-ranked metric view has no such instinct. It will group by whatever grain the question implies, including a monthly rollup nobody validated, then return the inflated number with full confidence and a governed source to cite. Defining the metric once and letting every agent reuse it is the whole point of a semantic layer, which is exactly why an unvalidated definition propagating through it does more damage than one analyst making a one-off mistake.

The obvious counterargument is that certification links and lineage already cover this, but they don't. Certification records who trusts a definition, while lineage records that one column feeds another, and neither carries the rule that a distinct count can't be summed across time. That rule only exists inside the transformation code itself, so catching it requires a different kind of graph than the one OntoRank builds.

Genie Ontology in practice

None of this argues against Genie Ontology, since ranked, permissioned context is a real improvement over an agent inferring business meaning from raw schema, and the benchmark gap over unranked retrieval is large enough to matter in production. The practical implication is narrower: treat OntoRank's top-ranked definition as the best available context rather than a verified answer.

A few concrete steps follow from that:

• Audit metric views for non-additive measures before they feed the ontology. Distinct counts, averages, medians, and ratios that divide by a distinct count are the usual suspects. If a measure expression contains one of these, flag it as unsafe to roll up across a coarser grain than it was defined at, regardless of how certified or popular the definition becomes.
• Don't let certification status stand in for correctness review. Certification tells you a definition is trusted and governed, but it doesn't tell you the calculation behind it holds up at every grain an agent might query it at.
• Trace the metrics that matter most back to their transformation logic, not just their definition. OntoRank's ranking signals of authority, freshness, and usage say nothing about the code that built the underlying table, and for high-stakes metrics, that code is the only place the validity rule actually lives.
• Expect the stakes to rise as agent-querying scales. A human analyst might catch a faulty distinct count by instinct; an agent will trust the governed metric view implicitly, propagating bad math at the speed of the model.

Genie Ontology answers the question of which definition your company trusts most (given the context of the questions asked), and it does that well enough to meaningfully cut down on agents guessing at business context from fragments. Whether the number computed from that definition is correct is a separate problem, and it gets solved by reading the transformation code itself rather than by ranking what's already there any better.