DatolioA data quality rule is a testable expression of a business expectation. The dimension classifies the failure; the rule says what must be true; the threshold and consequence say when people should act.
Start with the fields that influence a decision, not every field in a dataset. Profiled evidence can suggest a rule, but a human must decide whether the expectation, threshold and response make sense for the intended use.
Anatomy of a useful rule
- State the expectation Write a sentence a business user can confirm before choosing SQL or a no-code condition.
- Choose the dimension Use a dimension to explain the failure mode, not as a substitute for the rule itself.
- Define scope and tolerance Name the dataset, field, eligible population and acceptable threshold.
- Agree the response Assign severity, reviewer and action when exceptions exceed tolerance.
- Keep the evidence Retain run time, eligible rows, violations and a bounded sample so a score can be interpreted.
| Dimension | Business expectation | Threshold | Response |
|---|---|---|---|
| Completeness | Completed sales have a Customer ID | ≥ 99.5% present | Investigate source mapping below threshold |
| Accuracy | Sold quantity cannot be negative | 0 violations | Block weekly sales publication |
| Uniqueness | Transaction ID identifies one transaction | 100% unique | Merge or quarantine duplicates |
| Consistency | Completed sale customer exists in customer master | ≥ 99.9% matched | Review late master-data loads |
| Timeliness | Daily sales arrive by 08:00 UTC | 95% of days per month | Escalate repeated late delivery |
What good looks like
A pass rate without the eligible population, expectation and tolerance is not enough evidence to decide whether data is fit for use.