Natural-language analytics
Ask a question in plain language and get an answer with the query that produced it — over the databases you already run, read-only, on your own infrastructure.
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.
Show the working. The answer arrives with the query that produced it, the tables it touched, and the definition it applied. That is not a trust feature for the executive. It is what lets the data team confirm the thing is right, and it is what makes the answer usable in a decision anyone has to sign.
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 semantic layer you own. Answers with their queries attached. Permissions and an audit trail. And a written assessment of which parts of your data are ready and which are not.
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.