Summarize with AI
In text-to-SQL UX, do not hide the query, and do not show raw SQL as the answer either. Show a short plain-language restatement of what the query actually counted, which dates, which filters, which definition, and let the user change any line. Keep the SQL one click away for the people who read it.
Hiding the query feels like the simple choice, because most of your users never learned SQL. But a chart with nothing under it cannot be checked by anyone, so the first wrong number travels as far as a right one. For an AI data product, that is how you lose an account without a single complaint.
The churn chart that went into a board deck
Picture an AI analytics tool for B2B software teams. It connects to the company's Postgres database and its Stripe sync. The main screen is one input with the placeholder Type a question about your data. Under it sit three suggestion chips: MRR by month, Top accounts by seats, Churn by plan.
The VP of customer success at a 60-person company types churn by plan last quarter. About four seconds later a bar chart appears, titled Churn by plan, Q2. Starter 41, Team 17, Enterprise 2. One grey line under it reads Based on 1,284 rows from subscriptions. In the bottom right corner is a small link that says View SQL. She has never clicked it.
Behind the chart, the model picked the wrong date. It filtered subscriptions on created_at between 1 April and 30 June, then counted the ones whose status is now canceled. So the chart shows Q2 signups that have since left. It does not show accounts that left in Q2. The real Q2 count for Starter, read from cancelled_at, is 88. The query was valid, it ran, and it answered a question nobody asked.
She pastes the chart onto the Retention slide of the board deck. Two weeks later the finance lead pulls the Stripe report and gets a different number. Nobody in the room can say which is right, because nobody in the room reads SQL. She goes back to sending questions to the data contractor, and her account goes from about thirty questions a week to none.
Why hiding the query felt like the simple choice
Now stand where the founder of that tool stands. His team spent a year on the part nobody sees: a few hundred metric definitions written with customers, rules for which table wins when two disagree, a layer that maps plain words onto columns. The product page shows none of it. It shows the input and a chart.
His evals pass. They check that the SQL runs and that the result matches a reference query for a fixed set of questions. By that measure the churn answer was fine. What he sees instead is a usage graph for one account that drops to zero in a week, and a support thread that ends with a screenshot of two numbers that do not match.
His first fix is a line under every chart: AI can make mistakes, check important numbers. His second is moving View SQL from the corner to its own tab. Clicks on the tab stay close to zero, because the people who would understand it are not the people asking. In his next pitch an investor asks what stops the warehouse vendors from shipping the same box. His real answer is the definitions. They are exactly what the interface hides.
Raw SQL is not the fix either
Most advice on this question picks a side. One camp says hide the SQL because business users find it scary. The other says always show it, for trust and transparency. Both treat the SQL as the thing to decide about. It is not. The thing the user needs to check is the meaning of the query, and SQL is just the form that meaning happens to be stored in.
Give the VP of customer success a 38-line query with two joins and a CASE statement and she cannot find the mistake, even if it sits on screen the whole time. The error was one column name, created_at where it should have said cancelled_at. To her, both look like the same kind of noise. Showing her the SQL moves the blame onto her without giving her any way to catch the problem.
Here is the claim we would defend. Hiding the query does not make a data product simpler. It makes it unverifiable. And showing raw SQL to someone who cannot read it is hiding it in plain sight. The answer is a third thing: the query, read back in the words the user used to ask.
The answer is four lines above the chart
Put a short restatement above every chart, written from the query the model actually ran. For the churn question, it reads like this:
- Counting: paid subscriptions that ended. Downgrades are not counted.
- When: cancelled between 1 April and 30 June. Change to signup date.
- Grouped by: the plan each account was on when it left.
- Left out: 12 internal test accounts. Show them.
On the original query, the When line would have read signed up between 1 April and 30 June. The VP of customer success sees the problem in two seconds. She did not have to know what a join is. She only had to recognise her own question, or notice that it was not hers.
Three rules make the card work. First, generate it from the SQL, not from the user's question. A restatement written from the question just repeats the question back with confidence, and it would have printed the right words over the wrong chart. Second, make every line a control. The date line is a dropdown with cancelled date and signup date, and changing it reruns the query. Third, name the definition and where it came from, such as Churn, as defined by your team on 3 May, so the user knows whose rule produced the number.
When the model had to choose between two close readings, do not choose quietly. If cancelled date and signup date give answers far apart, show both side by side. Two ways to read this for Starter: 88 accounts left during Q2, or 41 of the accounts that joined in Q2 have since left. Let her pick. It costs one extra query and saves a slide.
This is the same idea that sits behind AI audit interfaces, where a reviewer needs the decision in plain words before the raw log. Here it lives inside a single answer. It also pairs with the habit of putting one plain sentence under every metric: that sentence says what the number means, and the restatement says how it was counted.
When raw SQL earns a place on screen
SQL still belongs in the product. It just should not be the only explanation, and it should not be the default for everyone. A simple rule covers most cases:
- Show the restatement to everyone, on every answer, always above the chart.
- Show the SQL on request, with a copy button, for anyone who wants to run it somewhere else.
- Open the SQL by default for people who told you at signup they write SQL, or who opened it on their last three answers.
- Attach the restatement to every export. A chart pasted into a slide should carry its four lines as a footnote.
- Never show nothing. A chart with no visible reading is the one option that fails every user.
The copy button is for the customer's data team. Once analysts have checked a few queries against their own models, they tell everyone else the tool can be trusted.
There is a useful example of this outside data. On the site we built for Chariot, a speech AI lab, every demo pairs what you write with how the model will say it. Rx #88214 sits next to prescription number eight eight two one four. A visitor can check the model's reading of a tricky line before trusting it, without knowing anything about how speech models work. The restatement card does the same job for a query.
What an unverifiable answer costs you
A data product is only used if its numbers get reused. The answer that matters is the one someone pastes into a doc, a deck or a Slack thread. If people learn they cannot check a number, they stop reusing it, and the account keeps paying for a few months before it quietly cancels. Product-led SaaS benchmarks put activation for most products at 20 to 40 percent of signups. In a tool like this, a trust break after the first board deck can push an account out after it already activated, which is the more expensive way to lose it.
There is a second cost, and it is about how the company is read. Investors at Series A now ask a blunt question: would this company still have a reason to exist if a foundation model provider shipped something ten times better tomorrow. An input box that returns charts looks like a model call with a logo on it. The defensible part, the definitions, the table rules, the knowledge of what churn means at this customer, has no screen.
The restatement is that screen. Every time the card reads Churn, as defined by your team on 3 May, it shows the user something a general model cannot know. Hiding the query hides the work that makes you more than a wrapper. Showing it in the user's words puts that work in front of the buyer, and later in front of the investor watching the demo.
A restatement test you can run this week
You do not need a redesign to find out whether this is hurting you. You need an afternoon and last week's logs.
- Pull 30 real questions from last week, with the SQL the model ran for each one.
- For each, write one line saying what the SQL actually counted. Work from the SQL only. Cover the question with your hand if you need to.
- Now read the question. Mark every case where your line and the question disagree. Those are your silent wrong answers.
- List the choices the model made that the user never saw: which date column, which time zone, which table, what it left out, how it grouped.
- Pick your three most asked question types and put a four-line card above their charts, with the date line as a dropdown.
- Add the card to exports and copy to clipboard, so the reading travels with the number.
- Log every time someone changes a line. Each change is a wrong answer caught before it reached a board deck.
Expect step three to surprise you. You know your schema, so you read every query the way it was meant.
Founders building data products often look at a ranking of product design agencies for AI data platforms once the answers start to outgrow the chat box. At Studio Maydit we design the screens where people decide whether to trust an AI product enough to keep using it, and for a data tool that is the answer screen. Fixed-scope projects run three to four weeks and end with a diagnosis of what is leaking in the product. If your users cannot tell what your charts counted, book a 30-minute call and we will draft the restatement card for your top question with you.
