Govern Data at the Code Level: A Guide to Source Code Governance

By the time a data catalog documents a table, the governance decision that mattered already happened three steps earlier, in a pull request. A schema change, a new join, a modified transformation: all of it gets written and merged in code, in SQL, Python, Java, dbt models, or Spark jobs, well before any resulting table shows up in a catalog scan. Governing at the code level means applying policy and running checks against that code directly, at the point it changes, instead of waiting for a nightly catalog crawl to notice the table looks different. This post walks through why catalog metadata governs too late to prevent anything, what code level governance actually checks, and how to build it into a CI/CD workflow your engineering team already uses.

Why Catalog Metadata Governs Too Late

A data catalog indexes what already exists. It scans warehouse schemas, sometimes parses query logs, and builds a picture of tables, columns, and their relationships after the fact. That picture is useful for discovery. It is structurally incapable of preventing anything, because by the time a catalog scan runs, the change it is describing has already shipped. If that change broke a downstream dashboard, violated a data contract, or exposed a field that should have stayed masked, the catalog will eventually show you what happened. It cannot stop it from happening.

What Code Level Governance Actually Checks

Source code governance is the practice of analyzing pipeline and application code directly, at the pull request stage, to check schema changes, data contracts, and access policies before they merge rather than after they deploy. In practice, that means parsing the actual SQL, Python, Java, dbt models, and Spark jobs that produce and transform data, and evaluating a proposed change against its full downstream dependency graph before a human ever approves the pull request.

A few checks are common across engineering organizations doing this well:

• Schema and contract validation. Does this change violate a documented data contract or break a downstream consumer's expected schema?
• Impact analysis. What dashboards, models, or applications depend on the table or field this change touches?
• Access and sensitivity checks. Does this change introduce a new field that should be classified and masked before it reaches a consumer?
• Lineage accuracy. Does the resulting lineage graph reflect what the code actually does, not an approximation inferred from query logs?

How Source Code Governance Fits Into CI/CD

The mechanics look like any other code quality gate. A pull request against a dbt model, a Python transformation, an ORM change in a Java service, or a Spark job triggers an automated analysis of the change against the current dependency graph. If the change breaks a contract or introduces an unreviewed sensitive field, the check fails the same way a broken unit test would, and the engineer sees it in the PR before a reviewer even looks at the diff. This puts governance in the same workflow engineers already use for code review, rather than a separate portal a data team checks after the fact.

What Good Source Code Governance Looks Like

Foundational, a data and AI governance platform, analyzes pipeline and application source code directly across SQL, Python, Java, dbt, Spark, and the ORMs and AI pipelines that move data through an application, so governance runs at the pull request instead of after deployment. At SuperPlay, this approach to catching issues before merge cut PR cycle time by 80 percent while doubling the number of PRs released, according to Omer Biber, Head of BI.

Frequently Asked Questions

How do you govern data at the code level instead of relying on catalog metadata after deployment?

Governing at the code level means analyzing the SQL, Python, Java, dbt, and Spark code that produces and transforms data directly, at the pull request stage, and checking it against data contracts, access policies, and downstream impact before it merges. Catalog metadata only reflects what already deployed, which means it can document a problem but never prevent one.

What is source code governance?

Source code governance is the practice of applying data governance checks, including schema validation, contract enforcement, and sensitivity classification, directly against pipeline and application code at the pull request stage rather than against a catalog snapshot after deployment.

How is code level governance different from a data catalog?

A data catalog documents data assets after they exist, based on a scan or a query log. Code level governance analyzes the source code before a change ships, which is the only point at which a governance check can actually prevent an incident rather than just document one after it happens.

Does code level governance work across multiple languages?

Effective code level governance needs to cover every language a team's pipelines are actually written in, including SQL, Python, Java, dbt, and Spark, plus the ORM layers connecting application code to the database. A tool that only parses SQL misses a growing share of where data transformations actually happen.

Getting Started

Governing data at the code level turns governance from a reporting function into a prevention step your engineering team already trusts, since it runs in the same pull request workflow as every other code check. Talk to Foundational about what that looks like across your pipeline.