What is the Write-Audit-Publish pattern?

Write-Audit-Publish (WAP) is an architectural pattern for data pipelines that separates writing from publishing into three distinct phases. In the Write phase, new data is written to a staging area or an isolated branch, not yet visible to data consumers. In the Audit phase, automated quality checks run against that staged data: completeness, uniqueness, schema consistency. In the Publish phase, only if the checks pass, the data becomes visible in the production table, typically through an atomic operation such as a pointer swap or a transactional commit. The key point is that a data error never reaches production consumers, because it gets isolated before publication, not after. The pattern originated at Netflix, described by Michelle Winters in 2017, and can now be implemented natively thanks to open table formats that support branching and staging, such as Iceberg.

Where data quality ends and WAP begins

Data quality defines WHAT to check: completeness, accuracy, uniqueness, cross-system consistency. WAP is not a quality check in itself, it is the architecture that decides WHERE and WHEN in the pipeline those checks run. Without WAP, quality checks run against data already in production, and a discovered fault is a fault that has already reached the dashboards. With WAP, checks run against isolated staging before the data becomes visible, so a failed check blocks publication instead of merely flagging damage already done. The same distinction applies to data observability, which monitors the health of already published data over time to catch drift and anomalies: WAP acts earlier, as an admission gate, not as ongoing surveillance over what has already passed through.

A concrete enterprise example

A nightly sales batch arrives with a bug in the upstream ETL that duplicates a subset of rows. Without WAP, that batch gets written directly into the production table: the next morning's finance dashboards show inflated revenue, and someone notices only when the numbers stop matching the accounting system, hours or days later. With WAP, the same batch is first written to a staging branch; the audit phase runs a uniqueness check on the order key, finds it violated, and blocks publication. Production consumers never see that batch: they keep working off the previous night's data until the upstream issue is fixed and the cleaned batch passes audit.

Why it matters to decision makers

The cost of a data incident depends almost entirely on when it is discovered. A problem caught during audit costs the time of a fix and a release delayed by a few hours. The same problem discovered after publication costs the trust of everyone who already made decisions on wrong numbers, the time to trace every downstream report and model that used them, and often a public correction. Adopting WAP means moving that cost to before publication instead of after, which is why it becomes an architectural priority as more business decisions, including ones made by AI agents, depend on pipelines nobody checks by hand anymore before the data reaches downstream consumers.