A number everyone trusted was overstated by roughly a third — not because anyone lied, but because the query summed groups that overlap. A human eventually caught it. An AI pointed at the same metric would have inherited the error silently, on every decision, at machine speed.
When you deploy an LLM, an agent, or an AI feature on top of your metrics, it doesn't question the number — it acts on it. If the same metric means three different things across your stack, the model learns the wrong signal and applies it confidently, at scale, invisibly. A wrong dashboard tile is one bad meeting; a wrong number wired into AI is a wrong decision automated across every customer. The time to check your definitions is before the model ships, not after it's been wrong for a quarter.
A team monitored users against several automated flagging rules — rules that each flag a different kind of at-risk behavior. Call them Rule 1, Rule 2, Rule 3. Each rule produces a cohort: the set of users it flagged, and the transaction value attached to those users.
Leadership asked a reasonable question: "How many users are we flagging, and how much settled volume is under review?" The dashboard answered it, built the obvious way:
total_flagged_users = users(R1) + users(R2) + users(R3) volume_under_review = volume(R1) + volume(R2) + volume(R3)
Clean SQL. Ran fast. Reconciled to each rule's own report. Everyone trusted it.
The rules overlap. A single user who trips Rule 1 and Rule 3 is a real, common case — that is exactly the kind of user a risk team wants to see. But when you add the cohorts together, that user is counted twice. Their settled volume is added twice.
Adding the per-rule numbers answers a different question than the one leadership
asked. SUM across overlapping groups measures rule-flag events,
not distinct users. The tile looked like a headcount and a dollar figure;
it was actually a count of (user × rule) pairs.
| Figure | Naive sum across rules | Distinct (correct) | Overstatement |
|---|---|---|---|
| Flagged users | ~2,600 | ~1,900 | ~37% |
| Settled volume under review | inflated by the same double-counted users | materially lower | material |
The error is invisible at the tile level. Each rule's own number is correct. The total is wrong. Nothing in the dashboard tells you the groups overlap.
Not by staring at the SQL — the SQL was "correct" in the sense that it did what it said. It was caught by asking a question the tile could not answer:
"Is this a count of users, or a count of flags? If I
COUNT(DISTINCT user) across all rules, do I get the same number as the
sum of the cohorts?"
The distinct count came back well below the sum. That gap is the
double-count. The moment the two numbers disagree, you know the cohorts overlap and
the total cannot be a SUM.
Two changes, both small:
COUNT(DISTINCT user). For settled volume, first
union and de-duplicate the records at the defined entity/transaction grain, then
SUM the one canonical amount for each record. One user contributes
once to a user total, regardless of how many rules they trip.The corrected tile shows: per-rule detail, plus a distinct total that is always ≤ the sum. If someone asks "why doesn't the total equal the parts," that is the feature, not the bug — it is the overlap made visible.
This is not an industry-specific problem. It is an overlapping-cohort problem, and it hides in the most common metrics operators cite — the same ones an AI will read:
SUM counts or amounts across groups that can share the
same underlying entity. For counts, take the set union with
COUNT(DISTINCT …). For amounts, union and de-duplicate at the
metric's defined grain, then SUM one canonical amount per record.
If a "total" equals the sum of overlapping parts, it overstates the unique
population or amount.
The one-line checks: for counts, does SUM(part counts)
equal COUNT(DISTINCT entity)? For amounts, does the naive sum equal
the canonical post-de-duplication SUM(amount) at the same grain?
If not, the parts overlap and the naive total is wrong.
A human eventually caught this one — someone asked the right question in a meeting. That safety net disappears the moment you point AI at the metric. An LLM, an agent, or an AI feature doesn't ask "is this a count of users or a count of flags?" It reads the number and acts: it prioritizes, it routes, it answers a customer, it reallocates spend. If the definition is wrong, the model is now wrong at machine speed, on every decision, and it sounds confident doing it.
Metric trust is not "is the SQL correct." It is "does this number answer the question the decision-maker — or the model — thinks it answers." Those are different tests, and only the second one catches this class of error before it scales.
Based on a real engagement. Company unnamed; all figures fuzzed and illustrative; no client data used. Prepared using the analytics-ai-platform metric-trust methodology. · Krzysztof Piłat, Principal Data Analyst