
Data governance programmes fail for a predictable reason. The decisions get made once, recorded somewhere they are difficult to find, and then never applied consistently. A steward classifies a column as personal data. The classification lives in a spreadsheet. Six months later, a new pipeline loads the same column into a different table. Nobody checks the spreadsheet. The column goes unprotected.
The approach that Cristian Badet, Data Lead Solution Architect at mindit.io, presented in a recent Databricks webinar is designed to close that gap. He calls it governance as code.
The core idea
Every governance decision has one owner, is recorded once, and is applied by the platform every time something changes. Not by a person remembering to apply it. By the platform doing it automatically.
The mechanism is the data contract: a file, typically JSON or YAML, that lives in the same repository as the code. It describes a dataset’s structure, the business term and classification of each column, the quality rules, the owner, the retention policy, and any other governance attribute the organisation needs to track.
The data governance owner sets the standards. The security officer decides how sensitive data is protected. The data steward fills in the contract for each column. The engineer builds the pipeline. The deployment process reads the contract, validates it, and applies it to the table in Databricks: tags, descriptions, access rules, and quality checks, all from the same source file.
That is the governance decision made once and applied every time.
What happens at each stage of a data asset’s life
The contract follows a data asset from design to retirement.
At design and build, the steward marks the email column as personal data in the contract. The engineer builds the ingestion pipeline. When the deployment runs, it checks that all required fields in the contract are filled in, stops if any are missing, and creates the table with its tags and descriptions already applied.
At runtime, every data load is checked against the quality rules in the contract. Rows with empty email addresses are quarantined or dropped and reported, depending on what the contract specifies.
At review, a scheduled job compares the live table against the contract. If a new column has appeared from a source system, the job flags it. The steward sees it, classifies it, updates the contract, and the next deployment applies the classification.
At retirement, a new version of the table replaces the old one. The old table is marked as deprecated in the contract and its data is archived or deleted according to the retention rules already written there.
At every stage, the decisions are in the contract, not in someone’s head.
Why the pull request matters
One detail from Cristian’s presentation that is easy to overlook: every change to a data contract goes through a pull request in the repository, and the data owner approves it before it is merged.
This is not a bureaucratic step. It is the control point. It means that a governance decision cannot be changed without the owner’s knowledge, and the full history of every decision is preserved in version control. If a classification changes, you can see when it changed, who changed it, and why. That is the audit trail that compliance requires, produced automatically by the same process the engineering team already uses.
What this looks like on a single column
To make it concrete: the email column in the customer table.
The contract states that the column holds an email address, that it is personal data, and that it is subject to the organisation’s PII masking policy. On deployment, Databricks reads that contract, writes the description on the column, applies the personal data tag, and the masking rule fires on every query based on that tag, for humans and AI agents alike.
A weekly job checks whether the tag is still there. If someone changed it by hand, the job restores it on the next run. The governance decision holds without anyone having to manually enforce it.
That is the difference between governance that is documented and governance that is applied.