## TL;DR
A new upstream column breaks downstream checks that assert an exact column set: diff the upstream table schema against the schema the downstream check expects, decide whether the new column should flow through, be ignored, or be explicitly excluded, and update the contract in one place. Pinning the check to fail on any addition guarantees this recurs on the next upstream release.

```text
schema drift error: new column added upstream failed downstream schema check
```

## Use this when
- The check or run fails with this symptom: the downstream schema check fails right after an upstream column appears.
- You are working on a downstream schema check failing after an upstream table gained a column and the failure repeats on the same data or configuration.
- You need the failing rows, rule, or stage isolated before changing thresholds or code.

## Not for this skill when
- A removed or renamed column, which is a breaking change needing a model fix rather than a contract update instead.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Diff the current upstream schema against the expected schema recorded in the check or contract and name the added column and its type. Verify: the added column is named with its type
2. Find who owns the new column and whether downstream models are expected to use it, ignore it, or block on it. Verify: the column has an owner and an intended treatment
3. Update the model to select columns explicitly instead of relying on star expansion where the contract is strict, or extend the contract to include the column. Verify: the model selection and the contract agree
4. Rebuild the downstream model and rerun the schema check on the new upstream shape. Verify: the schema check passes with the new column present
5. Add a schema-change notification or contract test at the upstream boundary so the next addition is announced, not discovered. Verify: the boundary check or notification is in place

## Variant phrasings
### schema drift new column added upstream
The verbatim new-column phrasing.
### downstream schema check fails after upstream change
The downstream-impact phrasing.
### new column breaks dbt model schema test
The dbt-specific phrasing for schema tests on sources.

Compatibility: dbt, Soda, and Great Expectations schema checks against Snowflake, BigQuery, and Postgres tables

## Why it happens
Checks that enumerate expected columns treat any addition as drift, even though adding a column is normally backward compatible. Star selects, strict contracts, and schema tests written against a snapshot all turn a safe upstream evolution into a downstream failure.

## Edge cases / pitfalls
- Explicit column lists in critical models cost maintenance but remove this whole failure class.
- Coordinate contract changes with the upstream release notes. A column added for a migration may be dropped again soon.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3BJ4b8QdqvJN2EBcbPeNgQ