Reading: Part 12. Data Contracts: ODCS and dbt Contract Checks

Lesson 1 of 5 in module «Part 12. Data Contracts: ODCS and dbt Contract Checks»

You are viewing the lesson without signing in. Sign in to save progress and take tests.

Source

Part 12. Data Contracts: ODCS and dbt Contract Checks

A data contract is needed so that the downstream consumer sees the promise of the product, not just the current implementation. In SDD Data a contract is not decorative YAML. It is a verifiable layer between the product promise and SQL.

Two Levels of Contract

ODCS is responsible for the technical contract of a data product: schema, quality, SLA, and breaking changes. The dbt model contract is responsible for the shape of a specific dbt model. In the training example we use models/schema.yml, built-in dbt tests, and singular tests as the minimum contract checks; contract.enforced: true is not enabled, so as not to mix the first training pass with the limitations of a specific adapter. In a production pipeline it can be enabled where the adapter and materialization support it.

Contract Drift

Contract drift occurs when the model changes but the contract does not. For example, mart_customer_360 gets a new column product_code, but the grain is still described as "one row per customer_id". This is more dangerous than a syntax error: dbt can pass, and the consumer gets a different meaning.

Drift comes in three types:

schema drift: fields added/removed/renamed;

semantic drift: a field remained, but its meaning changed;
process drift: validation.md or the reviewer's report do not reflect the change.

Relationship Between Contract and Tests

A contract must be backed by evidence. If ODCS says that risk_event_count_7d is mandatory, then there must be at least one test or a manual fact from a reviewer that confirms the presence and behavior of not_null. Otherwise the contract remains a promise without evidence.

Qwen Query

Compare specs/customer_360_contract.odcs.yaml,
specs/models/mart_customer_360.md, models/schema.yml, and
models/marts/mart_customer_360.sql.
Find contract drift and gaps in test coverage. Do not modify the files.

Minimum Output

Write a note about the impact on the contract:

Changed fields: none
Breaking change: none
PII impact: direct PII is not exposed in mart
SLA impact: none
Check coverage: unique/not_null for customer_id, mandatory fields, list of forbidden PII
Confirmation needed: no

For future PRs this block should be part of the change description.

Breakdown for the Reader

A data contract is not needed for the beauty of YAML. It is needed so that a consumer can rely on the shape and meaning of the mart without reading the SQL every time. In normal development, a public API cannot be changed silently; in data the situation is the same, only the API often looks like a table. A column, grain, freshness, and PII policy are parts of the interface.

ODCS, dbt contract checks, and schema tests cover different levels. ODCS speaks about the product and its technical promise. schema.yml and tests confirm part of the shape. Singular tests catch rules that do not fit into standard checks. No single layer replaces the others. If only dbt tests are kept, you can get a green model with the wrong meaning. If only ODCS is kept, you can get a beautiful contract without evidence.

Contract drift is especially unpleasant because it often looks like a useful improvement. A column was added. The granularity was expanded. A metric was renamed "for clarity". Each step on its own seems small, but the downstream consumer may receive a different set of rows or a different business metric. Therefore, the impact on the contract must be described even when the change seems safe.

In this chapter it is important to learn to read a change as a reviewer. The question is not "did the SQL get better" but "did the promise remain the same". If the promise has changed, explicit human confirmation is required. If the promise has not changed, that also needs to be proven: which fields are the same, which grain is the same, which PII are not exposed, which tests passed.

Practice

Compare customer_360_contract.odcs.yaml and models/schema.yml. List the mandatory fields and indicate which dbt test, singular test, or manual fact covers them.

Common Mistake

Assuming that adding a column is always safe. Even a nullable column can change consumer expectations if it looks like a new business metric or changes the grain.