AI can make assumptions. iDash guarantees accuracy by verifying the calculation logic before showing you the result.
The failure mode
Join a customer to their orders and the customer appears once per order. Count them and the count is wrong.
Every row this join produces belongs there. That is what makes the wrong total so hard to catch by eye.
| customer_id | channel | lifetime_value |
|---|---|---|
| c_1041 | Organic search | $6,180 |
| c_1042 | Paid social | $2,940 |
| c_1043 | Referral | $5,120 |
| order_id | customer_id | net_total |
|---|---|---|
| o_88401 | c_1041 | $2,310 |
| o_88402 | c_1042 | $2,940 |
| o_88403 | c_1041 | $1,940 |
| o_88404 | c_1043 | $3,180 |
| o_88405 | c_1041 | $1,930 |
| o_88406 | c_1043 | $1,940 |
| customer_id | lifetime_value | order_id | net_total |
|---|---|---|---|
| c_1041 | $6,180 | o_88401 | $2,310 |
| c_1041 | $6,180Repeated | o_88403 | $1,940 |
| c_1041 | $6,180Repeated | o_88405 | $1,930 |
| c_1042 | $2,940 | o_88402 | $2,940 |
| c_1043 | $5,120 | o_88404 | $3,180 |
| c_1043 | $5,120Repeated | o_88406 | $1,940 |
Sum of lifetime value across the join
$31,720
Three repeated rows carried their customer total a second time.
Sum after dedup on customer_id
$14,240
One row per customer, then add the column up.
1,842 customers who have placed 9,610 orders between them, asked for lifetime value by acquisition channel.
| Metric | Joined naively | Verified by iDash |
|---|---|---|
| CustomersCounted once per order | 9,610 | 1,842 |
| Lifetime valueEach customer summed once per order | $47.5M | $9.1M |
| OrdersMeasured on the inflated side, so unaffected | 9,610 | 9,610 |
Before any SQL is written, iDash computes a dedup plan from the shape of the aggregation. Same query, same plan, every time.
The compiler looks at which models are being aggregated, which joins the question needs, and which of those joins multiply rows on the measured side. This is arithmetic on the model graph, not an opinion.
Where a model is inflated, the compiler emits a step that reduces it to one row per primary key before the aggregation happens. The measure is then summed over rows that exist once.
The plan becomes real SQL for the source you connected: PostgreSQL, MySQL, SQL Server, ClickHouse, Trino or a file. The dialect differences are the engine's problem, not yours.
A separate rule inspects the generated SQL for fan-out afterwards, without knowing what was asked. Two independent passes have to agree before a number reaches you.
A refusal is a feature. Each one names the reason and tells you how to ask a version of the question that can be proved.
There is more than one way to connect two tables, and the routes disagree. Picking one silently would mean choosing an answer on your behalf.
What the compiler says
There are two paths from customers to revenue, one through orders and one through invoices, and they do not agree. Tell me which one this question means.
Name the path, or curate the relationship in the model so the choice is made once.
Deduping means keeping one row per key. With no key there is no definition of the same row, so there is no safe way to collapse the inflation.
What the compiler says
The events table has no primary key, so I cannot remove the duplicate rows this join creates. Add a key, or ask for a count of events instead.
Add a primary key upstream, or ask for a measure that lives on the inflated side.
One inflated table can be deduped in place. Two independently inflated tables in a single question need a plan that is not built, so the query stops rather than approximating.
What the compiler says
Orders and support tickets both multiply the customer row. Ask for one at a time and I can answer both.
Split the question in two. Both halves compile.
The plan is built in the compiler and verified again after the SQL is generated, by a rule that has never seen the question.
Question
What was revenue by region last quarter?
Resolved
Join path
Primary key dedup applied on order_id
order_items multiplies each order row 3.4 times on average. Revenue is measured on the order grain, so the compiler dedups on the primary key before aggregating.
Compiled plan
WITH orders_dedup AS (
SELECT DISTINCT ON (o.order_id)
o.order_id, o.customer_id, o.net_revenue, o.placed_at
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
)
SELECT r.region_name,
SUM(od.net_revenue) AS net_revenue
FROM orders_dedup od
JOIN customers c ON c.customer_id = od.customer_id
JOIN regions r ON r.region_id = c.region_id
WHERE od.placed_at >= DATE '2026-05-01'
AND od.placed_at < DATE '2026-08-01'
GROUP BY r.region_name
ORDER BY net_revenue DESCQuestion
What was revenue by campaign last quarter?
Ambiguous join path
Both paths are valid and they return different numbers. Rather than pick one and hand you a number that looks fine, the compiler stops.
last touch
session source
Compiler
ambiguous join path from 'orders' to 'campaigns': 2 equally short paths exist. Query one of them directly as the base model instead.
How to get an answer
Two labels, on every result. Semantic means the compiler produced it. Raw means it came from fallback SQL. There is no third, quiet option.
semantic
The question was calculated using your verified business definitions and checked for accuracy. This is the default path for standard metrics.
raw
For questions requiring ad-hoc analysis, iDash calculates the answer directly and clearly labels it as an unverified direct query.
The guarantees are narrow on purpose. Here is what iDash does not claim, so you know exactly what you are trusting.
Connect a read-only replica, ask something you already have the answer to, and compare.
Book a demo