One agreed way of working
Bronze, silver, gold layers and reusable models give every team one contract, so questions become queries, not rebuilds.
Agree the layering once, encode it in dbt, and the structure carries the discipline.
Ask three teams where the trusted customer table lives and you will get three answers. One points at customers_final, another at dim_customer_v2, a third at a platinum tier somebody added last quarter. Each was built in good faith. Together they are why nobody can say, with confidence, which number is the real one.
This is two of the most expensive habits in hand-rolled data work, side by side. The first is modelling that flattens everything into one wide table built to answer one question, so the moment the question changes, you start again from raw. The second is layering by accident: bronze here, silver there, an improvised final_v2 everywhere, with no shared agreement on what each stage is supposed to guarantee.
What dbt does about it
dbt gives the whole organisation one agreed way to structure transformation: staging, into intermediate, into marts, flowing through clear bronze, silver and gold layers. Bronze is raw, landed as-is. Silver is cleaned and conformed, one definition per entity. Gold is business-ready, the models reporting reads from. Crucially, grain is preserved along the way, so models stay reusable. A new question becomes a query against a model that already exists, not a fresh pipeline built from scratch. There are no ad-hoc platinum tiers and no final_v2, because the convention is written down and enforced in code. dbt’s own guide to structuring a project lays out the same discipline.
What it looks like
Marketing needs revenue by campaign. Instead of pulling raw orders and re-deriving revenue (their own way, subtly different from Finance’s), they query the gold fct_orders model that already carries the agreed revenue definition, and join it to campaigns. The work takes an afternoon, not a sprint, and the number matches Finance’s by construction. The next team that needs orders builds on the same model, and the value compounds.
How we think about it
One layering, agreed once, beats ten conventions improvised forever. We treat the layer contract as a shared asset, not a personal preference: settle it, encode it in dbt, and let the structure carry the discipline so people do not have to. It pairs naturally with a data catalog everyone trusts, where those same layers become documented, discoverable lineage. The result is a data estate where growth means more questions answered, not more rebuilds.
One agreed way of working, in short.
What do bronze, silver and gold actually mean?
They are three agreed stages. Bronze is raw data landed as-is, silver is cleaned and conformed with one definition per entity, and gold is the business-ready models that reporting and BI read from. The names matter less than the contract: everyone knows what each layer guarantees, so nobody has to guess where trusted data lives.
Do we have to adopt your exact layers?
No. The point is that your team agrees on one layering and sticks to it, not that you copy ours. We help you settle the convention that fits your estate, then encode it in dbt so it holds. What you avoid is the alternative: ten teams, ten conventions, and a platinum tier nobody can explain.
What about the models we already have?
They are the starting point, not something to throw away. We map your current tables onto the agreed layers, keep the logic that works, and refactor the over-flattened ones so granularity is preserved. It is an incremental move, layer by layer, not a rebuild from zero.
How does this actually help reuse?
When models keep their grain and sit in known layers, a new question is usually a query against an existing model, not a new pipeline. Teams build on each other's silver and gold instead of re-deriving the same metric five ways. One contract is what makes the work compound rather than repeat.
Keep exploring
Change without fear
Modular, version-controlled models with tests mean a change is reviewed, tested and reversible, not a leap of faith.
Faster, cheaper runs
Incremental models process only what changed, so runs are faster, compute costs less, and the warehouse is under less strain.
Change shared models without breaking everyone
When a shared model changes, it can silently break every team downstream. Model versions and contracts let a central team ship a new version while consumers migrate on their own schedule.
Want this for your data?
If this is how you want your team to work, we should talk.