How to Build a Data Validation Pipeline

A modern outbound data pipeline rarely suffers because it cannot find enough data. It suffers because it cannot reliably determine which data should be trusted. A provider returns an email address, an enrichment system adds a job title, a company database returns employee count, a signal provider reports a hiring event. The real question begins after each of these steps: can this information be trusted enough for what comes next?

That is the role of data validation. Validation is not simply checking whether an email has the right format, not the same as cleaning a database, and not a one-time quality gate at the end of a pipeline. A reliable validation system determines whether data conforms to defined requirements, whether conflicting evidence needs review, whether information is current enough for its intended use, and whether a record is safe to move into the next operational state. Validation is the layer that separates collected data from trusted, usable data.

1. Enrichment Adds Data. Validation Decides Whether to Trust It

The previous article examined waterfall enrichment: how multiple sources can be used sequentially to improve data coverage. But enrichment creates a new problem. More data means more things that can be wrong. A provider may return the wrong person, an outdated title, an incorrect company association, conflicting values, stale contact information, a low-confidence match, or a value that is technically valid but contextually wrong.

Enrichment therefore cannot be the final step. A simplified pipeline runs:

COLLECT → ENRICH → VALIDATE → QUALIFY → ACTIVATE

Enrichment asks whether more information can be found. Validation asks whether that information meets the requirements for what comes next. Those are different questions. A waterfall can improve coverage while still producing data that should not be activated. Coverage is an output. Data quality is a system property.

2. What Data Validation Actually Means

Data validation is the process of testing data against predefined requirements. Those requirements can be technical, semantic, relational, temporal, or business-specific. A validation check might ask whether a field is present, whether the value is in the expected format, whether it falls within an acceptable range, whether it makes sense relative to other fields, whether it refers to the correct entity, whether it comes from a trusted source, whether it is recent enough, or whether it satisfies the rules required for the intended workflow.

Modern data-quality systems commonly distinguish completeness, validity, freshness, consistency, accuracy, and uniqueness as separate dimensions rather than treating quality as one binary property. Google Cloud provides separate checks for nulls, ranges, sets, regex patterns, uniqueness, freshness, and other dimensions. Salesforce similarly describes validation rules as mechanisms that enforce predefined requirements before data can move forward in a workflow.

Data validation determines whether a data object conforms to the requirements defined for its intended use.

3. Validation, Verification, and Accuracy Are Different Things

Three related concepts are often conflated, and keeping them distinct improves pipeline design.

Validation asks whether data conforms to defined rules. An email field containing john@company.com passes syntax validation. The value looks correct by the rules the system is checking.

Verification asks whether the information corresponds to trusted evidence or external reality. Does the mailbox actually exist? Does the person currently work there? Does the domain belong to the company? Was the value observed recently? Verification goes beyond format and into fact.

Accuracy asks whether the value is actually correct — not just whether it conforms to rules or matches external evidence, but whether it reflects the true state of the world.

Google Cloud explicitly separates validity from accuracy: a value can conform to an expected format or range while still being factually incorrect. An email can have valid syntax and belong to the wrong person. A company can have a valid employee-count value that is simply outdated. A job title can match an allowed title format while describing a former role. A good pipeline uses all three tests together rather than treating any one as sufficient.

4. Validation Is Not the Same as Data Quality

Data quality is the broader outcome that validation helps produce and maintain. Validation is one mechanism used to achieve it — not the whole system.

A complete data-quality operation involves several distinct functions. Validation tests whether data meets defined requirements. Governance establishes the rules, ownership, and accountability around that process. Monitoring observes quality trends over time. Remediation addresses failures when they occur. Feedback loops connect outcomes back to upstream rule design.

A system can have hundreds of validation rules and still have poor data quality if the wrong rules are being tested, thresholds are inappropriate, sources are unreliable, failures are ignored, stale records are never revalidated, validation happens too late in the pipeline, or business requirements have changed since the rules were written. Validation is one operational layer within a larger quality system — not a substitute for it.

5. Start With the Intended Use Case

The first mistake in validation design is starting with the fields. The better question is what decision or action the data will support.

Suppose a record contains company name, website, employee count, industry, job title, email, country, and funding information. The required validation depends entirely on the intended use. For account research, employee count may matter most. For persona targeting, job function and seniority may be more important. For email activation, current employment status and email validity become critical. For campaign eligibility, suppression state and geographic coverage may be mandatory conditions.

Validation should be fit for purpose. A universal rule requiring every field to be 100% complete is usually less useful than defining which fields are critical for a particular workflow and setting thresholds accordingly. The right validation threshold is the one required by the decision — not an abstract standard of perfect data.

6. Layer 1: Structural Validation

The first layer asks whether the data has the expected structure. This includes checking for required fields, correct data types, schema conformity, column existence, nullability rules, and expected record structure.

employee_count  → numeric

founded_year    → integer

country         → string

first_seen      → timestamp

If employee_count contains "about five hundred," the problem is structural before it is even semantic. Structural validation establishes the basic conditions required for the rest of the pipeline to function reliably. A transformation that assumes a numeric field and receives a string, a date comparison that receives an unformatted value, or a range check that receives null — all of these failures become harder to diagnose if structural issues are not caught first.

7. Layer 2: Format and Syntax Validation

The next layer checks whether values conform to expected formats: email syntax, phone number structure, URL format, country codes, date formats, standardized job functions, and domain formats.

Email          → valid syntax pattern

Country        → recognized country code

Employee Count → numeric

Funding Date   → valid date format

Google Cloud supports rule types including regex checks, range checks, non-null checks, and allowed-value sets as explicit validity and completeness rules.

Format validation has an important limitation: it proves conformity, not truth. An email can be syntactically correct and still be useless. A URL can be correctly formatted and point to the wrong company. A title can fit a normalized taxonomy and still describe a former role. Syntax is the beginning of validation, not the end.

8. Layer 3: Value and Range Validation

The next question is whether a value falls within an acceptable range or permitted set:

employee_count > 0

funding_amount >= 0

percentage >= 0 AND percentage <= 100

country ∈ supported_markets

seniority ∈ {C-Level, VP, Director, Manager}

This prevents obviously invalid values from entering downstream workflows. But ranges should also be context-aware. A company with 5 employees and a company with 50,000 employees may both be valid. A funding amount of zero may be valid in one context and invalid in another. A job title outside a normalized taxonomy does not necessarily mean the person is irrelevant.

A validation rule should distinguish "invalid" from "unrecognized." An unrecognized value may warrant review rather than rejection — which is why the UNKNOWN state becomes useful in the validation outcome model described in Section 13.

9. Layer 4: Semantic and Cross-Field Validation

Some of the most valuable validation happens when individual fields are checked in relation to each other. A field can be valid in isolation while the combination is inconsistent.

Consider: Company Status = Acquired with Funding Status = Active Series A — that combination may require investigation. Or: Contact Status = Current Employee with Employment End Date = six months ago — a direct contradiction. Or: Country = Germany with Phone Country Code = +1 — not necessarily wrong, but a candidate for contextual review.

Cross-field validation asks whether values make sense together, which moves validation beyond syntax and into semantics:

FIELD VALIDATION

↓

RELATIONSHIP VALIDATION

↓

CONTEXT VALIDATION

As data models become more complex, the relationships between fields often carry as much information as the field values themselves.

10. Layer 5: Identity and Entity Validation

Before trusting an enriched value, the system needs to know what entity the value belongs to. Consider a record for John Smith, VP Sales at Acme. The pipeline still needs to determine which John Smith, which Acme, whether this is the same person already in the system, whether this is his current employer, whether the role is current, and whether the enrichment belongs to the correct account.

IDENTITY CHECK

↓

ENTITY RESOLUTION

↓

FIELD VALIDATION

↓

VERIFICATION

Validating a field attached to the wrong entity produces a particularly dangerous result: correct-looking data attached to the wrong record. For outbound systems, this can be worse than missing data. Missing data creates uncertainty. Incorrectly attached data creates false confidence — the system believes it knows something it does not.

11. Layer 6: Source, Provenance, and Freshness

A validated value should not exist without context. At minimum, the system should preserve:

FIELD PROVENANCE

├── Value

├── Source

├── Source Type

├── Observed At

├── Verified At

├── Method

└── Confidence

For example: Email = john@company.com, Source = Provider A, Observed = 2026-09-01, Verified = 2026-09-02, Method = Enrichment + Verification, Confidence = High. Now if another source reports john.smith@company.com, the system has enough context to detect a conflict rather than silently overwriting one value with another.

Freshness is a distinct dimension from validity. A value can be valid but stale — a job title last verified fourteen months ago may have been correct when observed without being safe to use today. Google Cloud treats freshness as a separate data-quality dimension from validity and accuracy. Validity asks whether the data conforms to the rules. Freshness asks whether the data is current enough for the use case. Both questions need answers before a record can be trusted.

12. Layer 7: Business-Rule Validation

Technical validation asks whether the data is structurally and logically acceptable. Business validation asks whether it is acceptable for the specific workflow.

For email activation, the conditions might require that the email is valid, the person is currently employed, the account fits the ICP, the geography is supported, the account is not suppressed, and the contact is relevant to the campaign. Only when all conditions are met might the record become activation-ready.

Salesforce uses validation rules to enforce business-specific requirements and prevent records that violate predefined rules from advancing. A record can pass every technical validation layer and still fail business validation. The question is not simply whether the data is valid — it is whether the data is valid enough for this specific action.

13. PASS, FAIL, UNKNOWN, and REVIEW

A simple VALID / INVALID binary model is often too coarse for outbound data operations. A stronger validation system produces four operational states.

PASS means there is sufficient evidence that the data meets the defined requirements. FAIL means the data clearly violates a rule or has evidence indicating it should not proceed. UNKNOWN means there is insufficient evidence to determine whether the data is valid — this is different from failure. REVIEW means there is a conflict, ambiguity, or exception requiring additional resolution before the record can move forward.

For example: Email Syntax → PASS. Employment Status → UNKNOWN. Account Match → REVIEW. Suppression Status → PASS. This is more useful than a single quality score because it preserves the reason behind each decision.

UNKNOWN should not automatically become PASS. Lack of evidence is not proof of correctness. At the same time, UNKNOWN is not always a terminal state — it may mean re-enrich, then verify, then review, then retry.

14. Why Quarantine Is Part of the Pipeline

A failed record should not simply disappear. It should have somewhere to go. That is the purpose of a quarantine or exception state.

DATA INPUT

↓

VALIDATION

↓

┌──────────┬──────────┬──────────┐

PASS     REVIEW      FAIL

↓          ↓           ↓

NEXT    RESOLVE    QUARANTINE

STEP       ↓           ↓

       REPROCESS ←─────┘

The quarantine record should preserve the record ID, failed rule, source, timestamp, previous value, current value, validation version, error reason, and remediation status. AWS recommends staged validation and quarantine so that data failing schema, metadata, or plausibility checks is isolated before entering production workflows. Bad data should be isolated — not silently discarded or allowed to contaminate downstream systems.

15. Validation Gates Should Exist Throughout the Pipeline

Validation should not happen once at the end. Different stages create different risks, and the earlier a bad record is detected, the cheaper it is to correct.

SOURCE

↓

INGESTION VALIDATION

↓

NORMALIZATION

↓

TRANSFORMATION VALIDATION

↓

ENTITY RESOLUTION

↓

ENTITY / FIELD VALIDATION

↓

ENRICHMENT

↓

ENRICHMENT VALIDATION

↓

QUALIFICATION

↓

BUSINESS-RULE VALIDATION

↓

CAMPAIGN ASSEMBLY

↓

JIT ACTIVATION VALIDATION

↓

SENDABLE DATA

A record that fails immediately after ingestion is easy to isolate. A record that passes through five transformations, enrichment providers, scoring systems, and campaign workflows before being rejected is much harder to diagnose. Validation should happen where bad data can still be stopped, isolated, or corrected — not only at the point where it is too late to change anything without cost.

16. Not Every Rule Needs a 100% Threshold

A common mistake in validation design is assuming every rule should require perfection. Different fields carry different operational importance, and thresholds should reflect that:

Email Validity       → Critical

Country              → Critical

ICP Fit Evidence     → Critical

Employment Status    → Critical

Phone Number         → Optional

Revenue              → Optional

Technology Stack     → Useful, non-critical

A campaign might require email validity at 99% or above, a supported country, verified current employment, and a clear suppression status — while tolerating missing phone numbers entirely. A research dataset may have entirely different threshold requirements for the same fields.

Google Cloud's data-quality framework explicitly supports passing thresholds for rules rather than assuming every rule must be absolute. Validation thresholds should reflect business impact and workflow requirements, not an abstract standard of completeness.

17. Validation Rules Need Ownership and Versioning

Data rules are not permanent. Business requirements change. ICP definitions change. Markets, products, and data sources change. Validation rules need governance.

A useful rule definition captures:

RULE DEFINITION

├── Rule ID

├── Rule Name

├── Purpose

├── Scope

├── Condition

├── Severity

├── Threshold

├── Disposition

├── Owner

├── Version

├── Effective Date

└── Last Reviewed

For example: CONTACT-EMPLOYMENT-001 requires evidence of current employment, carries Critical severity, routes UNKNOWN results to Review, is owned by Data Operations, is at version 1.2, and was last reviewed 2026-09-01.

Poorly designed validation creates a distinct problem from the one it is meant to solve: valid data being incorrectly blocked. Salesforce specifically recommends testing validation rules before activation and warns that poorly designed rules can prevent valid records from being saved. A validation system must protect against both bad data and bad validation logic.

18. How to Measure a Validation Pipeline

A validation pipeline should not be measured only by what percentage of records passed. A complete measurement model tracks dimensions across four areas.

Rule-level metrics track pass rate, fail rate, unknown rate, review rate, and conflict rate for each individual rule. These reveal which rules are producing the most exceptions and which sources are generating the most failures.

Data-quality metrics track completeness, validity, accuracy, uniqueness, freshness, and consistency across the dataset. These measure the condition of the data itself rather than the performance of individual rules.

Operational metrics track quarantine volume, quarantine aging, resolution time, reprocessing rate, recurring failure rate, and cost per resolved record. These measure whether the pipeline is operationally efficient and whether exception handling is functioning correctly.

Activation metrics track activation-ready rate, bounce rate, wrong-person rate, suppression violations, and downstream correction rate. These connect validation performance to outbound outcomes — the most important measurement link in the system.

The most useful question is not how much data passed. It is how much trustworthy data became usable for the intended workflow.

19. From Validation to Activation Eligibility

A record can be structurally valid, syntactically valid, recently verified, and correctly resolved — and still not be eligible for outreach.

CONTACT

↓

VALID

↓

VERIFIED

↓

CURRENT

↓

ICP-FIT ACCOUNT

↓

RELEVANT ROLE

↓

NOT SUPPRESSED

↓

CAMPAIGN RULES PASS

↓

ELIGIBLE

Validation asks whether the data meets its requirements. Eligibility asks whether the record can be used for a specific action. Those are not the same state. The final transition should be VALIDATED → ELIGIBLE, not VALIDATED → SEND. There may still be additional business, campaign, compliance, or operational conditions between those two states — and the pipeline should represent them explicitly rather than collapsing them.

20. The Validation Feedback Loop

A mature validation system learns from its failures:

DATA

↓

VALIDATION

↓

PASS / FAIL / UNKNOWN / REVIEW

↓

RESOLUTION

↓

ACTIVATION

↓

OUTCOME

↓

FAILURE ANALYSIS

↓

RULE / SOURCE / PIPELINE IMPROVEMENT

↓

VALIDATION

Suppose a campaign produces an unexpected number of wrong-person replies. The validation system may discover that employment data was stale, role normalization was incorrect, contacts were associated with the wrong account, an enrichment source had poor coverage for that market, or a campaign rule allowed records with unresolved identity. The outcome becomes evidence for improving the data pipeline — not just the messaging. This is how validation moves from a static quality gate to an operational learning system.

21. The Complete Data Validation Architecture

Putting all layers together:

DATA INPUT

↓

IDENTITY CHECK

↓

STRUCTURAL VALIDATION

↓

FORMAT / SYNTAX VALIDATION

↓

VALUE / RANGE VALIDATION

↓

SEMANTIC VALIDATION

↓

CROSS-FIELD VALIDATION

↓

SOURCE / PROVENANCE CHECK

↓

FRESHNESS CHECK

↓

EXTERNAL VERIFICATION

↓

BUSINESS-RULE VALIDATION

↓

┌──────────┬──────────┬──────────┐

PASS     REVIEW     FAIL     UNKNOWN

↓          ↓          ↓          ↓

NEXT    RESOLVE  QUARANTINE REVALIDATE

STEP       │          │          │

           └──────────┴──────────┘

                      ↓

                  REPROCESS

                      ↓

               BACK TO VALIDATION

                      ↓

                  CONFIDENCE

                      ↓

                  ELIGIBILITY

                      ↓

                  ACTIVATION

                      ↓

                   OUTCOME

                      ↓

                  FEEDBACK

Validation is not one rule. It is a sequence of decisions — each layer testing a different dimension of trustworthiness before the record moves forward.

22. Validation Should Produce Evidence, Not Just a Label

A record should not simply contain Validated = TRUE. That label says very little about why the record was trusted or when that trust was established.

A better representation:

VALIDATION RECORD

├── Field

├── Value

├── Validation Status

├── Rule

├── Source

├── Observed At

├── Verified At

├── Confidence

├── Failure Reason

├── Last Validation

└── Validation Version

For example: Job Title = VP Sales, Status = PASS, Source = Company website, Observed = 2026-08-28, Verified = 2026-09-01, Confidence = High, Rule = CURRENT-ROLE-001. This creates validation evidence — a structured record of why the system trusted a value and when that trust was established. A mature data infrastructure should be able to answer, for any activated record, exactly why the system believed it was trustworthy enough to act on.

23. Validation as Outbound Infrastructure

The outbound data pipeline is not SOURCE → LIST. It runs:

SOURCE

↓

DATA

↓

VALIDATION

↓

QUALIFICATION

↓

ELIGIBILITY

↓

ACTIVATION

↓

OUTCOME

A reliable outbound system needs to know where the data came from, what was changed, what was validated, when it was validated, which rules were applied, what failed, what requires review, what is currently eligible, and what happened after activation — not as separate questions, but as connected states in a continuous system.

The goal is not to eliminate every imperfect record. The goal is to prevent uncertainty from silently becoming action. A record with unknown employment status should not reach an activation workflow the same way a verified current contact does. A record with a conflicting account match should not be treated as resolved simply because no one flagged it. Validation creates the explicit states — PASS, FAIL, UNKNOWN, REVIEW — that allow the system to handle each record appropriately rather than treating all of them as equally trustworthy.

Conclusion

A modern outbound system does not need more data for the sake of having more data. It needs trusted data that can safely move through a workflow.

Enrichment improves coverage. Validation tests conformity. Verification strengthens confidence. Entity resolution establishes identity. Freshness determines whether information is still current. Business rules determine whether the data meets operational requirements. Eligibility determines whether the record can be used for a specific action. Feedback determines whether the system should improve.

COLLECT

↓

ENRICH

↓

VALIDATE

↓

VERIFY

↓

RESOLVE

↓

QUALIFY

↓

ELIGIBILITY

↓

ACTIVATE

↓

LEARN

Validation is not about proving that every record is perfect. It is about determining what the system can safely do with each record. A good validation pipeline does not merely produce valid and invalid labels. It produces evidence, confidence, state, and controlled next steps. Enrichment adds information. Validation determines whether to trust it. That is what turns data quality from a cleanup exercise into infrastructure.

The next question is how enrichment and validation connect to campaign eligibility — specifically, what quality and completeness thresholds a record must meet before it can enter an outbound motion, and how those thresholds should be defined relative to the campaign being run.

Sources

Google Cloud — Auto Data Quality Overview. Available at: https://docs.cloud.google.com/knowledge-catalog/docs/auto-data-quality-overview

Google Cloud — Use Auto Data Quality. Available at: https://docs.cloud.google.com/knowledge-catalog/docs/use-auto-data-quality

Google Cloud — Auto Data Quality Rules. Available at: https://docs.cloud.google.com/dataplex/docs/use-auto-data-quality

Salesforce Trailhead — Get Started With Validation Rules. Available at: https://trailhead.salesforce.com/content/learn/modules/validation-rules/get-started-with-validation-rules

Salesforce Help — Validation Rules. Available at: https://help.salesforce.com/s/articleView?id=sf.fields_about_field_validation.htm&language=en_US&type=5

Salesforce Trailhead — Implement Validation Rule Best Practices. Available at: https://trailhead.salesforce.com/content/learn/modules/validation-rules/implement-best-practices

AWS Well-Architected — Use Staged Validation and Data Quarantine Mechanisms. Available at: https://docs.aws.amazon.com/wellarchitected/latest/life-sciences-lens/lsrel07-bp03.html

Gartner — Data Quality. Available at: https://www.gartner.com/en/data-analytics/topics/data-quality

Gartner — Building Blocks for Effective Data Governance in the Age of AI (July 2026). Available at: https://www.gartner.com/en/documents/8120429