Quarantine, flag, fix or delete? Choosing what happens to bad rows

Fix only when the correct value is certain

Trimming padding from a code or lowercasing an email under a declared policy are fixes: the correct value follows from the rule. Replacing a malformed amount with a plausible number is not a fix; it is an invention.

Quarantine what can't be used

A row with an impossible value, a missing required field or an unknown reference can't go into the clean table. Quarantine moves it to an exception table with a reason, so the row isn't lost and the source can be corrected.

Flag what is unusual but possibly real

A very large order or a negative refund may be perfectly valid. Flagging adds a marker column and keeps the row, so analysts can include or exclude it on purpose and the population doesn't silently change.

Delete only what is out of scope by rule

Filtering rows that the analysis explicitly excludes (test accounts, a different year) is legitimate when the rule is written down and the count is reported. Deleting rows because they are inconvenient is not.

• Fix: the rule makes the correct value certain.
• Quarantine: the row breaks a rule and can't be used.
• Flag: the value is unusual but may be real.
• Filter: the row is outside a declared scope.