Get the Answer Without Learning the Database

The challenge

IPSDI serves the fire service with analytics, an exposure tracker and a research programme. The data is real, the products are live, and departments value them. The institute’s problem was never the asset.

It was reach. One team carries product, sales, grants and customer success at once, and capacity is the permanent constraint. Federal payments are delayed and uncertain, which makes a revenue line the institute does not control a bad foundation to build on. The way out is a product line that sells on its own, and for that the product has to land in a single meeting.

Analytics did not land in a single meeting, for a reason that had nothing to do with the quality of the data. Getting an answer out of it meant knowing how the data was shaped: which table, which field, which filter. A fire chief has a question about exposure across their department and no reason to know any of that. Someone with schema knowledge had to sit between the question and the answer.

That is a hard ceiling rather than a slow process. Questions run into the hundreds a week, better than fifteen thousand a year. At twenty minutes each to write the query, build the chart and reply, answering them by hand is two full-time people who do nothing else. Nobody was ever going to staff that, so most of those questions went unasked and the ones that got asked became a queue.

What we built

Natural-language querying over the analytics database, running on their own tenant.

A department asks the question the way they would ask a colleague. The system works out what that means against the actual schema, runs the query, and returns the answer together with a visualisation of it. No table names, no field names, no filter syntax.

The generated query comes back with the answer rather than being hidden. That matters more here than in most places: this is fire-service data informing decisions about exposure and risk, and an answer nobody can check is an answer a chief is right to distrust. Showing the query makes the result auditable by anybody who wants to audit it, and makes a wrong question visible as a wrong question rather than as a confident wrong number.

The institute owns the platform, the code and the IP. It runs on their tenant, and AI usage is billed at cost with nothing marked up.

What changed

The demo became the product. A meeting where the prospect asks their own question and watches it answered is a different meeting from a walkthrough of somebody else’s dashboard.

Schema knowledge stopped being the gate. Fifteen thousand questions a year now resolve with no analyst in the loop. That volume was never servable by hand, which is the point: the constraint was never how fast a query ran, it was who was allowed to ask one.

Onboarding got cheaper. Self-service setup costs the team less per department, which is what makes the analytics line viable as a product rather than a service.

Why NimbleBrain

Natural language to SQL is easy to demonstrate and hard to trust, and the trust problem is the whole engagement. A system that answers confidently and wrongly against fire-service data is worse than no system, because the failure is invisible.

The query is shown for that reason, the platform runs on their tenant with their data staying theirs, and they own what was built. The engagement is structured to be stepped off at any phase boundary, with everything built to that point staying with them.