You shouldn't need a data engineer to answer a business question.
Every time someone on your team needs a number, they file a ticket. Or ping an analyst. Or wait for the next dashboard refresh. That's the workflow we're replacing. Ask the question, get the chart, read the narrative that explains what the data means. The SQL is right there if you want to check it.
Narrative generation: we tell you what the data means
Most analytics tools hand you a chart and leave you to figure it out. We generate a structured narrative for every result. Not a generic summary — a grounded analysis built from the actual query output.
Every narrative follows a mandatory arc: a headline that names all series with their direction and explicit date ranges, a key insight that identifies cross-series patterns like shared peaks or divergences, and per-series statistical facts — non-competing observations that each add new information.
Density-based allocation: depth scales with complexity
Not every chart needs the same level of narrative depth. A single-series bar chart with 5 rows doesn't need three paragraphs of analysis. So we compute a data density tier deterministically in code — not by the LLM — and use it to gate which narrative fields get populated.
Summary only. Headline and key insight are set to null.
QA (question alignment) + summary. Key insight populated when cross-series patterns exist.
All three fields: headline, key insight, and per-series facts. Full statistical analysis.
Multi-turn context: conversations remember what you asked
Each conversation tracks entities and filters across turns. When you say "break that down by quarter," the system knows you're refining the prior analysis — it doesn't start from scratch. It uses keyword delta tracking to detect what changed between your current question and the previous one.
Filter changes are classified into four operations: add (new filter that didn't exist before), replace (same dimension, different value), subtract (remove a filter), and preserve (carry forward unchanged). The SQL gets rebuilt surgically — only the parts that changed get regenerated. Everything else carries over from the previous turn's verified query.
This is why follow-up questions are fast. We're not re-profiling your schema or re-resolving entities on every turn. We're applying a delta to a known-good query. See the full pipeline architecture →
Conversational analytics vs traditional BI
| Feature | Conversational (Chion) | Traditional BI |
|---|---|---|
| You need a number by EOD | Ask Chion, get the chart in under a minute | Ping the analyst, wait until end of day — maybe longer |
| SQL knowledge required | None — ask like you'd ask a colleague | Expert-level, typically requires an analyst or engineer |
| Something looks off | Click the chart, read the SQL — every number has a source | No way to check without an analyst or data engineer doing a deep dive |
| New question comes up | Just ask — every question is ad-hoc | Requires reframing the dashboard, potentially by end of day or later |
| Query verification | Contract-enforced, multi-phase verification | Manual review by whoever shipped it — if anyone reviews at all |
| Visualization | Auto-generated D3.js charts with zoom and filtering | Time-intensive builds in Tableau or similar tools, or Google Sheets that can be reran and refreshed |
Ask your data a question
Point it at your database and ask something. See what comes back.