## TL;DR
Exposures declare downstream consumers like dashboards and their dependencies, and validation fails when a declared dependency does not exist, is misspelled, or is not built by the project. Read the validation error for the exact exposure and dependency name, fix the reference or add the missing model, and revalidate. Exposures are documentation with teeth: a wrong reference fails the build on purpose.

```text
dbt exposures validation failed
```

## Use this when
- dbt fails with an exposures validation error.
- A dashboard or ML model was added as an exposure recently.
- Model renames broke exposure references.

## Not for this skill when
- Exposures validate but show outdated info. Refresh the docs instead.
- You want to add a new exposure type. Check the schema spec first.

## Steps
1. Read the validation error for the exposure name and the bad dependency reference. Note the exact names. Verify: the broken reference is identified
2. Check whether the referenced model, source, or metric exists under that exact name. Note the correct name. Verify: the right name is known
3. Fix the exposure definition: correct the name, or add the missing model to the project. Note the YAML parses. Verify: the reference is repaired
4. Re-run validation and confirm it passes. Note the exposures section is green. Verify: validation is clean
5. Add exposure checks to CI so renames break the build before they break the docs. Note the guard is in place. Verify: future renames are caught

## Variant phrasings
### dbt exposure depends_on validation
The YAML-shaped search.
### dbt exposures.yml invalid
The file-shaped phrasing.

Compatibility: dbt Core 1.x. Exposure schema is stable; validation runs during parse.

## Why it happens
Exposures exist so dbt knows what breaks when a model changes: dashboards, notebooks, reverse-ETL syncs. For that to work the dependency references must be real, so dbt validates them at parse time and fails the build on a dangling reference. The failure is the feature. Most breakage comes from model renames where the exposure YAML was not updated, which is exactly the drift exposures are meant to catch.

## Edge cases / pitfalls
- Exposures can reference metrics and saved queries too, not just models. The same naming rules apply.
- A model that exists but is disabled still fails exposure validation. Disabled is not built.
- Exposure owners and maturity fields are free text, but depends_on is validated strictly. Typos only hurt in the dependency list.
- Large projects validate exposures on every parse, so a broken exposure blocks all runs, not just docs. Fix it fast.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DV-rzhBatdEnko9DIQBprQ