A data quality rule is a defined condition that a data value or set of values must satisfy to be considered valid — specifying what makes data acceptable for a particular field or dataset, and what action to take when data fails to meet that condition.
Data quality rules are the mechanism that converts abstract quality standards into specific, executable checks. "Email addresses should be valid" is a standard. "Email addresses must contain exactly one @ symbol and at least one period after the @, and must not be null" is a data quality rule.
The Four Components of a Data Quality Rule
Every well-defined data quality rule has four elements:
Sohovi applies your data quality rules automatically across the whole dataset and highlights every violation — so nothing slips through.
Target field: Which column or attribute the rule applies to.
Validity condition: The specific, testable condition that makes a value valid — expressed precisely enough that a computer (or person) can evaluate it without ambiguity.
Failure condition: What makes a value fail — the inverse of the validity condition.
Response: What happens when a record fails. Options: reject the record, flag for review, route to exception queue, notify the owner, or auto-correct where appropriate.
Types of Data Quality Rules
Format rules: The value must match a specific structural pattern. An email must contain "@". A ZIP code must be 5 digits. A date must be in YYYY-MM-DD format.
Range rules: A numeric or date value must fall within defined bounds. Price must be greater than 0. Discount must be between 0 and 100. Hire date must be in the past.
Completeness rules: A field must have a non-null, non-empty value. Email is required for all marketing contacts. Customer ID is required for all orders.
Sohovi profiles every column in your dataset for completeness and flags the exact rows where values are missing — free to try.
Enum rules: A categorical value must belong to an approved set. Status must be one of: Active, Inactive, Churned. Country must be a valid ISO 3166 code.
Cross-field rules: One field's validity depends on another field's value. If status is "Cancelled," cancellation_date must not be null. If payment_type is "Credit Card," card_last_four must be exactly 4 digits.
Uniqueness rules: A value or combination of values must appear exactly once. Customer ID must be unique. Email must appear no more than once per active contact.
Frequently Asked Questions
Q: What is a data quality rule? A data quality rule is a defined condition that data must satisfy to be considered valid. It specifies exactly what makes a value acceptable, what makes it fail, and what should happen when it fails. Rules convert abstract quality standards into executable checks.
Q: What is the difference between a data quality rule and a business rule? A business rule encodes a business decision or policy. A data quality rule enforces that business rule on actual data. "Customer status must be Active or Inactive" is a business rule. The validation rule that checks whether the status field contains only "Active" or "Inactive" is the data quality rule implementing it.
Q: How specific should a data quality rule be? Specific enough that anyone (or any system) can evaluate it unambiguously. "Phone numbers should look right" is not a rule — it's a hope. "Phone numbers must contain between 7 and 15 digits and may include only digits, spaces, dashes, parentheses, and a leading plus sign" is a rule.
Q: What should a data quality rule do when it finds a failing record? That depends on the context and severity. At data entry, blocking the save is appropriate. For batch imports, flagging and routing to a review queue is more practical. For existing data, marking the record as failing and reporting the count is often the first step. Define the response when you define the rule.
Q: How many data quality rules does a dataset need? Start with one rule per critical field. Five to twenty rules covering your most important fields — email format, required completeness, categorical values, numeric ranges — gives most organizations 80% of the value. Expand as you discover additional quality patterns.
Q: Can data quality rules be automated? Yes. Rules can be automated at data entry (form validation), at import (pre-import validation checks), in data pipelines (dbt tests, Great Expectations assertions), and in data quality tools that run rules on a schedule.
Q: What is a data quality threshold and how does it relate to a rule? A data quality threshold defines the acceptable failure rate for a rule — the percentage of records that can fail before action is required. The rule defines what failure means; the threshold defines how much failure is acceptable before it becomes a problem.
Q: How should data quality rules be documented? Each rule should be documented with: rule name, target field and dataset, validity condition in plain English, failure condition, response, acceptable failure rate, business justification, and date last reviewed. This documentation is what makes rules maintainable.
Q: What is the difference between a validation rule and a monitoring alert? A validation rule checks whether individual records satisfy a condition. A monitoring alert fires when the aggregate failure rate for a rule crosses a threshold — it's the operational signal that quality has degraded beyond acceptable bounds.
Q: Who should write data quality rules? The business owner of the data domain defines what "valid" means (the business intent). A data analyst or data engineer translates that into a technically executable rule. Both perspectives are needed — the business defines the standard, the technical team implements it.
Data quality rules are how you operationalize "good data." Without them, quality is aspirational. With them, it's measurable and enforceable.
If you want to start applying data quality rules to your most important dataset, Sohovi's rule builder lets you define and run checks on any CSV in minutes — no code required.
