Automation data quality checks: validate the contract before action

A field can look valid while being unsuitable for the next action. Data quality checks should enforce the contract for the specific workflow: required identity, allowed values, current source version, and relationships that make the record meaningful.

Write rules around the action

A report may tolerate a missing optional phone number. A record update cannot safely proceed without knowing which record to update. Define critical fields for the next action rather than applying the same completeness requirement to every column.

Google’s automatic data quality documentation distinguishes row-level rules from aggregate rules and supports checks including nulls, ranges, allowed sets, uniqueness, and custom SQL. That provides one concrete implementation option for table data. The business still defines which failures block a particular action. Google’s data quality rule overview.

Use a contract with field and relationship checks

This is a fictional contract, not a universal order schema. Your process owner defines allowed values, meaningful ranges, units, and version semantics. A timestamp alone may not establish version order if systems use different clocks or update rules.

Do not average away critical failures

Suppose a fictional batch has 100 updates. Ninety-eight have valid identities; two map to no target. A 98 percent pass rate looks encouraging, but those two updates still cannot execute. Validate records individually and quarantine the two failures. If the remaining updates depend on them, stop the dependent group as well.

Check the contract before the action.

Proposed batch

100 updates

Valid identities

98 updates

Unresolved identities

2 updates map to no target

Action

Quarantine failed rows; stop dependent groups if needed

View data

Evidence	Meaning
Proposed batch	100 updates
Valid identities	98 updates
Unresolved identities	2 updates map to no target
Action	Quarantine failed rows; stop dependent groups if needed

Fictional worked example from the article. Apply your organization’s controls.

Download image

Separately check the batch contract: expected source window, record count, duplicate identities, and whether all pages were fetched. A valid row sample cannot prove that the integration received the full dataset. Reconcile eligible source records against completed and unresolved records.

Normalize without hiding the source

Preserve original and normalized values with the transformation rule. A blank amount is not zero. A parseable date is not necessarily an unambiguous date. A repeated source ID is not automatically a harmless duplicate; it may carry a newer version or a conflicting value.

For permitted corrections such as whitespace trimming, log the transformation. For semantic changes such as choosing a currency or converting cartons to items, require an authoritative mapping or a human decision. Filling required fields with defaults can make validation pass while weakening the record.

Make the rule register reusable

Copy these columns into a team worksheet: rule ID, record type, field or relationship, expected condition, severity, affected action, owner, exception path, and policy version. Add one passing example and one failing example for every rule. State whether the rule blocks one record, a related group, or the whole batch.

Measure failures by rule and source, not only an overall score. If one supplier export repeatedly loses currency, repair the mapping or source requirement rather than repeatedly approving a default. Use the readiness tool to identify missing authoritative sources. Validate the contract with actual records before allowing it to govern system updates.