Data governance with dbt: KPC webinar recap

A look back at the webinar: data governance in the Modern Data Stack, end-to-end lineage, data contracts and lessons from the field at KPC.

By 2026, data teams have industrialized their pipelines. Yet governance is still treated as a separate project, disconnected from the transformation tools, and the result is dead documentation, quality nobody can guarantee and no traceability. That is the picture painted by Matthieu Augier (KPC) and Hicham Babahmed (dbt Labs) during their joint webinar on 26 May 2026.

A problem still far too common in 2026​

Whether it is an SME with data scattered across Excel files, or a large group with a dense IT estate and contradictory definitions between divisions, the picture is the same: nobody trusts the data. AI projects fail for lack of controlled semantics, strategic decisions rest on figures nobody has reconciled, and regulatory requirements (GDPR, Solvency II, PII) stay hard to address without traceability.

In the field, the same workstreams come back engagement after engagement: clarifying roles and responsibilities (data owner, data steward, data custodian), tackling quality pragmatically, building a living catalog and addressing regulatory auditability.

• Unreliable data: The question “what is good-quality data?” still has no operational answer in most organizations.​

• Regulation not under control​: GDPR, Solvency II, PII: the constraints keep tightening without traceability being in place.​

• AI failing fast​: AI projects “fail fast” when the semantics of the data have not been settled up front.

The KPC approach: the Data Governance Office, a system within the system​

At KPC, the answer to these workstreams runs through building a Data Governance Office — a dedicated unit that ties together roles, people, quality, cataloging, lineage and compliance. Three organizational models coexist:

• Centralized​: One single DGO unit feeds every division. One view, consistent governance.
  (The most common)

• Federated: A shared foundation plus autonomy per vertical branch — balancing central consistency with local agility by domain.​

• Decentralized​: Independent flows per domain. Requires an excellent data culture. Risk of duplication and diverging definitions without a strong DGO. 

"The idea is to capture the documentation once, share it with everyone who produces or consumes the data, and make them as independent as possible."

Matthieu Augier - Data Governance Director, KPC.

KPC x dbt Labs webinar

KPC x dbt Labs webinar

In each of these models, the data people — data owners, stewards, custodians, engineers — own distinct scopes, but run into the same friction point: without shared, living documentation, everyone ends up rebuilding their own version of the truth. That is exactly where transformation tooling changes things.

How dbt brings governance into the pipelines

In practice, every governance pillar can be implemented with dbt Platform's native features — with no external tooling. The live demonstration went through them pillar by pillar.

1. End-to-end lineage and column-by-column traceability

The dbt DAG (Directed Acyclic Graph) gives a complete visual map: from the raw sources through to the final uses (Power BI and Tableau dashboards, AI models).

In a multi-project context with central, finance and marketing teams, each team only sees the public models — models not declared public are automatically protected. The lineage goes down to the column, so you can see exactly how each field has changed through the transformations.

"One morning your dashboard stops showing the figures you expect. With dbt Catalog, you go back to the model, check the status of the last orchestration, the test results and the lineage — without calling the data engineer." 

Hicham Babahmed - Partner Solutions Architect, dbt Labs.

KPC x dbt Labs webinar

2. Data contracts: governance before production

Defined in the dbt project's YAML files, the data contracts run before the model is even created — they block any data that would breach the contract from going live (wrong column type, out-of-range value, an IBAN that is too long, and so on). The difference with data tests is structural: the contract frames what you decide up front with the business; the test checks what you observe at runtime.

Data contracts can be shared and replicated: a contract validated on one object can be duplicated and adapted to a similar object, which speeds quality work up at scale. That is particularly powerful in a federated model where several teams feed the same data platform.

3. Catalog, metadata and semantic layer

dbt Catalog centralizes descriptions, types, tests, orchestration status and recommendations for every model. The semantic layer lets you define business KPIs that every team can reuse — and query in natural language through connected LLMs.

Role-based access control lets you manage who consumes the semantic layer, particularly for compute-heavy uses.

"More and more, business people come onto dbt Platform — not to write code, but to check that the data they are about to present in a meeting is the right data."

Hicham Babahmed - Partner Solutions Architect, dbt Labs.

KPC x dbt Labs webinar

The KPC view: Reducing friction between data and business teams

Across KPCengagements, what dbt brings comes down to one precise point: the friction between data and business teams. For years, that friction came down to a communication gap: business requirements were not written down, the data produced did not match expectations, and nobody had a shared point of truth. 

dbt then acts as a translator between the two worlds — and that is exactly what the platform unlocks. Business people can write their requirements directly in the platform, see what the models produce, and challenge the data engineers on quality — with no go-between. The people who know are no longer swamped: they document once, and the platform keeps answering.

Another operational benefit worth noting: dbt works as a cross-cutting layer across several platforms (Snowflake, Databricks, BigQuery, Redshift). In companies that have adopted several data clouds, it unifies governance without forcing a migration.

“ The Data Governance Office is a system within the system: it ties together the roles and the people — technical, business or hybrid: data owner, data steward, data custodian, data engineer. And it treats quality first as a matter of process, not just tools. ” 

Matthieu Augier - Data Governance Director, KPC.

KPC x dbt Labs webinar

What to take away from this webinar

• Effective governance does not live in a disconnected catalog tool — it lives in the dbt pipelines themselves.

• Automatic lineage + built-in documentation + data contracts = the three pillars of traceable, trustworthy data, from production onwards.

• Data contracts and data tests are complementary but distinct: the contract frames what you decide with the business up front; the test observes what happens at runtime.

• dbt fits all three organizational models (centralized, federated, decentralized) — the one we meet most often at clients is centralized. The dbt platform acts as a bridge between business and data — the people who know document once, and the platform keeps answering.