Como sei o que quebra downstream antes de mudar um modelo do dbt?

Uma coluna renomeada ou um modelo removido parecem seguros no diff de um PR se nada downstream referencia visivelmente aquilo no mesmo arquivo - isso não diz nada sobre o que realmente consome aquilo três modelos adiante.

O grafo de linhagem já existe - você provavelmente não está lendo ele

Toda execução do dbt produz o manifest.json, que codifica completamente o grafo de dependências do projeto - as fontes upstream e os consumidores downstream de cada modelo, já calculados. dbt ls --select +my_model+ lista tudo que é upstream e downstream de um modelo dado direto desse grafo, sem abrir o dbt docs nem rastrear a estrutura de pastas na mão.

Exposures transformam "downstream" em algo concreto

Uma entrada em exposures.yml liga um modelo a um consumidor real fora do próprio DAG do dbt - um dashboard, uma sincronização reverse-ETL, um relatório que alguém realmente olha. Sem exposures, "nada depende desse modelo" só significa que nada dentro do dbt depende dele, o que é uma afirmação mais fraca e muitas vezes enganosa se o consumidor real é uma ferramenta de BI que o dbt não enxerga.

Fazer isso antes de uma mudança que quebra algo, não depois

Rodar dbt ls --select +model_name contra o seletor de um modelo alterado como checagem de CI pre-merge pega o caso onde uma renomeação ou uma coluna removida quebra três marts downstream antes do PR ser mesclado - não depois que alguém percebe dias depois que um dashboard está silenciosamente errado.