Why a number from your data should come with its SQL

Sushrut Ikhar, Co-founder, Matih Labs —

Why a number from your data should come with its SQL

TL;DR — A model that turns a question into SQL can write a query that parses, runs and returns a clean-looking number that is wrong. The cause is almost never syntax. It is meaning. A schema says what your tables are named, not what they mean. We cannot promise that a question will never be misread. So Mitra puts the SQL next to every answer, together with a chart, so the answer can be checked. Here are three ways it goes wrong, and what to do about each.

Someone asks a data question in plain language. The tool writes SQL, runs it, and shows a number. The number looks fine. Two weeks later it is in a board deck, and it is wrong in a way nobody caught.

Modern models write fluent SQL. The mistakes that matter are not about fluency. They are about what the data means, and that is not written in the column names.

What goes wrong with joins? The fan-out that counts revenue twice

Ask for July revenue from shipped orders on a typical commerce schema and you can get this:

SELECT SUM(o.amount)
FROM orders o
JOIN shipments s ON s.order_id = o.id
WHERE s.shipped_at >= '2026-07-01';

The query is valid and the foreign key is real. But if an order ships in two boxes, its amount is counted twice. Revenue inflates by the fan-out of your fulfilment process, so the error changes month to month as your shipping habits change. Nothing in the schema warns you. How many shipments an order has is a fact about your operations.

You do not need a new tool to see this. You need to be able to read the query. A person who reads the SQL above spots the join in seconds.

Why do metrics drift? One question, three meanings of "active"

"How many active users did we have last month?" is not one question. Does active mean logged in, or did something that counts? Are internal and test accounts excluded? Every company has a real answer, written in a document or in one analyst's head.

A tool that only sees the tables picks one meaning. Ask twice on different days and you may get two. That is how one "active users" ends up as three numbers in three decks.

When you can see the SQL, the meaning is no longer hidden. The filter that defines "active" is right there on the page. If it is not the filter you meant, you say so in a follow-up, in plain language, and the answer is redone.

Which rows should not count? The leftovers in production tables

Production tables hold things the business does not count: orders with status = 'test' from QA, deleted rows, refunds stored as negative line items, staff accounts. People who use these tables every day filter them out without thinking. A model reading only the schema does not know they are there.

The error is usually small, a few percent. That is exactly why it gets through. Reading the WHERE clause is the fastest way to catch it.

How do you make a number checkable?

We hold one bar for Mitra. Every answer must be checkable. So an answer comes with:

  • A chart, so the shape of the result is visible and odd values stand out.
  • The SQL behind it, so the exact question put to your data can be read.
  • A conversation, so a correction is one more message, not a ticket.

Trust is a working habit, not a property of a model. If a tool cannot show you which join it chose or which filter it applied, it is asking for faith.

What about the numbers other people see?

Once an answer is good, it tends to travel. You can build a dashboard from answers, keep versions of it, present it, download it as a PDF, duplicate it, and share it with your workspace. Dashboards can be embedded as well, either as a signed embed with fixed filters per viewer, or as a public embed.

That is when the SQL matters most. A number that many people use should be a number someone has read the query for. For anything you plan to repeat to a board, a customer or a regulator, we suggest this habit: open the SQL once, read the joins and the filters, and then share. Our guide to asking your first question is the place to start, and the sharing and presenting docs cover dashboards.

FAQ

Can a better model fix this?

A better model guesses more plausibly. But the three failures above are not guesses about syntax. The information about your shipments, your definition of "active" and your test rows is simply not in the schema. Someone has to read the result against what they know.

Do I have to read SQL to use Mitra?

No. You ask in plain language and get an answer with a chart. The SQL is there for checking. If you do not read SQL, a colleague who does can review the query for numbers that matter.

What if the answer is wrong?

Ask a follow-up in the same conversation and say what is off, for example "count each order once" or "leave out test orders". The answer is redone, and you can read the new SQL.

Does this work on uploaded files?

Yes. Mitra answers over connected data sources and over uploaded files such as CSV and Excel, and the answers carry a chart and SQL in both cases.

Where can I see how to ask from code?

The public REST API at /api/v1 and the SDKs are documented at matih.ai/docs/api.