Engineering
·
How our agent checks its own SQL before it answers
A query that fails is easy to catch. The ones that worry us run without complaint and return the wrong number.
Theo Anand
·
3 min read

A query that fails is easy to catch. The database throws an error, the agent reads it, and tries again. The queries that worry us are the ones that run without complaint and return the wrong number.
Before Logit returns a number, it runs a set of checks on the SQL it just wrote. These are ordinary checks, the kind a careful analyst runs out of habit. We wrote them down because an agent skips anything left implicit.
Does the join change the grain?
The classic silent error in analytics is a join that multiplies rows. Join orders to shipments, and an order with two shipments is suddenly counted twice. The query runs. The total is wrong.
More rows aren’t always a mistake. If you’re summing shipping costs, you want one row per shipment. So Logit notes the grain the metric needs, one row per order or one per shipment, and compares row counts before and after each join that can change it. It also watches for the opposite failure: an inner join that quietly drops orders with no match.
Are the dates what you meant?
“Last month” can mean the previous calendar month or the last 30 days. “This quarter” depends on whether your company runs on a fiscal calendar. Time zones move orders across midnight, and across months.
Logit settles these before it runs anything. It uses your team’s saved definitions when they exist and states its assumption when they don’t. The date range always appears next to the answer.
What happened to the missing values?
AVG skips nulls, so a half-empty column can still produce a reasonable-looking average. COUNT(*) counts every row, while COUNT(column) skips the nulls, and the gap between the two is part of the answer. A breakdown by region shows nulls as their own group, but an inner join to a region table, or a chart that hides that group, makes the rest look complete.
The agent checks for nulls in every column it uses and reports them when they’re large enough to change the answer.
Does the result look like your data?
Some errors only show up as strange numbers: a conversion rate above 100 percent, revenue dated before the company existed, one region carried by a single enormous customer. Logit compares each result to the ranges it has seen in your data and flags anything that falls outside them.
This check doesn’t explain the number. It flags outliers, and some of them are bugs. Some are a real customer who’s just that big. Either way, it stops and asks.
When a check fails
A failed check never becomes a quiet correction. Silent fixes are how a wrong total ends up in a quarterly review. If Logit rewrites a query, the answer says what changed. If it can’t, you get the number with the warning still attached, and the decision stays with you.
If you run data at your company and have a check you swear by, send it to hello@logithq.com. The good ones end up in the product.