The CRM was full.
No obvious blanks. No catastrophic import failure. Every lead had a country value, which sounded reassuring until someone tried to segment performance by region and discovered entries like Israel, IL, ישראל, N/A, EMEA, Europe, and one memorable row that simply said home.
Nothing was technically missing. The analysis was still a crime scene.
That is validity.
Validity asks whether data follows the rules it is supposed to follow. Not whether a value exists. Not whether it looks plausible at a glance. Whether it conforms to the format, type, range, and business rules that allow you to trust what it means.
This matters more now, not less, because AI can help fix malformed data quickly. If the mechanics of cleaning are getting cheaper, then the expensive part becomes recognizing which rules actually matter before the model starts "helping" you standardize nonsense into something tidy.
Valid does not mean true
This is where people get sloppy.
A valid email address can belong to the wrong person. A valid date can be attached to the wrong event. A valid country code can still represent the wrong market because it was inferred badly upstream.
Validity is narrower than truth. It asks: does this value obey the rule set we claim to operate under?
That sounds limited, but it is essential. Without validity, analysis degrades before truth even becomes discussable. You cannot reason clearly about a field whose accepted inputs were never controlled.
Format rules versus business rules
Some validity checks are mechanical.
- Is the field a date?
- Is the value numeric?
- Does the code match the expected pattern?
- Is the value inside an allowed range?
Those are useful, but they are the easy part.
The harder part is business validity:
- Is
European acceptable value in a country field? - Can a discount exceed the order subtotal?
- Should a free-trial user have a recognized revenue value?
- Is
999a valid age, even if the column type accepts it?
This is why "it passed validation" is often such a weak comfort. Many pipelines validate syntax while ignoring semantics. They confirm the data can be stored, not that it should be trusted.
Why age = 999 is not a quirky edge case
Bad values are rarely random. They are signals.
999 usually means somebody needed a placeholder. N/A in a controlled field means the intake process tolerated ambiguity. unknown often means the source system could not classify something but the downstream schema demanded an answer anyway.
Treating these as harmless edge cases is lazy. They distort grouping, inflate category counts, and create false stability because the garbage arrives in a repeatable format.
One sharp opinion here: if your pipeline accepts placeholders without a defined policy, it is not being flexible. It is outsourcing confusion to the analyst who inherits the table later.
Controlled vocabularies are boring until they save your analysis
Nobody wants to hold a meeting about allowed country codes. That is precisely why the problem gets neglected until segmentation breaks.
Controlled vocabularies feel bureaucratic when things are calm. Then a company tries to compare channel performance across markets, merge CRM data with product events, or build a regional forecast, and suddenly the boring list of acceptable values becomes the only thing standing between order and narrative collapse.
The same is true for status codes, plan names, currencies, device types, campaign taxonomies, and refund reasons. Analysts often inherit these as if they were facts of nature. They are not. They are design choices with consequences.
The difference between accepting data and trusting data
Many systems are designed to accept imperfect input because business operations need to continue. That is reasonable.
But there is a huge difference between allowing data into a system and endorsing it for analysis.
Operations may need to capture a lead now and fix details later. Analytics cannot quietly pretend that the field is therefore ready for segmentation. Acceptance is a workflow decision. Trust is an analytical decision.
Confusing the two is how teams end up presenting precise charts built on values nobody defined tightly enough to compare.
How analysts usually miss validity failures
They look for emptiness and outliers, but not rule violations.
They notice nulls. They may even notice absurd extremes. What they often skip is building explicit expectations for each field:
- What values are allowed?
- In what format?
- Under what conditions?
- Who owns the rule?
- What happens when the rule fails?
Without that, data quality becomes aesthetic. Analysts inspect whether the field "looks okay" rather than whether it obeys a standard strong enough to support the decision.
That is not governance. That is vibe-based analytics.
A practical validation matrix
If a field matters to decisions, document its validation logic in one place.
| Field | Rule | Invalid examples | Owner | Response |
|---|---|---|---|---|
country | Must be ISO-2 country code | Europe, N/A, ישראל | CRM Ops | Reject on ingest or map through approved table |
discount_pct | Must be between 0 and 100 | 150, -10 | Commerce Eng | Quarantine row and alert |
signup_date | Must not be in the future | 2030-01-01 | Data Eng | Block downstream load |
plan_name | Must match approved catalog | enterprise-ish | Product Ops | Remap or escalate to owner |
The point is not paperwork. The point is making trust explicit.
Once every value looks acceptable, a different failure appears: you may still be counting the same thing multiple times. That is the problem of uniqueness.
