What is a Data Quality Rule?

A single testable assertion about data, such as a column never being null, a value sitting in a range, or an identifier being unique.

What is the purpose of a Data Quality Rule?

A data quality rule catches bad data before it propagates into dashboards and decisions, protecting the integrity of downstream analytics. Each rule is small and binary, which makes data quality something a team can measure and enforce rather than hope for.

How do you use a Data Quality Rule in product management?

Define quality rules for: completeness (key fields not null), uniqueness (no duplicate IDs), referential integrity (foreign keys valid), freshness (data not stale), and distribution (values within expected ranges). Automate rules in CI. Alert when rules fail. Track data quality score as an operational metric.

Where does the concept of a Data Quality Rule come from?

Data quality as a discipline formalised with the growth of data warehousing in the 1990s. Thomas Redman's "Data Quality: The Field Guide" (2001) established dimensions of data quality: accuracy, completeness, consistency, timeliness, and uniqueness. Modern data quality tools (Great Expectations, dbt tests, Monte Carlo) operationalised these rules as code.

What are common mistakes with a Data Quality Rule?

Writing rules that only check format and never check meaning lets perfectly-typed nonsense pass, a valid date in the future, a negative revenue figure. Alerting on every minor breach trains teams to ignore the alerts entirely, so the real failures slip through with the noise. Rules defined without a clear owner and remediation path generate tickets nobody resolves. Applying the same strictness to a critical financial metric and a low-stakes log field wastes effort where it does not matter and skimps where it does.

🧹

Data Quality Rule

Q: What is an example of a Data Quality Rule?

DQ rule: graph_saves not null within 24h of user signup: Dimension: completeness. Rule: every user record should have at least one graph event within 24h of signup OR a null_graph_events flag. Failure rate acceptable: <2%. Current: 0.4%. Alert: Slack #data-quality. Owner: Data team. Catches: pipeline failures that drop post-signup events.

A single binary assertion, column never null, value in range, identifier unique, making quality testable.

Data & AnalyticsAnalytics & Datatype: 'data_quality_rule'interface: BaseNode

View in Graph

▼On this page

Description Properties Relationships Graph Position Related Entities

Description

A data quality rule is a single testable assertion about data: a column is never null, a value sits inside a range, an identifier is unique, a table was refreshed within the hour. Each rule is small and binary.

See moreSee less

How it works in practice

An analytics team runs a model that computes daily active users. They attach four rules to it: user_id is unique, event_date is not null, the count stays within 50 percent of the trailing seven-day average, and the source table was loaded in the last two hours. One morning the freshness rule fails, the count rule passes, and the model is held back before it can publish a stale number to leadership. Tools like dbt tests and Great Expectations make rules like these declarative and run them on every pipeline execution.

Data quality rule vs. its neighbours

Data contract is the broad agreement between producer and consumer. A quality rule is one enforceable clause that may sit inside a contract, but rules also live independently as pipeline tests.
Data lineage finds where a problem came from. A quality rule detects that a problem exists in the first place. A failing rule plus lineage is the standard root-cause pairing.
Metric is the business number being computed. A quality rule is the guard on the inputs and the output of that number, which is why the canonical edge runs from metric to rule.

The six widely cited dimensions, formalised by Wang and Strong in 1996, give a vocabulary for what rules check: accuracy, completeness, consistency, validity, timeliness, and uniqueness.

In the graph

In the Unified Product Graph, a data quality rule sits in the data and analytics region and connects most directly to the things it protects. A metric is validated by a rule (metric_validated_by_data_quality_rule), and rules associate with the data_source they test and the data_lineage that traces failures. That metric edge is the meaningful one: it turns an abstract assertion into a guarantee attached to a specific business number, so you can ask which metrics are guarded and which are flying blind.

Worked example: Trellis

A core data quality rule in Trellis requires that every agent-change event in the event schema carries who initiated it, what records it touched, why it was proposed, and an approval state before it is considered complete. Without that rule, the audit trail behind Guardrails and audit would have gaps, and one-click rollback could not guarantee it was undoing the right thing.

Preview

Presets

title

rule_type

test_type

column_refthreshold

alert_on_breach

last_run_status

last_run_date

Data Quality Rule

Workspace ID Not Null Check

Rule typecompletenessTest typenot_nullAlert on breachtrueLast run statuspass

Column refoperational.workspaces.workspace_id

Threshold0 nulls tolerated

Last run date2026-06-14

Properties

Type-specific fields on BaseNode

rule_typeenum

Quality dimension this rule validates

completenessaccuracyfreshnessuniquenessconsistency

test_typeenum

Specific test implementation

uniquenot_nullaccepted_valuesrelationshipscustom

column_refstring

Column or field this rule applies to

thresholdstring

Acceptable threshold value for the rule

alert_on_breachboolean

Whether to send an alert when the rule is breached

last_run_statusenum

Result of the most recent run

passfailerrornot_run

last_run_datestring

ISO date of the most recent run

Inherited from BaseNode (6 fields)

idstringrequired

Unique identifier (UUID)

typeNodeTyperequired

Discriminator for the entity type

titlestringrequired

Display name

descriptionstring

Optional detailed description

statusstring

Lifecycle status

tagsstring[]

Freeform tags for filtering

Relationships

2 edge types connected to this entity.

Parents

Entities that can contain this type

Metricmetric_validated_by_data_quality_rule

Cross-References

Contextual links across the graph

Data Sourcedata_quality_rule_governs_data_source

Graph Position

1parent

🧹Data Quality Rule

1cross-ref

Definition

A data quality rule is a testable assertion applied to data before it reaches analytics, such as a column never being null or a value staying within a valid range. It connects data sources to metric definitions, catching bad data before it propagates to dashboards and decisions.

Usage Guidance

Define quality rules for: completeness (key fields not null), uniqueness (no duplicate IDs), referential integrity (foreign keys valid), freshness (data not stale), and distribution (values within expected ranges).
Automate rules in CI.
Alert when rules fail.
Track data quality score as an operational metric.

Anti-Patterns

Writing rules that only check format and never check meaning lets perfectly-typed nonsense pass, a valid date in the future, a negative revenue figure.
Alerting on every minor breach trains teams to ignore the alerts entirely, so the real failures slip through with the noise.
Rules defined without a clear owner and remediation path generate tickets nobody resolves.
Applying the same strictness to a critical financial metric and a low-stakes log field wastes effort where it does not matter and skimps where it does.

Examples

DQ rule: graph_saves not null within 24h of user signup

Dimension: completeness. Rule: every user record should have at least one graph event within 24h of signup OR a null_graph_events flag. Failure rate acceptable: <2%. Current: 0.4%. Alert: Slack #data-quality. Owner: Data team. Catches: pipeline failures that drop post-signup events.

Data Quality Rule

A single binary assertion, column never null, value in range, identifier unique, making quality testable.

Data & AnalyticsAnalytics & Datatype: 'data_quality_rule'interface: BaseNode

View in Graph

▼On this page

Description Properties Relationships Graph Position Related Entities

Description

See moreSee less

How it works in practice

Data quality rule vs. its neighbours

Data contract is the broad agreement between producer and consumer. A quality rule is one enforceable clause that may sit inside a contract, but rules also live independently as pipeline tests.
Data lineage finds where a problem came from. A quality rule detects that a problem exists in the first place. A failing rule plus lineage is the standard root-cause pairing.
Metric is the business number being computed. A quality rule is the guard on the inputs and the output of that number, which is why the canonical edge runs from metric to rule.

The six widely cited dimensions, formalised by Wang and Strong in 1996, give a vocabulary for what rules check: accuracy, completeness, consistency, validity, timeliness, and uniqueness.

In the graph

Worked example: Trellis

Preview

Presets

title

rule_type

test_type

column_refthreshold

alert_on_breach

last_run_status

last_run_date

Data Quality Rule

Workspace ID Not Null Check

Rule typecompletenessTest typenot_nullAlert on breachtrueLast run statuspass

Column refoperational.workspaces.workspace_id

Threshold0 nulls tolerated

Last run date2026-06-14

Properties

Type-specific fields on BaseNode

rule_typeenum

Quality dimension this rule validates

completenessaccuracyfreshnessuniquenessconsistency

test_typeenum

Specific test implementation

uniquenot_nullaccepted_valuesrelationshipscustom

column_refstring

Column or field this rule applies to

thresholdstring

Acceptable threshold value for the rule

alert_on_breachboolean

Whether to send an alert when the rule is breached

last_run_statusenum

Result of the most recent run

passfailerrornot_run

last_run_datestring

ISO date of the most recent run

Inherited from BaseNode (6 fields)

idstringrequired

Unique identifier (UUID)

typeNodeTyperequired

Discriminator for the entity type

titlestringrequired

Display name

descriptionstring

Optional detailed description

statusstring

Lifecycle status

tagsstring[]

Freeform tags for filtering

Relationships

2 edge types connected to this entity.

Parents

Entities that can contain this type

Metricmetric_validated_by_data_quality_rule

Cross-References

Contextual links across the graph

Data Sourcedata_quality_rule_governs_data_source

Graph Position

1parent

🧹Data Quality Rule

1cross-ref

Definition

Usage Guidance

Define quality rules for: completeness (key fields not null), uniqueness (no duplicate IDs), referential integrity (foreign keys valid), freshness (data not stale), and distribution (values within expected ranges).
Automate rules in CI.
Alert when rules fail.
Track data quality score as an operational metric.

Anti-Patterns

Writing rules that only check format and never check meaning lets perfectly-typed nonsense pass, a valid date in the future, a negative revenue figure.
Alerting on every minor breach trains teams to ignore the alerts entirely, so the real failures slip through with the noise.
Rules defined without a clear owner and remediation path generate tickets nobody resolves.
Applying the same strictness to a critical financial metric and a low-stakes log field wastes effort where it does not matter and skimps where it does.

Examples

DQ rule: graph_saves not null within 24h of user signup