DE//AGENT
Explore
Tutorial Lesson 6 of 10 · The Data Quality Series community intermediate

Review a schema change against its contract

Run the Schema Reviewer's four-step pass over a producer's schema diff — classify each field change, resolve consumers from lineage, emit a dated migration plan — and use the schema-drift runbook to separate hard failures from silent nulls before anything merges.

At a glance

When A producer PR touches a column a contract covers; A column appeared, disappeared or changed type upstream without notice
Where Data Contracts
Why A schema change shipped unreviewed is a loaded gun in the pipeline — hard casts break loudly, silent nulls break worse.

Learning objectives

  • Classify each schema change as compatible, risky, or breaking
  • Resolve the consumer impact set from lineage
  • Emit a migration plan with dates for any breaking change

What you need

  • Before/after schema for the change
  • A consumer list or lineage
  • [object Object]

Steps

  1. Diff the schemas field by field. (from agent-schema-reviewer )
  2. Classify each change: compatible, risky, breaking. (from agent-schema-reviewer )
  3. Determine whether the failure is hard (job error) or silent (nulls). (from runbook-schema-drift )
  4. Resolve consumers from lineage. (from agent-schema-reviewer )
  5. Emit a migration plan with dates. (from agent-schema-reviewer )
  6. Rename/removal is breaking; coordinate with consumers. (from runbook-schema-drift )

Check yourself

  • A diff narrowing decimal(18,2) to decimal(10,2) is classified risky and blocked as data-loss risky.
  • On a labelled set of 20 schema changes, every classification matches its label.

Worked example

Diff the old and new schema — from runbook-schema-drift 

diff <(parquet-tools schema old.parquet) <(parquet-tools schema new.parquet)
# Glue/Athena: compare catalog columns to the Parquet footer

Classification — compatible / risky / breaking — from skill-schema-change-contract-review 

- **Compatible** — new nullable column, widened type that preserves values.
- **Risky** — narrowing a type, adding a NOT NULL without a default, changing units.
- **Breaking** — rename, remove, or semantic change to an existing column.

Dated migration skeleton — from skill-schema-change-contract-review 

Add → dual-write → backfill → announce → migrate consumers → remove (dated).

Sourced from

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

  • Assume breaking when semantics are ambiguous.
  • Renames are removals in disguise; treat them as breaking.
  • A rename + a new column with the old name looks compatible to a schema differ — always diff semantics, not just names.

Production considerations

  • Never approve a breaking change without a dated plan.
  • Enforce a schema contract with a compatibility policy in CI.

Diagram

schema change review
   |
   |- field-by-field diff --> classify compatible / risky / breaking
   |
   |- hard failure or silent nulls? --> silent nulls keep the job green
   |
   |- consumers from lineage --> migration plan with dates --> approve or block

Registry stats

Verification community · Oct 21, 2026
Completeness 81
Trust multiplier ×1.25
Composite 34.15 · adequate
Freshness 3 days since last source check
Difficulty intermediate
Version 0.1.0
License CC-BY-4.0
Security flags none