The pipeline
Each stage is a pluggable component. We swap implementations to fit the customer's stack and constraints.
- Voice capture. Browser Web Audio or mobile native; on-device VAD (voice activity detection) trims silence.
- Speech-to-text (ASR). OpenAI Whisper (self-hosted or API), Deepgram, Amazon Transcribe, or Google Speech-to-Text. Indian-English and multi-Indic support depending on choice.
- Intent & entity extraction. An LLM (Claude or GPT) reads the transcript, extracts the metric, the dimensions, the time window, and the filters — constrained to what the semantic layer exposes.
- Semantic-layer query. The structured intent is compiled to a query against dbt MetricFlow, Cube, AtScale, or Looker LookML (whichever the customer uses). The semantic layer enforces metric definitions and joins.
- Warehouse execution. The compiled SQL runs against the customer's warehouse — Snowflake, BigQuery, Databricks, Redshift, Postgres. RBAC is enforced at the warehouse, not the chatbot.
- Visualisation. An LLM picks an appropriate chart type from the result shape (time-series → line; categorical → bar; etc.). Renders via Plotly, Apache Superset embedding, or the customer's existing BI surface.
- Optional voice response. Text-to-speech via Amazon Polly, ElevenLabs, or Google Cloud TTS. Optional — most users want the visual.
Why a semantic layer matters
Naive text-to-SQL fails on real enterprise schemas. Joins are wrong. Metric definitions disagree across departments. The same word means different things in different tables. The semantic layer is the contract that resolves all of this before SQL is generated.
- Metric consistency. "Revenue" is defined once, in code, with the right grain (recognised, gross, net — explicit). Every query uses the canonical definition.
- Join correctness. The semantic layer knows which tables join on which keys. The LLM cannot invent a join.
- Authorisation. Row-level and column-level security is applied at the warehouse, governed by the user's identity. The chatbot has no superpowers.
- Citations. Every answer can show the underlying tables, columns, and the SQL that ran. Auditability by default.
For depth, see our resource on why text-to-SQL needs a semantic layer.
What it does well — and what it doesn't
InVoIQ is honest about its operating envelope.
It does well
- Defined metrics over defined dimensions ("revenue by region last quarter").
- Common time-window comparisons ("month over month", "year over year").
- Top-N and bottom-N queries.
- Drill-down within metrics already modelled in the semantic layer.
It doesn't pretend to do
- Free-form analysis on un-modelled data — if it's not in the semantic layer, the agent says so and asks.
- Statistical inference (causal claims, regression) — hands off to a notebook or analyst.
- Forecasts — references the team's existing forecasting models if any; otherwise refuses.
- Anything that involves PII without proper authorisation context.
How it compares to native BI tools
The major BI vendors now ship voice / natural-language layers — Tableau Pulse, Power BI Copilot, ThoughtSpot Sage, Looker Conversational Analytics. They work well inside their platforms.
InVoIQ is for organisations that want:
- BYOM (bring-your-own-model) — choose Claude, GPT, or open-weight models per use case, including on-prem deployment for regulated workloads.
- Vendor-agnostic — works across multiple BI surfaces and warehouses; not locked to one vendor's ecosystem.
- Data-residency control — ASR, embeddings, and inference can run in customer-controlled regions for DPDP / regulated workloads.
- Custom governance — integrates with the customer's identity, audit, and approval flows rather than a SaaS vendor's.
Where it fits
InVoIQ is the voice-driven layer on top of AI-Powered BI. It runs on the Data Platform we build, governed by Responsible AI controls, with quality assured by Eval@Core.