How Dawiso Extends Databricks Unity Catalog, from the Access Gate to Governed AI Context

The Access Gate, from request to provisioned access

The Access Gate is the part of the Dawiso Data Product Platform that handles approval of access to data products. Someone finds a data product in the catalog and requests access to it. From there the Access Gate runs the whole process, from the approval itself through to automatically granting the access in the platform where the data actually lives. For a Databricks customer that means the grant lands in Databricks without anyone opening a workspace to make it happen.

This is the piece most worth understanding, because it sits exactly where Unity Catalog stops. Unity Catalog enforces a grant well. The decision behind that grant gets made somewhere else, usually somewhere much less governed, in a ticket queue, a spreadsheet of approvals, or a data steward's inbox, and Unity Catalog only ever sees the outcome. Nothing in the platform records who asked, who approved, for what purpose, or when the access should expire.

Because the request in Dawiso is made against a data product rather than against a bare table name, everything the approver needs is already attached to it. The product carries an owner, a classification, a business definition, and the lineage showing where the data came from. The owner can approve on the strength of that, instead of forwarding the question to the data team and hoping someone recognizes the table.

The same gate serves both people and AI agents. An agent that needs a dataset requests it the same way a person does, through the same approval path, with the same record left behind. That matters more every quarter, because the number of non-human consumers in a Databricks estate is growing faster than the number of human ones, and an agent running under a shared service principal is invisible to any access review.

What comes out the other end is evidence. One request, one approval, and one record that a GDPR, DORA or NIS2 auditor can read without a reconstruction exercise across three systems. This is what data access management looks like when the catalog is involved in the decision rather than notified after it.

A scanner that sees past tables and views

A Databricks account has two axes, and a scan that follows only one of them sees half the picture. On one side is the Unity Catalog metastore, holding catalogs, schemas, tables and views. On the other side are workspaces, and a workspace can read from several catalogs. Some of the objects that matter most to the business hang off the workspace rather than the catalog.

A metastore-only scan covers the first axis. The Dawiso Databricks scanner reads both. Alongside catalogs, schemas, tables and views it also ingests ML models, table constraints, Unity Catalog tags, column masks, row filters and data classification, external locations and storage credentials, AI/BI dashboards together with their datasets, and Genie Agents together with their sample queries.

Those last two are what decide whether governance reaches the people who actually consume the data. A dashboard is a governed asset like any other, and if it sits outside the governance framework, every impact analysis stops one step short of the person who will actually notice the breakage. Genie Agents, which Databricks called Genie Spaces until it renamed and expanded them in 2026, are curated views of data that people query in natural language. An agent that answers business questions belongs in the same catalog as the tables it answers from.

Here is what that looks like on both sides. In the Databricks workspace, dashboards and Genie Agents sit in the sidebar next to the SQL editor and the models, entirely separate from the catalog tree.

And here is one of those Genie Spaces after a Dawiso scan, sitting in the catalog tree next to tables, views and ML models. The scan brings across its description, its sample queries and its diagrams, and gives it ownership fields of its own so a data owner and a steward can be assigned to the agent itself. Dawiso still labels these Genie Spaces, the name Databricks used before the rename.

Lineage comes from the Unity Catalog system.access lineage events, with two settings worth tuning. A lineage window controls how far back the scan reads, and a workspace scope decides whether Dawiso ingests events from the connected workspace only or across the whole metastore. A short window scans faster, a longer one catches the pipeline that runs once a month.

Scale is the other half of scanning. Dawiso's ingestion engine is built to load millions of objects and to update them in bulk without locking the area of metadata people are working in. Scanners run from the Dawiso cloud, or you deploy them as command line utilities inside your own network and push metadata out, which is usually what a bank or an insurer needs. The two modes can be mixed per source system.

Mastered in Dawiso, written back into Unity Catalog

Scanning is one direction. The more interesting direction is the way back. Ownership, GDPR and security classification, and business metadata can all be mastered in Dawiso and written back into Unity Catalog, so the curated result shows up in Databricks itself.

Mechanically, a Dawiso automation action writes the value onto the Databricks column, either as a Unity Catalog tag or as a property, under a key you choose. A security classification mastered in Dawiso can land in Unity Catalog as something like dawiso_security_classification, and from that point on it is ordinary Unity Catalog metadata that Databricks policies and queries can read.

The destination is the table's Overview tab in Catalog Explorer, the screen a data engineer already has open. Owner, tags and classification all live there, next to the Quality block and the policies.

What this buys you is a clean split of labor. The business owner works in Dawiso, in an interface built for someone who does not write SQL, with AI assistance for drafting definitions and classifying assets. The data engineer never has to go and look, because the answer is already sitting on the column in Databricks.

Databricks runs the checks, Dawiso shows the business

Databricks has its own data quality capability, Data Quality Monitoring, whose data profiling was formerly known as Lakehouse Monitoring. It is the Quality block on the same Overview tab, switched on per table, and its anomaly detection, which learns a table's normal commit rhythm and row counts to flag stale or incomplete data, reached public preview in February 2026. On top of that you can set custom metrics for the checks your own domain needs.

Dawiso integrates with it rather than competing with it. The checks run on Databricks compute, using the framework and the rules you already have. Dawiso tracks the results at the metadata level, next to the definition, the owner and the classification of the asset they belong to, and turns them into dashboards a business owner can actually read.

The practical consequence is a line item you do not have to buy. Combining the native engine with a business-facing surface gives analysts and data owners a straight answer to which assets can be trusted, without a third data quality tool and a third set of credentials.

Governed context for Genie Agents through MCP

In May 2026 Dawiso was listed in the Databricks MCP Marketplace, as one of the first independent tools outside the original launch partners to be approved. Databricks is one of the few platforms that supports Model Context Protocol servers natively inside its agentic workflows, which is what makes the integration worth building rather than bolting on a translation layer.

Everything curated in Dawiso can be fed to AI agents and AI tools running on Databricks through the MCP server. Business terms, data products, ownership and classification, all of it becomes context an agent can read. For Genie Agents that is the difference between an agent that knows your table names and one that knows what your company means by "active customer".

The part that surprises people is that the connection writes as well as reads. When an agent on Databricks builds a pipeline, transforms data or creates a new asset, it can document that work in Dawiso as it happens, scoped to the permissions of the user running it. Descriptions, new objects, business terms and published documentation all become things an agent contributes to rather than things a human backfills later.

Where Dawiso fits

None of this asks Databricks to be something it is not. Unity Catalog stays the governance engine for everything inside the platform, and it is a good one. Dawiso adds the business layer above it, the Access Gate in front of it, and the reach past its edges.

That last point is usually why the conversation starts. Very few estates are only Databricks. The common shape is Databricks plus Power BI or Microsoft Fabric, with dbt in the transformation layer, an Oracle or SAP database still holding the system of record, and Confluent moving events between them. A platform-native catalog can only ever govern its own slice, which is the case for a cross-platform context layer and for end-to-end lineage that does not stop at the workspace boundary. We have written that argument out in full under how Dawiso complements Unity Catalog, so it is worth reading there rather than repeating here.

Dawiso is a validated Databricks technology partner, and the scanner in particular has been shaped by feedback from Databricks Solution Architects working on real deployments. If you want to see what it reads, what it writes back, and how the Databricks connector is set up, that page has the object list and the permissions. The Context Layer is where the same governed context gets served onward to your AI governance.