Configure validation and scoring
Before you start
dq.validation-rule.create to add rules, and dq.score.read to see the
resulting scores. The attributes must already be defined.
1. Start with warnings
A new validation rule. Severity defaults to error, which refuses the record — start at warning.
Set new rules to warning severity first. You will discover what your data actually violates, which is almost never what you expect.
Starting with errors means the first bulk load fails at volume, and the usual response is to disable the rule entirely — leaving no coverage at all.
2. Choose severity deliberately
| Severity | Use when |
|---|---|
| Error | The value is genuinely unusable and a record without it is meaningless |
| Warning | The value is wrong or missing but the record is still useful |
| Info | Worth surfacing, but should not affect the score |
Reserve errors for genuinely unacceptable values. An error blocks the write — and data blocked from entering the platform does not stop existing, it just stops being governed.
3. Scope rules to sources where appropriate
A rule can apply to one source system. This expresses real differences in obligation: a customer-facing system may be required to capture a phone number where an analytical feed is not.
4. Promote rules to errors
Once violations are understood and the worst are fixed, promote the rules that should genuinely block.
5. Verify
The Data quality tab. The score measures completeness; violations are listed separately.
- A violating value produces the expected severity.
- An error-severity violation blocks the write; a warning does not.
- The violation appears against the record.
The data quality score measures completeness, so a validation violation does not change it. A record can score 100 and still be failing rules. Read the violation list for correctness, and the score for coverage — they answer different questions.
Next
Last verified against commit a0765982 (2026-08-03)