Conversational analytics that don't make things up: AI-BI/DW on a governed semantic layer

Natural-language-to-SQL is a parlour trick when it runs over raw warehouse tables. Ask the model for "revenue last quarter" and it will write a plausible query against whichever table it found first. The query will run. The answer will look right. It will often be wrong.

The fix is not a better language model. The fix is constraining what the model is allowed to query.

Why NL-to-SQL alone hallucinates

Three structural reasons.

First, no version of "revenue" is canonical at the table level. Booked, billed, recognised, deferred, gross, net of refunds - same table, different columns, no policy on which one means "revenue."

Second, the model has no awareness of governance. Row-level security, fiscal calendars, currency conversion rules, restatements - these live in metadata the model never sees.

Third, the model cannot explain itself in the units the business uses. "Revenue grew 12%" is a sentence. "Revenue grew 12% defined as gross billed in EUR using the December close exchange rate, excluding the entity we divested in November" is an audit-ready statement. The model has the first one. It needs the second.

The lakehouse, semantic objects, KPI library

DivetIQ's AI-BI/DW is structured so the model cannot avoid the constraints.

• Lakehouse storage sits on open table formats (Iceberg, Delta) with a medallion architecture: bronze (raw events), silver (conformed), gold (semantic-ready). Native CDC from every platform module, plus connectors for external systems.
• Semantic objects define every business measure once - revenue, customer, order, FTE, OEE, DSO - with versioned definitions, fiscal calendar awareness, and cross-tool consistency. Power BI, Tableau, Looker, Excel and the conversational analytics agent all hit the same definitions.
• Prebuilt KPI library ships dozens of measures wired to the specialist agents in the catalog. The Cash Position agent and the conversational analytics interface query the same KPI object; the AE asking "how is my cohort doing?" gets the same denominators the agent uses for its own threshold checks.

The conversational agent does not generate SQL against tables. It resolves the question to a semantic object, compiles a query that respects the object's definition, and runs it under the asker's access scope.

Trust and explainability per answer

Every answer carries its receipts:

• The semantic object resolved (with version).
• The compiled query.
• The row counts and partitions read.
• Any masking applied for the asker's scope.
• Anomaly flags - is this number outside its historical distribution?

If the user asks the same question phrased three different ways, they get the same number from the same semantic object - or they get a deliberate, surfaced disambiguation prompt. The platform never quietly picks one definition over another.

The embedded analytics SDK and the headless analytics API expose the same semantic layer for customers building their own apps. The model never escapes the contract.

This is what makes conversational analytics auditable instead of cute. The trick is not in the language model. The trick is in what the language model is forbidden to do.