A platform lands raw order events in bronze, types and cleans them in silver, and builds a revenue table in gold. Finance finds that orders in three currencies have been converted at the wrong rate since July - the conversion is a CASE expression in the silver transformation. Which correction is the layering there to make possible?

What is being tested

Whether you know what the layers are for. Bronze, silver and gold are not three stages of tidiness. The layering exists so that a defect in transformation logic can be corrected by changing code and re-running, with no appeal to anyone's memory of what the source said in July.

The reasoning

The wrong rate is in silver's logic, so the fix belongs in silver's logic. Bronze still holds the raw orders exactly as the source sent them, with the original currency and amount, which means every affected day can be rebuilt: change the CASE expression, re-run silver for July onward, re-run the gold revenue table from the corrected silver.

Three properties make that work, and all three have to be deliberate:

• Bronze is immutable and complete for the window you may need to restate. If bronze keeps 30 days and the defect is three months old, the rebuild is impossible and the answer changes entirely.
• The transformation is a pure function of a logical date, so re-running 2026-07-04 produces the same output whether it runs once or five times. A load that appends without a partition overwrite turns a rebuild into duplicates.
• Gold is derived, never authored. The moment someone hand-edits gold, the next rebuild silently reverts it and the numbers oscillate.

Expect the rebuild to cost real compute: roughly 90 days of silver and gold, which on a mid-sized platform is hours, and it competes with the nightly load. Schedule it, do not fire it at 09:00.

Why the other options fail

• Correct the values in bronze. This is the common instinct and it destroys the only copy of the truth. Bronze is the evidence that the source said 1.09 and the pipeline applied 1.90. Edit it and the defect becomes unprovable, the auditor's question unanswerable, and a second defect found later cannot be separated from this correction.
• Patch the gold rows. It fixes one table and leaves silver wrong, so every other consumer of silver - the finance extract, the forecast model, the dashboard nobody told you about - stays wrong, and the next scheduled gold build overwrites the patch.
• Add an offsetting adjustment table. Legitimate in accounting, wrong here. It leaves two sources of revenue truth and every future query has to know to subtract the adjustment. Reserve this for periods that are formally closed and may not be restated.

When this is the wrong answer

When the period is closed. If finance has filed on those numbers, a silent rebuild changes a signed figure. Then the correct move is the offsetting adjustment plus a restated version published under a new as-at date - and the rebuild still happens, into a separate table, so the two versions are both explainable. The layering makes the restatement possible; the business decides whether it is allowed.