Bad rows shouldn't reach the warehouse

Two bad options, and the one nobody should pick

A row violates a rule — a null where you require a value, a negative amount, a broken enum. There are three things a pipeline can do: abort the run, quarantine the row, or silently drop it. The third is the one that ruins your data quietly, and it's the one faucet-stream never does.

Quality checks decide, per rule, before the write

Quality is a stage in the movement path — it runs on each page before the sink sees it. Every check declares what happens on failure:

quality:
  checks:
    - { field: amount, rule: { gte: 0 }, on_failure: abort }
    - { field: email,  rule: not_null,        on_failure: quarantine }

• abort — stop the run. Use it for violations that mean the whole batch is suspect.
• quarantine — route the offending row to a dead-letter queue, and let the good rows through. The bad row is captured, not discarded.

Quarantine needs somewhere to go

And because governance runs in a fixed order with masking first, a quarantined row carries the masked payload, not the raw one — a bad row never leaks a secret into the DLQ. (More on that ordering in the governance paper.)

Takeaway

Invalid data stays out of the target, valid data keeps flowing, and nothing vanishes without a trace. Abort when the batch is untrustworthy; quarantine when it's a few bad rows — and never pick the silent third option, because faucet won't offer it.