A data quality rule states an expectation that can be evaluated against a defined data population. A reusable rule also records its business meaning, owner, version, and valid exceptions so another team can judge whether it applies to a new asset.
Profiling can suggest where a rule may be useful. It does not establish that a common pattern is a mandatory business requirement. Review the meaning before activating a suggested rule.
Use twelve rules as specification examples
The examples below are illustrative requirements, not production thresholds or executable syntax. Adapt the population and exception treatment before implementation.
| Rule | Population and expectation | Exception or review point |
|---|---|---|
| Required order key | Eligible completed order lines have order_id and line_id | Draft populations may have different requirements |
| Unique line key | order_id plus line_id identifies one eligible line | Versioned records need a version-aware key |
| Valid currency | Currency belongs to the approved list | Unknown codes require review, not guessing |
| Nonnegative quantity | Quantity is nonnegative in ordinary sales lines | Returns and adjustments require explicit treatment |
| Allowed status | Status belongs to the approved lifecycle | New statuses need owner approval |
| Date sequence | Completion date is not before creation date | Timezone and correction rules must be aligned |
| Customer reference | Required customer keys resolve to the approved reference scope | Approved unknown members must be documented |
| Net amount | Amount follows the approved price and discount rule | Null discount treatment must be explicit |
| Timely delivery | The required load completes before the business deadline | Agreed maintenance windows need separate handling |
| Population completeness | Eligible source keys appear in the expected target | Late arrivals follow an approved cutoff |
| Reconciliation | Matched records agree under the approved mapping | Unit, currency, and rounding differences need rules |
| Distribution review | A material behavior change is reviewed | An anomaly is a signal, not automatic proof of error |
Convert a profile finding into a reviewed rule
Suppose profiling shows that nearly all customer_id values are unique. The suggested rule is “customer_id must be unique.” Before approval, inspect the dataset grain. A customer-history table can contain several valid versions per customer, so the appropriate requirement may use customer_id plus effective_from, together with a rule against overlapping active intervals.
The review should record the accepted rule and the rejected interpretation. That history helps prevent another team from reintroducing the same unsuitable uniqueness assumption.
Store a reusable specification
For each rule, retain its purpose, eligible population, fields, logic, threshold, severity, owner, version, and exception treatment. State whether the rule is a suggestion, approved definition, active control, or retired rule.
Separate the general definition from its asset-specific binding. A required identifier rule can be reused conceptually, while the actual field, scope, and severity differ between products. Reuse should preserve meaning rather than encourage blind copying.
Define the denominator before reporting a rule score
A rule percentage needs an explicit eligible population. Suppose an illustrative batch contains 1,000 orders, including 100 drafts that do not yet require a shipment date. Of the 900 completed orders, 18 are missing the required date. Completeness for that requirement is 882 divided by 900, or 98 percent. Dividing by all 1,000 orders would answer a different question.
Record how exclusions are identified and whether an excluded record remains visible to the reviewer. The draft population may need its own aging check even though it is outside the completed-order rule. Exclusion from one control should not make an important business population disappear from oversight.
Keep operational failures separate from quality failures. If the shipment reference was unavailable, report that the test could not establish the result. Do not reuse yesterday's score as today's evidence. A rule result should show both the defined denominator and whether the execution examined the intended scope successfully.
Test expected failures and valid exceptions
Build a small test population with a known pass, a known failure, and a valid exception. Confirm the reported denominator and treatment of nulls. Record whether a failed reference means an invalid key or an incomplete reference extraction.
After activation, inspect recurring exceptions and owner response. A rule that creates noise may have a scope problem, a source defect, or an unreviewed business change. Do not simply lower the threshold without recording the reason and consequence.
Assign severity according to the decision the rule supports
A missing optional description and an incorrect settlement amount should not automatically receive the same response. Agree on severity with the business owner and identify which failures stop a process, require investigation, or enter a maintenance queue. A threshold only becomes meaningful when its consequence is understood.
Test boundary values around the approved threshold. If a maximum delay is specified, define the timezone, observation point, and treatment of scheduled pauses. If a permitted numerical difference is specified, record its unit and rounding rule. These details prevent teams from interpreting the same control differently across environments.
Group related failures for investigation without hiding the individual requirements. A missing customer reference can trigger several downstream checks. Link those results to the suspected cause where justified, while preserving the evidence for each rule. This reduces duplicate investigation without declaring a cause before it is established.
Govern the rule lifecycle
Reassess a rule when the data grain, business definition, source, or consumer purpose changes. Retire rules that no longer support a current requirement, while retaining the history needed to interpret past results.
RightSight supports profiling, AI-assisted review, reusable rules, and quality workflows. DataTrust supports validation and reconciliation requirements. Confirm the specific review, execution, and evidence path in your configuration.
Read quality dimensions for formulas and automated validation for execution design.
Keep a distinction between a deterministic rule failure and an anomaly requiring assessment. A sudden rise in returns could reflect a legitimate campaign, a delayed batch, or a defect. Route the signal with its baseline and observation period. Do not treat an unusual distribution as an approved reason to alter source values or reject records automatically.
Use profiling suggestions to reduce manual work safely
Ask the reviewer to inspect representative valid and invalid records alongside an AI-suggested rule. Check whether a pattern reflects a business requirement, a temporary source condition, or an artifact of the sample. Record why a suggestion was accepted, modified, or rejected so future reviewers can understand its intended scope.
Reuse the reviewed specification through explicit asset bindings. When another team selects it, require confirmation of the grain, eligible population, field mapping, and exception treatment. Compare results after a version change before retiring the previous rule. This makes reuse a controlled reduction in repeated work rather than an unexamined copy of the original assumption.
Frequently asked questions
Should AI-suggested rules be activated automatically
A suggestion needs review against meaning, grain, and valid exceptions before it becomes an approved control. The required authority should be explicit.
Can one rule be reused across different datasets
Its general meaning may be reusable, but each binding needs the correct fields, population, threshold, and exception treatment.
When should a rule be retired
When its purpose is no longer valid or a reviewed replacement supersedes it. Preserve the version history required to interpret earlier results.
Request a Demo using one proposed rule, a known failure, and a valid exception.