# How do you give Databricks Genie the business context it needs to answer accurately?

> ## Summary
>
> - Databricks Genie answers enterprise data questions accurately when business meaning is explicit and governed. A smarter model doesn't get you there. You need shared, governed context, which can be learned from assets you already have in the organisation.
> - In practice that means four layers: a curated model built around business questions, metric views for your KPIs, a glossary of business concepts and how they relate, and governed tags and policies that carry permissions.
> - Curate the critical "head" of your business, the KPIs and definitions you can't afford to get wrong. Genie Ontology infers the long tail from the dashboards, queries and notebooks you already have.

## Why does an AI coworker give wrong answers on enterprise data?

An AI coworker gives wrong answers when the meaning of the data lives in people's heads and not in the platform. I learned this working with a large manufacturer. Their data estate held thousands of tables copied straight from source systems.

![Databricks Genie One answering a SUM fitment rate question by searching Genie Ontology, then querying a governed metric view with MEASURE() calls.](https://cdn.hashnode.com/uploads/covers/627d1726b7c3c8c346150134/3d6f8452-85cc-4d9f-9959-d5403207c060.png align="center")

Take a simple question: "What is our reuse rate for serviceable parts at our two main repair sites?" The data that answers it sits in columns like `flg_new_yn` and `num_fit_parts` (illustrative names). An engineer can guess what those mean. Three engineers guessed three ways. Every query counted the same thing on top, used parts fitted. The difference was the **denominator**.

- One divided by fittings where a used part was eligible (22%).
- Another divided by all parts fitted (12%).
- The third divided by total parts demand, including parts still on order (6%).

All of those are perfectly correct, yet only one matched the definition the business actually used. A human bridges that gap with tacit knowledge and doesn't notice doing it. But an agent is grounded on data not on someone's tacit knowledge. When meaning is missing, an agent infers it from column names and commits to the guess with full confidence. Pre-agent era, at human speed, a wrong definition was one bad report. At agent scale, it's thousands of confident wrong answers before anyone checks.

## What is a context layer for Databricks Genie?

A context layer is a business meaning layer that sits on top of your data. It defines entities, properties, relationships and rules, and ties each of them to live tables. It translates between three levels:

| Level | What it holds |
| --- | --- |
| **How the business asks** | Outcomes and KPIs, for example "Which forecast removals next month have no parts and no shop slot?" |
| **Where meaning lives** | Entities, relationships and certified metric definitions |
| **What the data is** | Source-aligned/raw tables, files and documents |

Genie Ontology is the context layer underneath Genie One and Genie Agents. It combines context you curate in Unity Catalog ([UC Semantics](http://ttps://docs.databricks.com/aws/en/uc-semantics/)) with context it learns automatically from governed assets, ranks that context by authority, and applies permissions before using it \[[Databricks blog\]](https://www.databricks.com/blog/operationalizing-genie-ontology-your-data-stack).

## How do I map metrics, schemas and policies to Genie?

Map business meaning to Genie in layers, building from the bottom up. This is the order we used, with what each layer gives Genie:

| # | Layer | What you build | What Genie gains |
| --- | --- | --- | --- |
| 1 | **Curated model** | Fact and dimension tables shaped around the business question, not the source system, built with [Lakeflow Spark Declarative Pipelines](https://docs.databricks.com/aws/en/ldp/) | Fewer joins to guess |
| 2 | [**Unity Catalog metric views**](https://docs.databricks.com/aws/en/uc-semantics/metric-views/) | One definition per KPI, with display names and synonyms | The same number for every user and tool |
| 3 | **Business glossary and relationships** | Business terms as [Unity Catalog Pages](https://docs.databricks.com/aws/en/uc-semantics/pages), grouped into [Domains and Subdomains](https://docs.databricks.com/aws/en/uc-semantics/domains), with [primary and foreign keys](https://docs.databricks.com/aws/en/tables/constraints) linking the higher level entities in the curated model | Questions that hop across domains |
| 4 | [**Governed tags**](https://docs.databricks.com/aws/en/admin/governed-tags/) **and** [**ABAC policies**](https://docs.databricks.com/aws/en/data-governance/unity-catalog/abac/) | Tags such as `pii` or `financial` driving [row filters and column masks](https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks/) | Answers limited to data the person asking is allowed to see |
| 5 | [**Genie Agent setup**](https://docs.databricks.com/aws/en/genie-agents/best-practices) | One Genie Agent per data product, with instructions, example SQL and benchmark questions | Accuracy you can measure and track |

## How do I add business context when the data already exists?

Most enterprises start brownfield: thousands of tables copied one-to-one from source systems, with reports and jobs already reading them. Leave those tables untouched and build the meaning in a new layer above them. In our build that came down to four steps:

1. **Start with a few high-value questions.** Don't try to cover the whole estate.
2. **Find the entities behind those questions.** List the entities each question needs (customer, asset, shop visit, part) and locate the source tables that hold them. Choose one master table per shared key, such as the asset serial number. Then check that the same serials reconcile across systems.
3. **Declare the join paths.** Add primary and foreign key constraints to those masters in Unity Catalog. Unity Catalog doesn't enforce them, but they tell Genie how the tables join, so it doesn't have to guess.
4. **Build the curated model, then metrics.** Use Lakeflow Spark Declarative Pipelines to build curated fact and dimension tables that read from the source tables. Then define metric views on the curated tables. Comments matter as much as structure. Genie Ontology learns the long tail from table and column comments. A column described as "Y when the fitted part is new, N when it is serviceable used" tells Genie far more than `flg_new_yn` does on its own.

## What changed when the business meaning was explicit?

Before we built the context layer, we pointed a Genie Agent at the raw source-aligned tables and unstructured data. It probed several tables, picked one definition of the rate, and returned a number nobody could trace. With the context layer in place, we asked Genie One: "What is our serviceable used material fitment rate for a product programme, and how much of it comes from life-limited parts?" Life-limited parts (LLPs) have a fixed certified life and must be replaced when it runs out, so they are tracked separately.

![Databricks Genie One answering "What is our SUM fitment rate, and how much of it comes from life-limited parts?" The thought process shows 18 Genie Ontology results across Pages, Snippets and Domains. Genie then inspects the sum_fittment metric view and a domain-specific Genie Agent. The generated SQL calls MEASURE() for fitted parts, replaced parts, SUM parts and three SUM rates, split into LLP and non-LLP.](https://cdn.hashnode.com/uploads/covers/627d1726b7c3c8c346150134/e55cc158-8551-4772-aac5-ce43b000d6e2.png align="center")

The screenshot shows three things:

1. **Genie checked the ontology before writing SQL.** Genie One searched Genie Ontology for what "SUM fitment rate" and "life-limited parts" mean, and found 18 results across [Pages](https://docs.databricks.com/aws/en/uc-semantics/pages), Snippets (inferred context) and [Domains](https://docs.databricks.com/aws/en/uc-semantics/domains). It didn't start by guessing from column names.
2. **Genie chose the governed definition.** From those results it went to the `sum_fittment` metric view and the domain-specific Genie Agent, the curated sources for this question.
3. **The SQL calls measures, not formulas.** Every number in the query comes from `MEASURE()`, for example `MEASURE(sum_rate_of_fitted)`. Genie didn't write a single division. The denominators were decided once, in the metric view. That last point is the fix for the denominator problem at the start of this post. The metric view carries the rate three ways, as separate named measures: SUM parts as a share of parts replaced, as a share of parts fitted, and by value. Genie returned all three side by side, split into LLP and non-LLP. Nobody has to guess which rate they are looking at, because each one has a name and an owner.

> <mark>We also saw a warning sign worth sharing: Genie Agents multiplying team by team, each with its own definitions. That repeats the old BI dashboard sprawl. The fix was</mark> **<mark>one shared semantic layer</mark>**<mark>, with every Genie Agent built on top of it.</mark>

## Key takeaways

- Accuracy comes from context, not from a cleverer model.
- Put the can't-get-it-wrong metrics in Unity Catalog metric views first.
- Model relationships between domains so one question can cross them.
- Let governed tags and ABAC carry permissions, so every answer is safe by default.