dbt exposures document the downstream consumers of dbt models — the dashboards, reports, ML pipelines, and APIs that depend on your transformation outputs. Without exposures, the dbt lineage graph ends at the model layer; with exposures, you can trace impact from an upstream source change all the way to the business-facing dashboard that will break if the upstream changes.
dbt exposures are YAML definitions that document the downstream consumers of dbt models — the dashboards, reports, ML models, APIs, and other applications that depend on the transformation outputs that dbt produces. They are the mechanism for completing the dbt lineage graph: without exposures, lineage ends at the mart layer; with exposures, you can trace from a raw source table through every transformation to the Tableau dashboard or machine learning model that ultimately consumes the data.
Why Exposures Matter
The value of dbt is partly in the models themselves and partly in the graph that connects them. A dbt project without exposures is a graph with loose ends — you know what feeds into what within dbt, but you do not know what depends on your dbt outputs. This creates a governance gap:
When a data engineer modifies a model, they can see which other dbt models depend on it using dbt's lineage. But they cannot see that the modified model feeds the CFO's quarterly revenue dashboard, or that it is used by the marketing attribution ML model that runs every Sunday. That visibility — the downstream business impact of a data change — requires exposures.
With exposures defined, dbt ls --select exposure:* shows all exposures; dbt ls --select +exposure:finance_dashboard shows all models that the finance dashboard depends on. Impact analysis becomes systematic.
Exposure YAML Structure
Exposures are defined in YAML files, typically alongside the models they consume:
exposures:
- name: finance_revenue_dashboard
label: Finance Revenue Dashboard
type: dashboard
maturity: high
url: https://tableau.company.com/views/FinanceRevenue/Summary
description: >
Monthly and quarterly revenue dashboard used by the CFO and finance team.
Refreshed daily from the fct_orders and dim_customers marts.
depends_on:
- ref('fct_orders')
- ref('dim_customers')
- ref('fct_revenue_adjustments')
owner:
name: Sarah Chen
email: sarah.chen@company.com
Key fields:
**name** — a unique identifier for the exposure within the project.
**type** — the category of downstream consumer. dbt supports: dashboard, notebook, analysis, ml, application. The type is used for filtering and documentation display.
**maturity** — low, medium, or high. Indicates the governance maturity of the exposure — how well-maintained and trusted it is. A high-maturity exposure is a production dashboard with a named owner and regular review; a low-maturity exposure is an exploratory notebook.
**url** — a link to the downstream asset. For a Tableau dashboard, this is the dashboard URL; for a Jupyter notebook, the notebook URL.
**depends_on** — the dbt models (and seeds, snapshots) that this exposure consumes. Use ref() syntax to reference models by name.
**owner** — the person responsible for the exposure. Used for documentation and for impact analysis notifications.
Exposure Types and Their Governance Implications
The exposure type drives different governance considerations:
**dashboard** — production BI dashboards that business users access regularly. High visibility, high impact of changes. These are the exposures most important to document, as model changes that affect them will be noticed immediately by business users.
**notebook** — analyst notebooks (Jupyter, Databricks, Hex) that use dbt model output. Typically lower visibility than dashboards but important to document for completeness.
**analysis** — standalone SQL analysis scripts or ad-hoc analysis documents. Less formal than dashboards; may be used occasionally rather than on a schedule.
**ml** — machine learning models that use dbt outputs as features. Changes to upstream dbt models that affect ML features can degrade model performance without immediately obvious symptoms — a detection lag that makes lineage documentation especially important.
**application** — operational applications (web applications, APIs, operational systems) that read from dbt model outputs. These are the highest-risk downstream consumers: a breaking change in a dbt model can cause an operational application failure.
Using Exposures for Impact Analysis
The most important use of exposures is impact analysis before making model changes. dbt's --select syntax supports exposure-based selection:
Select all models upstream of an exposure:
dbt build --select +exposure:finance_revenue_dashboard
This builds every model that the finance dashboard depends on, in order. Use this to test a change to an upstream model while verifying the full downstream impact.
List all models that a specific exposure depends on:
dbt ls --select +exposure:finance_revenue_dashboard
List all exposures affected by changes to a specific model:
dbt ls --select fct_orders+ --resource-type exposure
This is the key impact analysis query: "if I change fct_orders, which exposures will be affected?" The answer is every exposure downstream of fct_orders — the dashboards and applications that stakeholders care about.
Exposures in dbt Documentation
dbt docs generate includes exposure information in the documentation site. For each exposure, the documentation shows:
- The exposure description and maturity level
- The owner's name and contact information
- The URL link to the downstream asset
- The lineage graph from source tables through models to the exposure
This documentation makes the analytics estate legible to non-technical stakeholders. A CTO reviewing the dbt documentation site can navigate from the CFO's dashboard back through every transformation to the raw source data — understanding the full provenance of the numbers.
Exposure Coverage as a Governance Metric
Tracking exposure coverage — the proportion of mart-layer models that have at least one documented downstream exposure — is a useful governance metric. A mart model with no documented exposures either has no downstream consumers (it can be considered for deprecation) or its consumers are undocumented (a governance gap).
Regular exposure audits:
1. List all mart models: dbt ls --resource-type model --select marts.*
2. List all models with documented exposures: dbt ls --select +exposure:* --resource-type model
3. The difference is mart models with no documented downstream consumers.
For organisations managing large dbt projects, this audit typically surfaces both genuinely unused models (candidates for deprecation) and undocumented consumers (governance gaps to address by adding exposure definitions).
Our data architecture practice designs dbt governance frameworks including exposure documentation standards for enterprise analytics teams — contact us to discuss analytics lineage and governance for your dbt project.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →