## TL;DR
Read the manifest diff before rebuilding: a schema change detected error means the built model's columns no longer match what the manifest or contract recorded, so compare the model SQL's output columns with the recorded schema, then either restore the dropped or renamed column or update the contract and downstream references deliberately. Blind reruns repeat the same detection.

```text
dbt run error: test failed in manifest with schema change detected error
```

## Use this when
- The check or run fails with this symptom: dbt reports a test or contract failure tied to a schema change in the manifest.
- You are working on a dbt run that stops on a detected schema change 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 test failure on values rather than schema, where the columns match and the data is at fault instead.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Open target/manifest.json and the compiled model SQL and list the output columns each one describes. Verify: the recorded schema and the actual output columns are side by side
2. Diff the model SQL against the last committed version to find the dropped, renamed, or retyped column. Verify: the exact column change is identified
3. Search the project and downstream dashboards for references to the old column name or type. Verify: every downstream reference is listed
4. Choose deliberately: restore the column for compatibility, or update the contract, the schema.yml entry, and the downstream references in the same change. Verify: the schema and all references agree again
5. Run dbt build for the model and its children and confirm the manifest regenerates without a schema change warning. Verify: the build completes and the new manifest matches the model

## Variant phrasings
### dbt schema change detected manifest error
The verbatim manifest phrasing.
### dbt contract schema change column renamed
The contract phrasing for renamed or dropped columns.
### dbt test failed schema change on run
The run-output phrasing users paste from CI.

Compatibility: dbt Core 1.5 and later with schema.yml contracts and manifest artifacts

## Why it happens
dbt records model schemas in the manifest and, with contracts or state selection, compares new output against that record. Any column rename, drop, or type change trips the detection even when the new schema is intentional, because downstream consumers may still depend on the recorded shape.

## Edge cases / pitfalls
- State selection against a stale manifest creates phantom changes. Regenerate the baseline manifest from the main branch.
- Type widening, such as int to float, counts as a schema change for strict contracts. Treat it as a breaking review item.

## Provenance

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