Natural-language analytics
Explore questions over databases you already run using read-only access and documented schema definitions. Validate material answers against your own reports.
The cost is not the delay
The path from a question to an answer runs through people: raise a request, wait in the data team’s queue, receive a report, discover it answered the wrong question. Every organisation knows this and most have decided it is the price of doing business.
It is not, and the reason is subtler than the waiting.
Watch a real line of enquiry when each step costs a week. What has margin done in this region? Then, seven days later, was that revenue or cost? Then, seven days after that, which units drove it? The fourth question — do those units share something? — is where the answer actually lives, and almost nobody gets there. The queue does not slow investigation down. It truncates it.
"Can it answer this on our schema, not a demo one?"
That is the correct question, and the honest answer is that it depends on the schema. Published text-to-SQL results fall off sharply between clean academic databases and real warehouses with hundreds of tables, ambiguous column names and no referential integrity. Everyone building in this space is subject to the same physics. What differs is whether they tell you.
How we approach it
Read-only, on your infrastructure. Connections are opened read-only and every query executes inside a time-bounded transaction. Nothing is copied out, nothing is written back.
Document the schema before trusting the model with it. A column named flag7 means something to the person who created it in 2014 and nothing to anyone else. The semantic layer — table meanings, usable columns, the organisation’s agreed definition of “active customer” — is where the accuracy comes from. Language modelling on top of an undocumented warehouse is theatre.
Check the answer on your schema. The documented schema layer and read-only execution are useful controls. A complete answer-to-source citation chain is not yet available, so the data team must compare material findings with approved reports and source data before anyone signs a decision.
Compute, do not narrate. Numbers that appear in a chart come from executing code against a result set. A model that writes a number into a sentence is guessing at arithmetic, and the fact that it is usually right is exactly what makes it dangerous.
What you get
Connections to the systems you already run. A documented schema layer you own. Read-only analysis, access controls and a written assessment of which parts of your data are ready and which still need documentation or verification.
When this is the wrong choice
- If the questions are fixed, build a dashboard. A known question asked daily by forty people is a report, and a report is cheaper, faster and more predictable.
- If the schema is undocumented, budget the documentation first. This is the single most common reason these projects disappoint. No model repairs a warehouse nobody can explain.
- If the organisation has not agreed what the metric means, the disagreement is about the definition, and no tool settles that argument. It usually surfaces in week one, which is at least useful.
- If you need writes — approvals, corrections, workflow — this is the wrong layer entirely. Read-only is a design decision, not a limitation we intend to remove.
- If the number goes to a regulator, a person owns it. The system shortens the path to the evidence; it does not sign the filing.