Validating and scoring data quality
Two related capabilities: validation constrains what values are acceptable, and scoring measures how good a record actually is.
Validation rules
Validation rules, each carrying the severity that decides whether a violation blocks the write.
A validation rule is a constraint evaluated when a value is written.
| Rule type | Constrains |
|---|---|
| Regular expression | The value must match a pattern |
| Range | A number or date must fall within bounds |
| Length | A string's length |
| Lookup | The value must exist in a reference-data list |
| Unique | The value must not repeat within a scope |
| Cross-field | A condition on one attribute given another |
Severity decides consequences
| Severity | Effect |
|---|---|
| Error | Blocks the write. The value must be fixed. |
| Warning | Allows the write, records the violation, and lowers the score |
| Info | Recorded for visibility; does not affect the score |
Severity is the lever that matters operationally. Making everything an error means bad source data cannot land at all — which sounds strict but usually means it lands somewhere else, unmanaged. Warnings let it in where you can see and fix it.
Source-scoped rules
A rule can be scoped to one source system, expressing constraints like "a phone number is required from the CRM but optional from the data warehouse". Systems have different obligations, and the model reflects that.
Data quality scoring
Each record carries a score from 0 to 100 measuring completeness: how much of what should be filled, is. Freshness — how recently the record was updated — is reported alongside it as a separate signal.
It is not a weighted blend of several dimensions, and there is nothing to weight per tenant. Validation outcomes are recorded as violations, not folded into this number, and duplication is the concern of matching.
This matters when reading a score: a record scoring 100 is complete, not correct. Read the violation list for correctness.
The number alone is not actionable — "72" tells nobody what to fix. Use the score to rank records by how much attention they need, and the violation list to decide what to do.
Configuration fails loudly
A validation rule whose configuration the engine cannot evaluate is rejected when you save it, rather than accepted and silently skipped. A rule that silently never fires is worse than no rule, because it looks like coverage.
Advice
- Start with warnings. Understand what your data actually violates before making anything blocking.
- Reserve errors for genuinely unacceptable values, not merely undesirable ones.
- Weight the dimensions to your use case rather than leaving them equal by default.
- Fix upstream where you can. A rule that fires constantly is describing a source system problem.
Next
Last verified against commit 315eb047 (2026-08-03)