Static data quality rules check whether your data meets fixed criteria. But they're blind to anything that changes gradually, anything that looks correct in isolation, and anything you didn't anticipate when you wrote the rule.
If your data quality program relies entirely on static rules, you're seeing only part of the picture. Here are five real-world data quality problems that routinely slip through even well-maintained rule sets — and how behavioral scoring catches each one.
1. The Gradual Null Rate Creep
The problem: Your customer table normally has 0.2% null phone numbers. Over three months, the null rate climbs: 0.4%, 0.8%, 1.6%, 3.2%, 6.4%. At each step, the change is small enough that no static rule fires. After three months, 6.4% of your customers have no phone number — a significant data quality issue.
Why static rules miss it: Your not_null rule has a threshold of, say, 90%. A 6.4% null rate passes easily. Even a threshold of 95% passes at 6.4%.
Sohovi tracks quality trends across runs and alerts you when a metric — null rate, duplicate count, score — moves outside its normal range.
How behavioral scoring catches it: Each individual run's null rate is checked against the historical baseline. A jump from 3.2% to 6.4% (doubling in one run) would show a z-score of 4+ — flagged as a medium-severity anomaly. The creep is caught step by step rather than only when it crosses an arbitrary threshold.
2. The Silent Pipeline Truncation
The problem: Your weekly sales export normally contains 48,000–52,000 rows. This week, a pipeline bug introduces a filter that wasn't there before. The export contains 11,000 rows. Every single row is correct — nulls are fine, formats are fine, values are valid. But 77% of the data is missing.
Why static rules miss it: Row count validation is rarely included in static DQ rule sets because it doesn't map neatly to a column-level rule. Even if you have a minimum row count rule, it's set based on the minimum you anticipated — not the statistical expected value.
Sohovi lets you set up validation rules for any column and instantly see which rows fall outside them — no code or SQL required.
How behavioral scoring catches it: The behavioral scorer monitors row count as a tracked metric. A drop from ~50,000 rows to 11,000 is a 20-sigma event. This is flagged as a critical behavioral anomaly immediately on the first run with the truncated data.
3. The Upstream Status Code Change
The problem: Your CRM export includes an "opportunity_stage" column that has historically contained: "Prospecting", "Qualification", "Proposal", "Closed Won", "Closed Lost". Your CRM vendor releases an update that renames the stages: "Discover", "Develop", "Present", "Won", "Lost". Every value is now different.
Why static rules miss it: Your enum validation rule checks that values are in the allowed set — but the new values are different from the allowed set, so the rule fails. You know something is wrong, but not what.
Actually, let's make this harder: maybe you have no enum validation rule because you didn't know what values to expect. In that case, nothing fires.
How behavioral scoring catches it: The distribution shift detector compares the current run's top values against the previous run's top values. Five new values appear; five old values disappear. This is flagged as a high-severity distribution shift with a message listing the new values.
4. The Wrong Currency Unit
The problem: Your international sales feed has always reported amounts in USD. A third-party integration is updated and starts reporting amounts in the local currency (GBP, EUR, JPY) without converting. For US orders, nothing changes. For international orders — which represent 35% of your data — amounts are now in the wrong unit.
Why static rules miss it: Your range check rule says amounts must be between $0 and $1,000,000. The values are still in that range (GBP and EUR are close to USD; JPY amounts might be 100x–150x larger but still within the max). Null checks pass. Format checks pass.
How behavioral scoring catches it: The mean value of the amount column shifts. If international orders average ~$500 in USD but ~£380 in GBP (still close) and ~¥55,000 in JPY (~$350 after conversion), the overall average value changes — sometimes subtly, sometimes dramatically (if JPY is dominant). For JPY, a run mean that jumps from $420 to $42,000 is a 100-sigma event.
5. The Join-Induced Duplication
The problem: Your data pipeline joins a customer table against a transactions table to produce a customer summary. A bug is introduced in the join key: instead of joining on customer_id, the join is now on customer_segment (which has 8 distinct values). Every customer is now joined to every transaction in their segment rather than just their own transactions. The output has 400x the expected rows — but all the data looks valid at the row level.
Why static rules miss it: If you don't have a row count rule, nothing fires. Even if you do, the valid-looking rows mean null checks, format checks, and range checks all pass. The uniqueness rule might catch it (customer_id now appears thousands of times instead of once) — but only if you have that rule and it's tuned to the right threshold.
How behavioral scoring catches it: The row count z-score would be off the charts (400x normal). The unique rate for customer_id would drop to near zero — also a massive anomaly. Both would be flagged as critical behavioral anomalies on the first run with the bug.
Why You Need Both
Static rules and behavioral scoring are complementary, not competitive:
| | Static Rules | Behavioral Scoring | |---|---|---| | What it checks | Fixed constraints you defined | Deviations from historical patterns | | Catches known problems | ✅ Yes | Sometimes | | Catches unknown problems | ❌ No | ✅ Yes | | Requires manual configuration | Yes | No | | Gets better over time | No | Yes (more history = better baseline) | | Threshold | Fixed | Adaptive |
The combination gives you full coverage: static rules enforce your known requirements; behavioral scoring catches everything else.
Sohovi runs both simultaneously: your DQ rules produce a DQ Score, and the behavioral scorer produces a Behavior Score. Both are shown on the run detail page, and both contribute to a complete picture of your data's health.
Key Takeaways
- Static rules are blind to gradual drift, row count anomalies, upstream changes you didn't anticipate, and anything that looks valid in isolation
- Behavioral scoring catches these by comparing current statistics against historical baselines
- The five most common behavioral anomaly patterns: gradual creep, pipeline truncation, upstream code changes, unit mismatches, join duplications
- Both static rules and behavioral scoring are necessary — neither alone is sufficient
FAQ
Q: Can behavioral scoring completely replace static rules? A: No. Static rules encode business requirements. Behavioral scoring detects unexpected deviations. You need both.
Q: What's the most common behavioral anomaly in practice? A: Null rate spikes are the most common. They're the most frequent signal of upstream pipeline issues.
Q: How quickly does behavioral scoring catch issues? A: On the very next run after the anomaly is introduced. There's no delay — it compares the current run against history immediately.
Q: Does behavioral scoring produce false positives? A: Low-severity flags (3–4 sigma) may occasionally be false positives. High-severity flags (6+ sigma) are almost always genuine issues.
Q: What should I do when a behavioral anomaly is flagged? A: Check the upstream data source first. Verify the anomaly is real. Then trace backward through your pipeline to identify the root cause.
Q: Can I set different z-score thresholds for different columns? A: Sohovi uses a uniform threshold of 3 sigma. Enterprise tools like Collibra offer per-column configuration.
Q: Does behavioral scoring work for the first run? A: No. It requires at least 2 historical runs to establish a baseline. The first few runs build the baseline; detection starts after that.
Q: What happens when data legitimately changes (e.g., seasonal patterns)? A: Legitimate changes produce behavioral flags initially. Over subsequent runs, the baseline adapts to include the new pattern. Seasonal patterns ideally require comparing against the same period in prior cycles.
Q: How is the Behavior Score calculated? A: Starting at 100, each high-severity flag subtracts 10 points, medium flags subtract 5, and low flags subtract 2. Score cannot go below 0.
Q: Where do I see behavioral anomalies in Sohovi? A: On the run detail page: Dashboard → Asset → Runs → click a run → Behavior Score card below the DQ Score gauge.
