Data quality at a glance
Two separate capabilities, easily conflated.
| Answers | Mechanism | |
|---|---|---|
| Validation | Is this value acceptable? | Rules evaluated on write |
| Scoring | How complete is this record? | A 0–100 completeness measure |
The score is completeness
| Signal | Is |
|---|---|
| Completeness | The score. How much of what should be filled, is |
| Freshness | Reported alongside it, separately |
The score is not a weighted blend of accuracy, consistency, and uniqueness — those are not dimensions of it. Validation outcomes are recorded as violations; duplication is the concern of matching.
Read the score for coverage and the violation list for correctness. They answer different questions, and a validation failure does not move the score.
Validation rule types
| Type | Constrains |
|---|---|
| Regular expression | Format |
| Range | Numeric or date bounds |
| Length | String length |
| Lookup | Membership of a controlled list |
| Unique | Non-repetition within a scope |
| Cross-field | A condition on one attribute given another |
| Custom | A named validator |
Severity is the operational lever
| Severity | Blocks the write |
|---|---|
| Error | Yes |
| Warning | No |
| Info | No |
Start with warnings. You will discover what your data actually violates, which is rarely what you expect — and starting with errors usually ends with the rule being disabled entirely, leaving no coverage at all.
Reserve errors for genuinely unusable values. Data blocked from entering the platform does not stop existing; it stops being governed.
Fails loudly
A rule whose configuration cannot be evaluated is rejected when you save it. A rule that silently never fires looks like coverage and is not.
Next
Last verified against commit 1e1de1ad (2026-08-03)