Write-Audit-Publish: Never Promote a Bad Table Again

Most quality checks run after bad data is already live. You load the table, then test it, then
discover the problem — but by now a dashboard already served wrong numbers, or an agent already
answered with them. Write-Audit-Publish (WAP) flips the order: you prove the data is good
before anyone can see it.

The three steps

1. Write — build the new data into a staging location consumers can't see: a temp table, a separate schema, or a zero-copy clone/branch of the target.
2. Audit — run your quality gates against that staged copy: uniqueness at the grain, row-count vs baseline, freshness, reconciliation against a trusted source.
3. Publish — only if every check passes, promote the staged data to production with an atomic swap (a rename or clone-swap), so consumers flip from old-good to new-good with no bad state in between. If a check fails, nothing is published; production keeps serving the last known-good data while you investigate.

Why it's better than audit-after-load

• Consumers never see bad data. The failure mode becomes "today's refresh is delayed," not "the dashboard is wrong." Stale-but-correct beats fresh-but-wrong almost every time.
• The swap is atomic. No window where half the table is updated and queries see a mix.
• Rollback is trivial. The previous version is still right there; promoting it back is one operation.

Making it cheap

The pattern used to be expensive — you'd copy the whole table. Modern warehouses make it nearly
free with zero-copy clones and table/catalog branching: you stage on a clone, audit it,
and publish by swapping pointers, with no bulk data movement. That's what turned WAP from a
nice-to-have into a default.

Where it fits in your stack

Wire the audit step to the same tests you already write (dbt tests, a data-quality scan) and let
their result gate the publish. The mental model: your transformation job doesn't "load the
table," it "proposes a new version," and only a passing audit promotes it.

Takeaways

• Validate on a staged copy and publish only what passes — consumers never see bad data.
• Promote with an atomic swap so there's no half-updated state, and rollback is one step.
• Zero-copy clones and branching make WAP cheap enough to be the default.
• Reframe loads as "propose a version"; a passing audit is what makes it live.