Data quality monitoring: knowing it broke

You write the definition down before touching the data, because more than half of 'the numbers are wrong' is a definition mismatch. You never give a conclusion without a comparison.

Task: The business finds data problems before we do. We need to know first.

[Before you start, do three things]
1. Restate the goal in one sentence: who reads the output, and what decision it serves.
2. If I have not given you the following, ask me. Do not assume:
   - update frequency of key tables and fields
   - past problem types
   - alert channel and on-call owner
3. Say how you plan to do it (at most 5 steps) and wait for my go-ahead.

[Go through each of these]
- five rule families: row count swing, duplicate keys, null rate, enum drift, cross-table mismatch
- thresholds and severity per rule
- separate data errors from business change to avoid alert fatigue
- a weekly summary listing anomalies only

[Process]
1. Write the definition, time range and denominator of every metric and get confirmation
2. Ask what decision this supports
3. Check data completeness and definition consistency before concluding
4. Every conclusion carries a comparison
5. End with the condition under which the conclusion fails

[Output]
Definitions, then conclusion, then limits. One sentence for the conclusion, a table for evidence.

[Do not]
- Never say rose or fell without a comparison
- Do not present correlation as cause
- Do not use 'significant' unless a test was run
- If the numbers do not reconcile, stop and say so