ENTERPRISE CONTEXT · TECHNICAL DEEP DIVE
The Databricks semantic layer has two halves: what your team models in Unity Catalog, and what Genie infers from how people use the estate. Genie Ontology is how Databricks joins them at runtime.
What is the Databricks semantic layer?
The Databricks semantic layer is the set of business meanings that sits between your tables and whoever queries them, whether that is a person or an agent. It names the metrics you report on, the dimensions you slice them by, the entities they belong to, and the joins that are valid between them. Unity Catalog holds the part your team defines deliberately, and Genie Ontology adds a second part that Databricks infers from how the estate is used.
Say someone asks for net revenue last quarter. The semantic layer part is the definition Finance published, which is gross amount minus refunds, taken from the orders table and joined to customers on customer_id. The ontology part is what Genie has noticed around that definition, such as which dashboard people actually open for revenue, that revenue questions should go to the curated Finance agent, and that a lead only counts once a demo is booked. Answering the question needs both, because the definition produces the number and the surrounding context decides whose definition to use and who may see the result.
So, the two halves answer different questions. Modeled semantics say what your company has agreed a term means. Inferred context says what people do with that term in practice, which is often not the same answer. Genie Ontology keeps both and resolves between them at the moment an agent asks.
What came before the Databricks semantic layer?
In 1970, Edgar Codd proposed the relational model because users should not have to know how data is physically stored to work with it. The abstraction was simple and durable: represent facts as relations, expose a small set of operations, and let the database worry about the machinery underneath. That solved an enormous problem, but not the next one, which is what the data means to the business.
A data row can tell you that the account Acme generated $1.2 million. It cannot tell you whether the company considers that account “enterprise,” whether Finance and Sales use the same definition of revenue, whether the churn policy applies to it, or whether a particular dashboard should be trusted over another. So the industry kept adding representations of the facts.
RDF reduced knowledge to subject-predicate-object triples. OWL added formal classes, properties, and logical semantics. Knowledge graphs made connected entities practical at a large scale. Semantic layers narrowed the problem to business concepts such as metrics, dimensions, entities, and valid joins. More recently, retrieval systems stopped trying to model everything in advance and instead assembled relevant context when a question arrived.
RDF, OWL, knowledge graphs, semantic layers and retrieval systems are not interchangeable, and they share a recurring ambition: put enough structure around raw facts that software can use them without carrying the entire organization inside the application. Capable AI agents change who consumes that structure, which is what turns a reporting semantic layer into a semantic layer for AI.
Why does an AI agent need more than a metric definition?
A dashboard needs a metric definition. An AI agent needs the metric, the right source, the valid join path, the meaning of company-specific terms, the user’s permissions, the relevant historical work, and some basis for deciding what to trust when those sources disagree. Then it may need to act on that result. A semantic layer for AI has to carry all of that, not just the metric.
That is why the market is converging on several different representations of roughly the same organizational problem.
Snowflake Semantic Views explicitly model logical tables, metrics, dimensions and relationships. dbt MetricFlow builds a semantic graph from models, entities and metrics. Palantir’s Ontology adds object types, link types and action types, including writeback. Genie’s current design is more hybrid: explicit Unity Catalog semantics plus inferred context assembled from platform activity.
This backdrop makes Databricks’ choice of the word ontology more interesting. The company is not merely renaming a semantic layer. It is trying to build a broader context system from the activity the data platform already records.
How does Genie Ontology combine modeled and inferred context?
Databricks describes Genie Ontology as a unified context layer with two inputs, which makes it the company’s answer to the Databricks semantic layer question.
The first is Unity Catalog semantics: context people define and govern deliberately. Metric Views, Domains and Pages belong here. Pages can define a business concept, attach sources and related assets, and become the preferred context when Genie encounters that concept.
The second is inferred context: snippets Genie automatically extracts and maintains from existing assets and usage, including Metric Views, dashboards, SQL queries, and Genie Agents. Databricks’ docs give examples such as an “active user” definition, a routing rule that revenue questions should use a curated finance agent, or a business rule that a lead only counts after a demo is booked.
Databricks Metric View
version: 1.1
source: prod.finance.orders
joins:
- name: customer
source: prod.crm.customers
'on': source.customer_id = customer.customer_id
fields:
- name: customer_segment
expr: customer.segment
measures:
- name: net_revenue
expr: SUM(source.gross_amount - source.refunds)
comment: "Canonical Finance definition of net revenue"
This example uses the documented Databricks Metric Views YAML shape. Databricks supports sources, joins, fields, measures, filters and additional metadata in Metric View definitions.
The modeled layer tells Genie, “this is what we mean.” The inferred layer tells it, “this is how people actually use the estate.”
Those two signals do not always agree.
Databricks assigns inferred snippets an authority score based on where they came from, usage and freshness. Its launch post describes a PageRank-like ranking process that can also consider the authority of the author and connections to certified or widely used assets. At query time, Genie ranks relevant snippets, resolves conflicts, filters them through Unity Catalog permissions and uses the selected context to answer.
The exact internal algorithm is not public. This figure reflects the product behavior that Databricks documents: retrieve candidate context, rank snippets by authority, enforce permissions, route or execute work, then return citations.
In practice, Genie behaves less like a static knowledge graph and more like a context-selection system.
Can you trace why an agent chose one definition over another?
Data engineers already trace a number backward when it looks wrong:
dashboard → semantic model → transformation → source table → upstream system.
Each edge explains where the value came from.
An agent introduces another chain above that data lineage. Why did it choose the Finance Page instead of the Sales dashboard? Why did it route the question to one Genie Agent? Which snippets were considered and rejected? Which join did it decide was valid? Which SQL did it generate? Which result changed the next step?
Reasoning lineage is the name for that second chain. What you audit is not the model’s chain-of-thought but the trace around it: the evidence retrieved, the authority decisions, the policy checks, the tool calls, the generated code, the query results and the final citations. A Databricks semantic layer records what a term means, and none of that records why one meaning won.
“Reasoning lineage” is our term, not a Databricks one. It names what the system retrieved and did, which you can check, rather than the model’s account of its own thinking, which you cannot.
What an auditable agent trace would need to preserve
{
"question": "Net revenue for enterprise EMEA last quarter",
"context_candidates": ["finance.page", "sales.dashboard", "query_8472"],
"selected_context": "finance.page",
"selection_evidence": {
"authority": "human-modeled / published",
"permissions": "allowed"
},
"tool": "sql_warehouse",
"generated_sql_hash": "sha256:…",
"result_artifact": "query_run_01928",
"citations": ["finance.page", "metric_view.net_revenue"]
}
This is a conceptual trace format rather than a Databricks API schema.
Which Databricks tools read the same semantic layer?
This is where Genie Ontology becomes more than an analytics feature.
Genie One reads the ontology when a business user asks a question. Genie Code searches the same ontology, so a metric definition or join hint curated once can affect developer work. Databricks’ managed Genie One MCP server lets external MCP clients send questions to Genie and receive answers grounded in the ontology, with Unity Catalog permissions enforced.
The architecture starts to look like a shared context layer that agents read at runtime, which is a larger claim than a Databricks semantic layer usually makes.
Reading is already broadly supported. Writing authoritative context is much more constrained.
Genie automatically maintains inferred context as the underlying assets and usage change. Humans can publish and edit Pages. Genie Code can draft Pages from source material, but those drafts still go through a human publication flow. And the Genie Agent MCP server is explicitly read-only for data queries.
So an agent cannot, today, simply decide that it learned a new business truth, write that fact into the shared ontology, and have every future agent inherit it as authoritative context.
That is probably a good constraint.
The important feedback loop exists indirectly: agents and humans create artifacts and usage, which can become new inferred evidence. Directly promoting an agent’s new claim to shared organizational truth is a much harder governance problem.
If Databricks eventually lets agents write to it, the product will need stronger provenance, approval, temporal validity and rollback. Otherwise the ontology risks learning from the consequences of its own previous outputs and amplifying mistakes.
What breaks a semantic layer as the business changes?
Ontologies look clean in architecture diagrams because the diagram freezes the organization in time.
Companies do not stay still.
They rename metrics. They acquire businesses. Teams create local definitions because the global one is inconvenient. A source system changes grain. A dashboard remains popular after the logic underneath it becomes stale. Permissions change. New agents generate more queries and documents, which themselves become evidence for future agents.
The graph is not merely large. It is moving.
Calling ontology maintenance “NP-hard” is tempting but imprecise.
But the enterprise maintenance problem is difficult for an additional reason: much of the ambiguity is not computational.
Whether “customer” means a billing account, legal entity, workspace or product tenant is an organizational decision. Whether the new definition should replace the old one retroactively is a policy decision. Whether Sales may override Finance for pipeline reporting is a governance decision.
No graph algorithm settles those questions by itself.
The maintenance challenge is both algorithmic and organizational. Automatic curation reduces setup cost, but it also makes change visibility, conflict handling and rollback more important.
Maintenance is where Genie Ontology will succeed or fail.
Databricks has an unusually good position from which to infer context because it sees a large amount of enterprise data exhaust: catalog metadata, queries, dashboards, lineage, permissions, Metric Views, Genie Agents and developer activity. The product can start without a pristine manually designed ontology, then use explicit semantics as stronger anchors where correctness matters. The same activity already drives other automation on the platform, such as tuning a job cluster from its own run history.
The danger is that the same automation that makes the Databricks semantic layer cheap to start can make it difficult to reason about later.
Is Genie Ontology ready for production use?
Not yet.
As of September 2026, Genie Ontology is in Public Preview. Pages are Beta. There is no public export or snapshot. Provenance is visible at answer level through citations, but there is no dedicated ontology lineage view. There is not yet a full reviewable changelog or diff of newly learned context.
| Status | Capability | What it means today |
|---|---|---|
| Available now | Hybrid context | Human-modeled Unity Catalog semantics plus automatically maintained inferred snippets. |
| Available now | Authority and ACLs | Relevant snippets are ranked, and Unity Catalog permissions gate what the user can consume. |
| Available now | Cross-surface reuse | Genie One and Genie Code search the same ontology, and Genie can be exposed through MCP. |
| Still immature | Ontology-level auditability | No public snapshot or export, dedicated relationship lineage, or full change diff today. |
| Still immature | Direct agent writeback | No public generic API for an agent to promote a newly learned claim into authoritative shared context. |
| Open question | Long-term maintenance | Can automatic curation stay correct as definitions, schemas, teams, permissions and agents change? |
Pages also carry a preview-era security caveat worth noticing. Databricks warns that Page data does not support customer-managed key encryption and is stored as plain text that may be replicated globally, so Pages should not contain PII, regulated data or other sensitive content.
Databricks has also published internal benchmark results: 84.5% first-attempt correctness on a 28-question enterprise data-analysis suite, versus 52.4% for its strongest anonymized general-purpose coding-agent comparator, with roughly half the latency.
It is an encouraging result, but still a small vendor-run benchmark.
The more consequential test is what happens after eighteen months of production use, when the ontology has absorbed thousands of new assets, stale definitions, reorganizations, permission changes and agent-generated artifacts. Success will depend less on whether Genie can build this semantic layer than on whether it can keep it true as the organization changes.
Databricks’ bet is that the platform now contains enough behavioral evidence to keep an ontology current without requiring an enterprise to model everything manually.
Can Databricks make an enterprise ontology that is not only useful when it is created, but inspectable, governable and correct, in near real time, while the enterprise keeps changing?
Frequently asked questions
Is the Databricks semantic layer the same as Unity Catalog Metric Views?
Databricks Metric Views are one part of it. They are where a team writes a metric down deliberately, with its source, joins, fields and measures, in the YAML shape shown above. Genie Ontology also covers Domains and Pages, and adds the inferred half that Genie maintains from dashboards, SQL queries, Genie Agents and usage. Metric Views are the modeled anchor rather than the whole layer.
Can an AI agent write new definitions into the Databricks semantic layer?
Not into the authoritative part. Genie maintains inferred context automatically as assets and usage change, and Genie Code can draft Pages from source material, but those drafts still go through a human publication flow. The Genie Agent MCP server is read-only for data queries. An agent cannot decide it has learned a new business truth and have every future agent inherit it as authoritative context.
How does it differ from dbt MetricFlow or Snowflake Semantic Views?
Those two model meaning ahead of time. dbt MetricFlow builds a semantic graph from models, entities and metrics, and Snowflake Semantic Views model logical tables, metrics, dimensions and relationships. Genie Ontology is more hybrid, pairing explicit Unity Catalog semantics with context assembled from platform activity, then ranking the candidates by authority at the moment a question arrives.
Altimate Code puts a deterministic tool layer under the model and returns a signed verdict with the evidence it used on every dbt pull request, so the retrieval, the checks and the generated SQL stay inspectable. Read what Altimate Code does, or how it runs against Databricks.