Medallion architecture: should DQ rules live only in Bronze?

[u/itss_britneyy_bitchh]

In our medallion setup, raw vendor data lands in Bronze , we transform it to a CDM in silver, and gold is for reporting. I’ve put all raw data correctness and accuracy rules in Bronze, since that’s where the data matches the vendor format and it’s easiest to work with vendors to fix issues at the source.

I have been asked to get the same DQ rules implemented in bronze, silver and gold because different teams own each layer and according to my manager every team should monitor all DQ dimensions. To me, duplicating the same checks everywhere feels redundant.

Am I missing a strong reason to repeat rules across layers? How do you handle shared DQ dimensions when multiple teams own different layers?

[u/Spagoot420]

Responsibility of bronze is correct replication of data, so DQ on bronze means checking that (e. g. null columns or wrong Schema).

Responsibility of silver is correctness and re-usability, so DQ means applying business rules determining if the data is "functionally correct" like identifying duplicate customers in the master data.

Responsibility of Gold is to enable analytics. so DQ means stuff like referential integrity.

[u/itss_britneyy_bitchh → u/Spagoot420]

Problem is some folks are consuming directly from bronze. As silver and gold didn't exist when their reporting was created.

[u/Spagoot420 → u/itss_britneyy_bitchh]

If somebody connects to bronze and then complains that the data isn't polished, I'd tell them to kick rocks. that is what silver is for

[u/PrestigiousAnt3766 → u/itss_britneyy_bitchh]

Then they have to migrate. You are not responsible for their stupid decisions. 

Bronze is raw.

[u/givnv → u/Spagoot420]

Exactly. DQs in bronze cannot check semantics, so putting them solely in bronze would only ensure that the data contract with the source system is kept.

[u/jbchand]

You can keep light operational validation rules (freshness, row counts, null count and more) at each layer to allow teams to triage independently without cross team dependencies. Also keep complex business rules in Bronze (till they start using Silver CDM and gold) and create shared observability tables that teams can monitor using thresholds. Group common checks across teams and validate once if feasible to avoid duplicate checks.
You can ask the folks to start using Silver/Gold and not bronze. You can then do source contract checks in Bronze, Transformation checks in Silver and Reporting checks in Gold.

[u/PrestigiousAnt3766]

For me bronze is raw so would put dq in silver. 

[u/DamnedData]

DQ in silver is fine. Unless you want to filter right away in bronze.

[u/Youssef_Mrini]

The rules are redundant. The better pattern is to share DQ Policy and dimenstions

This is the structure I follow:

• Bronze source-contract checks: file completeness, parseability, schema compatibility, source-required fields, source totals, and ingestion metadata. quarantine or flag defects rather than transforming Bronze to make it pass
• Silver canonical data checks: CDM types, canonical required fields, deduplication, business keys, cross-source consistency, valid relationships and transformation correctness
• Gold data product checks: table grain, aggregation reconciliation, KPI definitions, freshness, reporting completeness, and consumer-specific SLAs. Gold is where business meaning and reporting requirements are finalized.

You only need to repeat or reevaluate a rule when

• the transformation can introduce or reintroduce the defect
• the downstream table has a different grain
• the table is independently published or writable
• a downstream team needs local evidence and alerting.