Data governance on Databricks is often described at the level of principles: ownership, classification, lineage, quality. What is less often explained is how those principles translate into specific platform features and what those features actually do in practice.
Cristian Badet, Data Lead Solution Architect at mindit.io, walked through five areas in a recent live webinar. What follows is a summary of each one, based on that session.
1. Business meaning and discoverability
The starting point for governance is making sure everyone, and every system, works from the same definition of a business term.
In Databricks, business terms live in the business glossary. Each term has one definition and one owner. The data contract links each column to its term, so when someone browses a table in Unity Catalog, the column description comes from the glossary, not from whatever the engineer typed when they created the table.
Metric views take this further for KPIs. Net revenue, for example, is defined once in a metric view in the catalog. When a dashboard queries it, it uses that definition. When a Genie agent answers a question about net revenue, it uses the same definition. There is no divergence between what the dashboard shows and what the AI says, because both pull from the same source.
Domains, which became generally available in October 2026, let people browse data by business area rather than by technical structure. A new analyst looking for customer data opens the customer domain, sees the certified tables, and finds the right one without having to ask around. The certified label is not decoration. It means the table has met the quality and governance criteria defined in the contract, and it is regularly checked to make sure it still does.
2. Sensitive data classification and protection
Classification in Databricks works in two ways. The first is that the source system hands over the classification along with the data. The second is that Databricks proposes a classification based on what it detects in the column, and the data steward confirms or rejects the proposal.
Either way, the steward’s decision goes into the data contract. On deployment, the contract turns that decision into a governed tag on the column. A single attribute-based access control policy, defined once at the schema level, then applies to every column carrying that tag across every table that holds it.
The practical result: a new table arrives with a column tagged as personal data, and it is protected from its first query, without anyone having to write a separate policy for that table.
The same protection applies to AI. When a Genie agent queries a table, the masking rules fire on the agent’s query exactly as they would on a human’s query. There is no separate governance track for AI access.
A monthly job compares the classification results from Databricks’ detection against what is recorded in the contracts. If it finds personal data in a column that has not been classified yet, it surfaces that finding for the steward to act on.
3. Data quality
Databricks handles data quality in three layers, each serving a different purpose.
Expectations are quality rules embedded in LakeFlow declarative pipelines. They come from the data contract and define what happens when a row fails: quarantine it, drop it, or let it pass with a flag. This is where you handle the daily flow of incoming data.
Constraints are rules that apply at the table level whenever data is written. They are independent of the pipeline and enforce data integrity at the storage layer.
Data quality monitoring learns from the history of each table and flags anomalies: a load that arrived late, a table that came in with significantly fewer rows than usual, a spike in volume that does not match the expected pattern. Anomaly detection is in public preview.
The data contract defines the quality rules, the thresholds, the critical columns, and the criteria for certification. When a pipeline runs, the results are visible in the pipeline view: which rows passed, which were quarantined, and why. The certification of a table follows the accumulated quality results, not a one-time check.
4. Lineage
Databricks has tracked internal lineage, the flow of data between tables and transformations within the platform, for a long time. What has changed more recently is external lineage: the ability to connect source systems outside Databricks, such as a CRM or an ERP, to the tables that receive their data.
The result is that you can look at a metric view or a dashboard and trace the data back through every transformation step to the source system it came from, including systems that sit outside Databricks entirely.
Classification follows lineage. A table derived from a source that carries a personal data tag inherits the highest classification of its inputs. This reduces the risk of sensitive data appearing unclassified in downstream tables.
Before anyone renames a column or retires a table, the lineage view shows every downstream dependency: which pipelines use the column, which reports depend on the table, which teams would be affected by the change. That visibility is what makes impact assessment practical rather than guesswork.
5. Observability
The governance hub, currently in beta, gives a single view of the state of governance across the whole platform. It shows how data assets are queried, how access is granted, which tags are applied and to how many assets, and whether the governance decisions recorded in the contracts are still holding in the live environment.
Databricks also exposes this information through system tables and audit logs, which means the governance reporting that most teams still do by hand today, checking which tables are tagged, which are certified, which have owners, can be automated. The data steward acts on the findings. The platform produces the evidence.
Tag propagation, also in beta, lets you define a classification tag at one layer and propagate it automatically to the layers below. Define personal data at the source table, and every derived table inherits the tag without a separate classification step.
Together, these five areas form a governance system where decisions are made once, applied automatically, and continuously verified. The value is not in any individual feature. It is in the connection between them: a single data contract that drives classification, quality checks, descriptions, tags, access rules, and certification, all from one source of truth that lives in version control alongside the code.
