---
title: "What Is Verifiable Conversational Analytics?"
description: "Verifiable conversational analytics answers plain-English questions with live queries — and ships the query, sources, and runtime so you can check every answer."
canonical: https://datarelix.ai/resources/guides/what-is-verifiable-conversational-analytics/
publishDate: 2026-08-07
updatedDate: 2026-08-17
lastVerified: 2026-08-17
---

# What Is Verifiable Conversational Analytics?

Verifiable conversational analytics is conversational analytics that shows its work. You ask a question in plain English; the system translates it into a real query, runs that query against your live database, and returns the answer together with its evidence — the exact query that ran, the source tables it read, the row count, and the runtime — so anyone can check what was measured instead of trusting a fluent paragraph.

## Who this definition is for

Data and BI leaders deciding whether conversational analytics belongs in their stack, and on what conditions. Executives who will consume the answers and want to know what stands behind a number before it goes into a board deck. Analytics engineers who will be asked to connect a warehouse and need a concrete definition to evaluate vendors against.

## Two kinds of tools that let you ask your database questions

"Conversational analytics" covers any tool that answers data questions asked in plain language. It covers two very different kinds of tool. Some answer from text — a pasted export, a document, the model's trained associations — and produce prose that cannot be traced to anything. Others translate the question into a query, execute it against the connected database, and attach the execution record to the answer. If you have arrived here looking for a way to [chat with your database](/chat-with-your-database/), that second kind is the one worth wanting. The mechanics of the translation are covered in [how text-to-SQL actually works](/resources/guides/text-to-sql-explained/).

## How it differs from a chatbot summary

| Dimension | Chatbot summary | Verifiable conversational analytics |
|---|---|---|
| Where the answer comes from | Trained knowledge, or text you pasted in | A query executed against your live database |
| Freshness | Frozen at training time or paste time | Current as of the moment the query ran |
| Can it show its work? | No — there is no query to show | Yes — the executed query ships with the answer |
| Reproducibility | Re-asking can produce a different answer with no way to compare | The recorded query can be re-run and compared |
| How a wrong answer looks | Confident prose with nothing to inspect | A visible query whose reading you can dispute line by line |
| What review means | Rewriting the analysis from scratch | Reading four pieces of evidence against the question |

The left column is not useless — it is fine for summarizing a document. It is the wrong tool for "what was revenue last month," because when the number is wrong there is no artifact to examine, only a paragraph to doubt.

## The four evidence layers

Verifiability is four specific artifacts attached to every answer, each catching a different class of error.

### The exact query that ran

Not a paraphrase, not "I looked at your orders" — the literal statement that executed. This is the layer that resolves ambiguity: plain language underspecifies, and the model must commit to one reading. The query is where that commitment becomes visible. Anyone who can read basic SQL can confirm the filter, the join, and the aggregation in one pass.

### The source tables it read

Real schemas contain traps: `orders` and `orders_v2`, a raw events table next to a modeled revenue mart. An answer computed from the wrong table can be internally consistent and still wrong for your business. Seeing the sources tells you whether the answer came from the tables your team treats as truth — a check that requires a glance and no SQL at all.

### The row count

Row count is a plausibility signal. A monthly revenue question over six months should aggregate to six rows; a "top customers" question capped at ten should return ten or fewer. Zero rows means the filter matched nothing — an answer of "no revenue" built on zero rows is a very different claim from one built on thousands of matched orders. The count also shows when an automatic row limit truncated a result, so you know you are looking at a bounded slice rather than the full set.

### The runtime

Runtime is execution context. A query that scanned a large fact table and one that hit a tiny lookup table leave different footprints, and a runtime wildly out of line with the question is a prompt to look closer at what was actually scanned. It also carries operational information reviewers care about. On engines billed by elapsed compute, such as Snowflake and Databricks, runtime is a rough cost signal; on BigQuery and Athena, which bill by bytes scanned, it is not — there it tells you about the shape of the scan rather than the spend. Either way it indicates whether a question is cheap enough to become a refreshing dashboard.

## A worked example: monthly revenue, checked in four looks

The example below uses a fictional retailer's demo schema — `customers`, `orders`, `order_items` — and is illustrative, not output captured from a live system.

**Question:** "What was monthly revenue for the last 6 months?"

A reasonable generated query on PostgreSQL:

```sql
SELECT
  date_trunc('month', o.ordered_at) AS month,
  SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.order_id
WHERE o.status = 'completed'
  AND o.ordered_at >= date_trunc('month', CURRENT_DATE) - INTERVAL '6 months'
  AND o.ordered_at < date_trunc('month', CURRENT_DATE)
GROUP BY 1
ORDER BY 1;
```

The chart looks fine either way. The evidence is what lets you interrogate it:

- **Which tables?** Revenue was computed from `orders` joined to `order_items` — raw transactional tables. If your team's revenue definition lives in a modeled mart, this answer used a different source, and the sources line says so before you present the number.
- **Gross or net?** The query sums every line item on completed orders. Refunds are not subtracted — `status = 'completed'` says nothing about later refunds. This is a gross figure, and only the query text tells you that.
- **Which window?** "Last 6 months" was read as the last six *complete* calendar months, excluding the current partial month. Defensible — but if you meant "including this month so far," the two `date_trunc` boundaries are where you would see the difference.
- **Which currency?** `unit_price` is summed as-is. If the retailer sells in more than one currency, this silently adds euros to dollars — a flaw the query exposes and a summary paragraph never would.

None of these checks requires re-doing the analysis. Each is a targeted question the evidence answers directly — the review habit worth building, step by step, in [how to verify AI data answers](/resources/guides/verify-ai-data-answers/).

## What evidence fixes, and what it doesn't

Evidence does not make the model infallible. The model can misread an ambiguous question, pick the wrong of two similarly named columns, or apply a metric definition your company defines differently — "active customer," "churn," and "revenue" mean different things at different companies, and no model knows your definition until someone writes it down in a schema description.

What evidence changes is the failure mode. In an unverifiable system, those errors are invisible: the answer is prose, and the only recourse is suspicion. In a verifiable system, the same errors are inspectable — the misread lives in a query you can see, on tables you can name, with a shape you can sanity-check. The error rate is a property of the model; whether errors are catchable is a property of the architecture.

Three things follow, and they are the honest limits of the category. Evidence only works if someone reads it, so a team that never opens the query panel gets the risk profile of an unverifiable tool with extra steps. Answer quality tracks schema quality: cryptic column names and absent descriptions degrade any system in this category, and curating descriptions is real work that falls on your team. And the category is scoped to reading. Writing data, running migrations, and multi-step modeling with heavy business logic belong in your transformation and administration tooling, with conversational analytics querying their outputs.

## Security, in brief

Verifiability and security come from the same design decision: the model proposes, and a separate execution layer validates and runs each step. Generated statements are parsed into a syntax tree and rejected unless they are reads — [how the validator works](/resources/guides/read-only-ai-analytics/) — and the credential is decrypted only at execution and never enters the model's context — [the credential boundary](/resources/guides/credentials-away-from-the-model/). The security page states both in canonical form.

## A buying checklist

Evaluating tools in this category, ask each vendor:

- Can you see the exact executed query on every answer — by default, not on request?
- Can you see the source tables each answer read?
- Is access read-only by design — enforced by parsing and validating every statement, not by asking the model to behave?
- Where do credentials live, and does the model ever receive them?
- Are row limits applied automatically to every query?
- Is every run recorded — question, plan, executed query, result — and reopenable later?
- If the tool runs generated analysis code, is it isolated, with network access blocked?
- Does the account and access model match how your team needs to work?

A vendor who cannot answer the first two leaves you nothing to check an answer against.

## One implementation of the category

Datarelix is a hosted implementation of the definition above: every answer ships with all four evidence layers, and every run is reopenable from history. Answers worth keeping become dashboards that refresh from the same query logic, per the [dashboards guide](https://docs.datarelix.ai/guides/dashboards/). The full surface is on the [features page](/features/), and the execution boundaries are on the [security page](/security/).

## Notes and provenance

Product statements describe Datarelix as shipped in August 2026; the [security page](/security/) is canonical. The worked example uses a fictional retailer's demo schema and is illustrative rather than captured from a live system. The four-layer framing and the buying checklist are ours; no external benchmarks, citations, or customer references are used.

## Next: the mechanism

Go one layer down. [How text-to-SQL actually works](/resources/guides/text-to-sql-explained/) walks the pipeline from schema context to structured plan to validated execution, which is what makes the four evidence layers possible in the first place.