How to Prevent Bad Data from Reaching Production
The most reliable way to prevent bad data from reaching production is to make publication conditional on validation, so a bad change is never merged, but that is only one of three approaches teams use, and they work at different points in the data's life. Observability tools detect bad data after it arrives. Runtime validation catches it after the transformation runs. Transactional isolation stops it before it is ever published. Bauplan is the execution layer for AI-generated data changes, and it takes the third approach: bad data never reaches production because the merge gate rejects it atomically. The strongest setups often use all three, but it helps to be clear about what each one actually prevents.
TL;DR
- Three approaches prevent bad data, at three different moments.
- Observability (Monte Carlo, Bigeye): detects bad data after it is already in production.
- Runtime validation (Great Expectations, Soda): catches it after execution, before merge if you wire it that way.
- Merge-Gated Publication (Bauplan): bad data never reaches production; the merge gate rejects it atomically.
- The three are complementary, and mature teams combine them as defence in depth.
Approach 1: Data Observability, Detect Bad Data After It Arrives
Data observability tools such as Monte Carlo and Bigeye monitor production tables and alert you when something looks wrong: a volume anomaly, a freshness gap, a schema change, a distribution shift. They are strong at catching problems you did not know to check for, including issues that originate outside your pipelines, like an upstream source silently changing.
The defining characteristic is that they operate on data that is already in production. Observability detects and alerts; it does not prevent. By the time an anomaly is flagged, the data has been live, and downstream consumers may have used it. This is genuinely valuable for catching the unknown and the externally caused, but as a way to "prevent" bad data reaching production, it is detection after arrival, not prevention.
This distinction matters because observability answers a different question. It asks, "Has something gone wrong?" Prevention asks, "Can this change become visible at all?" One minimizes time to detection; the other removes an entire class of incidents. Mature systems usually need both.
Approach 2: Runtime Validation, Catch It Before Merging, After Execution
Runtime validation tools such as Great Expectations and Soda check data against defined expectations during the pipeline run. Compared with observability, this moves earlier: you are checking your pipeline's output as it runs, not scanning production after the fact.
How much it prevents depends on wiring. If the validation runs and, on failure, stops the pipeline before it publishes to production, it prevents the bad write. If it runs after the transformation has already written to the production table, it is closer to detection, and you are back to reacting. Runtime validation can be used to prevent bad data reaching production, but only when it is placed before the publish step and the pipeline actually gates on it. The tool provides the check; the prevention comes from the structure you build around it.
Approach 3: Merge-Gated Publication, Bad Data Never Reaches Production
Merge-gated publication changes what "prevent" means by making publication itself conditional. In Bauplan, every change runs on a zero-copy branch taken from production and writes only to that branch. Validation runs on the branch, and the branch merges to production only if it passes. If it fails, the branch is discarded and production never saw the change.
The prevention here does not depend on placement or discipline, because there is no path to production except the gated merge. Bad data is not caught quickly; it is never published, because publishing is defined as passing the gate. Pipeline authors do not need to remember to add the gate, because publication is already defined in terms of it. This is the architectural version of prevention: the system makes the bad state unreachable rather than detectable.
Which Approach for Which Team
The right approach depends less on maturity as a badge and more on what you are trying to stop.
If your problem is unknown and externally caused issues, upstream sources changing, drift over time, things no one thought to check for, observability earns its place, because detection is exactly the job. If your problem is your own pipelines producing wrong output, validation gated before publish prevents it, and transactional isolation prevents it by construction rather than by wiring. Early teams often start with a few runtime checks on critical tables. Teams running many pipelines, or letting AI agents write and run them, benefit most from isolation, because at that scale you cannot rely on every pipeline correctly placing a check, and you need the platform to enforce the gate.
Combining All Three: A Defence-in-Depth Strategy
These approaches are not competitors, and the strongest setups use all three at their respective layers.
Transactional isolation prevents your pipelines from publishing bad output, by gating the merge. Runtime validation expresses the specific, rich quality expectations that run inside that gate. Observability watches production for the problems the first two cannot see, the externally caused drift and anomalies that do not originate in a pipeline run. Layered, they cover prevention at publish time and detection afterward: Bauplan ensures a bad pipeline change never merges, your expectation suite defines what "bad" means in the audit, and Monte Carlo or Bigeye catches what enters from outside your pipelines. The point of defence in depth is that no single layer has to be perfect, because each covers a different failure and a different moment.
Frequently Asked Questions
Can Monte Carlo prevent bad data from reaching production?
Monte Carlo is a data observability tool: it monitors production data and alerts on anomalies such as volume, freshness, and schema changes. It detects problems, including ones that originate outside your pipelines, but it operates on data that is already in production, so it is detection after arrival rather than prevention before publish. To prevent bad pipeline output from reaching production, you need validation gated before the write or transactional isolation that blocks the merge. Monte Carlo complements those by catching issues they cannot see, like external drift.
What is the most effective way to prevent data pipeline errors in production?
The most effective single mechanism is to make publication conditional on validation, so a change that fails is never merged. Bauplan does this with a Write-Audit-Publish merge gate: changes run on an isolated branch and only reach production if they pass. In practice, the strongest approach combines this with runtime validation to express detailed quality checks inside the gate, and observability to catch problems that come from outside your pipelines. Isolation prevents your own pipelines from publishing bad data; the other layers cover the rest.
What is the difference between detecting and preventing bad data?
Detecting bad data means finding it, usually after it is already in production, and then reacting: alert, quarantine, roll back. Preventing bad data means it never becomes visible in the first place. Observability detects. Runtime validation can prevent if it gates the publish step. Transactional isolation, as in Bauplan, prevents by construction, because publication only happens through a merge that is conditional on validation.
Do I still need observability if I use Bauplan?
Yes, for a different job. Bauplan prevents your pipelines from publishing bad output by gating the merge, but it governs changes that flow through it. Observability tools watch production for problems that arise elsewhere, such as an upstream source changing or drift over time. The two cover different failures: Bauplan prevents bad pipeline writes, and observability detects issues that originate outside your pipeline runs. Defence in depth uses both.
