Most “ask your data a question” pitches fall over on the first real objection: what does the model actually see? If the answer is “all of it,” you’ve just built a very fast way to leak sensitive records to whoever phrases a prompt cleverly enough. That objection is why most organisations still run reporting through an analyst queue instead of a query box — the queue is slow, but at least it’s accountable.
We built a query layer that removes the queue without removing the accountability.
The point of improvement
The organisation’s reporting process looked like this: someone wants a number, they file a request, an analyst writes a query against the underlying schema, checks it, runs it, formats it, sends it back. Multiply that by every department that needs a monthly figure and you get a queue that’s permanently a few days behind whoever’s asking.
The number nobody had was: how long does a routine reporting request actually take, start to finish? Once we measured it, the number was ugly — and it’s the number the 90% reduction is measured against.
What we built instead
Three things had to be true simultaneously for this to be safe to ship, not just fast:
- Schema-aware, not data-aware. The model is trained on the structure of the organisation’s data — table names, relationships, column meanings — never on the underlying records themselves. It knows what a customer record looks like without ever having read one.
- RBAC-secured at the query layer, not the UI layer. Every generated query is executed under the same role-based permissions the user already has in the source system. A user who couldn’t see a table before can’t see it through the query layer either — the natural-language interface doesn’t create a new permission surface. The existing ORM is used.
- Answers, not dashboards. The output is a direct answer to the question asked, not a new dashboard someone has to learn to read. Ask “what were refunds by region last quarter,” get that number, not a BI tool you now have to maintain.
The number, and how we’d defend it
90% is the reduction in time between “someone needs a routine reporting answer” and “someone has it,” measured before and after go-live on the same class of requests. It’s not a projection — it’s a before/after on live usage.
If you’re the kind of buyer who’s going to ask “how do you know that,” good — that’s exactly the right question, and we’d rather you ask us than take the number on faith.
If your organisation’s reporting still runs through a queue, that’s usually not because the queue is the best option — it’s because the alternative felt too risky to build safely. That’s the actual problem worth solving.