Six steps between a question and an answer

How conversational analytics actually works — the pipeline that runs under a plain-English question, and the specific thing that can go wrong at each stage.

Someone types "how many users signed up in the last seven days?" and a number comes back. The interaction is deliberately unremarkable, which is the point — and also why it's worth knowing what happened in between.

Six stages run under that question. Each one can fail quietly, and the failures compound: a wrong reading of intent in stage one produces a technically flawless query in stage three and a confident, wrong summary in stage six. Understanding the pipeline is mostly useful for knowing where to look when a number seems off.

Stage What it does What breaks here
1. Intent Extract metric, entity, time window, operation Ambiguous question resolved silently
2. Mapping Business terms → tables and columns No mapping, so the model guesses
3. SQL Write the query Wrong grain, wrong column, dropped filter
4. Validation Parse, permissions, read-only, cost Skipped entirely
5. Execute Run, format, compute, rank Nulls read as zero, bad denominators
6. Present Summary, chart, follow-ups A causal claim the data didn't support

Stages one to three make a correct query more likely. Stage four is the only one that can prevent an incorrect one from running.

Stage 1 — Understanding the question

From "show me our top-performing products this quarter" the system has to extract a metric (what does top-performing mean?), an entity (products), a time window (this quarter — calendar or fiscal?), and an implied operation (rank, then limit).

This isn't parsing words. It's recovering a specification from a sentence that doesn't contain one.

Where it breaks: ambiguity resolved silently. "Our best customers" — by revenue, order count, retention, or contract value? Each is defensible; only one was meant. A system that asks is more useful than one that guesses well, and far more useful than one that guesses badly without saying so.

Stage 2 — Mapping business terms to data

The words people use aren't the words in the schema. A semantic layer is what connects them.

Business term Database table / field Customers customers Revenue sales_amount Orders transactions Signups user_registrations

Without this, the model infers the mapping from column names — which works until your revenue column is called amt_2, or until there are three columns that could plausibly be revenue.

Where it breaks: no mapping exists, so the guess gets made in stage three instead, where it's invisible. This is the stage that most determines whether a tool is accurate on your schema rather than on a demo one.

Stage 3 — Generating the query

With intent and mapping settled, writing SQL is the most reliable step in the pipeline. Modern models are good at it, and it is the part everyone worries about and the part least likely to fail.

What fails here isn't syntax. It's the judgement calls the previous two stages left open — which date column, which grain, which exclusions.

Where it breaks: a join that fans rows out and inflates every total. A filter on created_at when the business reports on completed_at. Test accounts nobody excluded. All produce valid SQL and a plausible number.

Stage 4 — Validation, the stage that gets skipped

Before anything runs, the query should be checked: that it parses, that every table and column it names exists and is one this person may read, that it's a single read-only statement, and that its estimated cost is acceptable on your data volumes.

This is the only stage in the pipeline that can prevent a bad outcome rather than merely make a good one more likely. Everything upstream improves the odds; this is the gate.

Where it breaks: it isn't there. Plenty of products go straight from generation to execution, because in a demo nothing bad happens. Ask what the validation step actually checks and whether it's enforced in the application or by database privileges — the second answer is the one that holds.

Stage 5 — Executing and shaping results

The database returns rows. Those rows usually need work before they're readable: formatting, percentage calculations, ranking, period-over-period comparison, rounding.

Where it breaks: shaping can hide problems. A null average silently rendered as zero. A percentage computed on a denominator that excluded rows the numerator included. Rounding that turns a suspicious figure into a clean one. The presentation layer is where a wrong number stops looking wrong.

Stage 6 — Presenting the insight

Rather than a grid, good tools return a summary, a chart, and a suggested follow-up. This is the real shift the category is selling — from data retrieval to insight generation.

It's also where the most interesting failure lives. Consider a summary of exactly the kind these systems produce:

"Revenue increased 12% vs. last month, driven mainly by enterprise customers."

The first half is arithmetic: two numbers, one comparison, verifiable. The second half is a causal claim, and the query almost certainly didn't establish it. Showing that revenue rose and that enterprise revenue rose does not show that enterprise revenue drove the increase — that requires decomposing the change by segment and comparing contributions, which is a different query than the one that produced the 12%.

Summarization models produce this phrasing readily, because it's how a human analyst would narrate the result if they'd done the extra work. The sentence reads as analysis and is partly assertion. A tool that says "revenue increased 12%; enterprise revenue increased 19%" is telling you less and claiming only what it checked.

When you evaluate the presentation layer, this is the thing to look for: does the prose stay inside what the query actually computed?

Why the pipeline framing is useful

Mostly for debugging. When a number looks wrong, the stage it broke at tells you what kind of fix it needs.

• Wrong interpretation of the question → stage one. Rephrase, or the tool needs a clarification path.
• Right question, wrong columns → stage two. You need a semantic layer, not a better prompt.
• Right columns, wrong number → stage three. Check the grain and the filters.
• It ran and shouldn't have → stage four. The gate is missing.
• Numbers don't reconcile with a known total → stage five. Look at null handling and denominators.
• The narrative overstates the data → stage six. The summary went past what was computed.

"The AI got it wrong" isn't actionable. "Stage two has no mapping for revenue" is.

What's genuinely hard

Three things remain unsolved rather than merely unimplemented.

Ambiguity is not a bug to fix. "Best customers" is underspecified in the question, not misunderstood by the system. The only real answers are to ask, or to have the definition written down in advance. Both are organizational work, not model work.

Business context lives outside the database. Every company defines active user, revenue, churn and conversion differently, and none of those definitions are in the schema. A system without them will be confidently wrong in a way that's hard to detect, because the SQL will be perfect.

Multi-step reasoning is still human work. Custom metrics, statistical testing, causal analysis, modelling — the pipeline above answers questions. It doesn't do analysis, and the gap between those two things is where analysts still live.

The relationship, inverted

What conversational analytics changes isn't the amount of work involved — the six stages are, if anything, more machinery than writing a query yourself. What changes is who does it. Instead of a person adapting to the database, the database adapts to the person.

That's worth having, provided the middle of the pipeline is honest: that stage four exists, that stage two is real rather than inferred, and that stage six stops at what stage five actually computed.

See the pipeline, not just the answer. DBx Studio shows the generated SQL beside every result, validates before it executes, and maps business terms through a semantic layer rather than guessing at column names — so each stage is something you can inspect rather than trust.

Query it. Analyze it. Visualize it. — all with DBx.