Bronze, silver and gold as a working habit
What each layer is for, why the boundaries are load-bearing, and the mistake almost everyone makes at bronze.
You will see this drawn as three boxes with arrows. Drawn that way it looks like jargon for "clean your data". It is more specific than that, and the specifics are the useful part.
Bronze — exactly what arrived
Bronze is the source data, landed, with nothing fixed. Same values, same spellings, same nonsense. Add only technical columns: when it landed, which file it came from.
The rule people break is cleaning here. It feels efficient — you are touching the data anyway. It costs you the only copy of what the source actually sent.
That matters the day you discover a bug in your cleaning logic. If bronze is raw, you fix the logic and rebuild silver from bronze in an afternoon. If bronze was already cleaned by the buggy code, the correct data no longer exists anywhere and you are asking the source system for a backfill.
Bronze is your undo button. Do not spend it.
Silver — one clean, agreed version
Silver is where you fix types, standardise south/South/STH, drop duplicates,
apply the joins that give a row its meaning, and enforce a grain you can state in a
sentence.
The test of a silver table is that two teams reading it get the same answer to the same question. If they do not, the disagreement belongs here, not in their queries.
Gold — shaped for a specific use
Gold is aggregated and modelled for a consumer: a dashboard, a metric, a feature table, an export. It is allowed to be denormalised, redundant and opinionated, because it exists to serve one thing well.
Multiple gold tables from one silver table is normal and healthy. Multiple silver tables meaning the same thing is a problem.
Why the boundaries are worth defending
Under deadline, the pressure is always to write one job that reads the source and produces the dashboard table. It is fewer lines and it works.
What you lose: you cannot reprocess without re-fetching, you cannot tell a data problem from a logic problem, you cannot reuse the cleaning for the second dashboard, and you cannot answer "was it wrong, or did it change".
Those all arrive later, together, usually at the worst time. The layers are cheap insurance bought early.
Try this
Take a pipeline you already have and write down which of the three each existing table actually is — not which it was named. The mismatches are where your next incident is coming from.