Modelling correctness · rule staging-depends-on-staging
dbt staging models that read other staging models
A Metacenta review checks this under the rule Staging models read sources, not each other. Everything below applies whether or not you ever commission one.
What this rule checks
This rule flags staging models that read another staging model. We place a model in a layer from its path: a staging, intermediate or marts folder. If no model's path places it in a layer, the rule declines.
Why it matters
Staging stops being the one place a raw table is tidied. Reading a staged model no longer tells you what it contains; you have to follow the chain back.
How to fix it
Point each cleaning step at raw data, not at another cleaning step. Move the joining or reshaping logic into an intermediate model, and leave each staging model reading only its source.
Before:
-- models/staging/shop/stg_shop__orders_enriched.sql
select o.*, c.region
from {{ ref('stg_shop__orders') }} as o
join {{ ref('stg_shop__customers') }} as c using (customer_id)
After:
-- models/intermediate/int_orders_with_region.sql
select o.*, c.region
from {{ ref('stg_shop__orders') }} as o
join {{ ref('stg_shop__customers') }} as c using (customer_id)
When it is fine to leave
Some teams deliberately build a second staging model over the first, such as deduplicating after a rename. That is a defensible style, which is why we rate this low severity at medium confidence. Say so in the model's description.
What we need to check it
manifest.json alone. Layers come from folder names; marts folders are marts, mart, presentation or reporting. A project that uses no such folders is not judged here.
Published rules it corresponds to
dbt_project_evaluator, rule fct_staging_dependent_on_staging. Ours checks the same condition and threshold.
This means our check corresponds to their rule. It does not mean the publisher reviewed or endorses it.