A data intelligence chatbot: query enterprise databases in plain language

A data intelligence chatbot that lets every business user query enterprise databases in natural language: no SQL, no analysts, no waiting.

The data is there. The access isn't.

Enterprise databases already hold the answers to most business-critical questions. The real barrier is access. Getting meaningful output requires SQL proficiency, schema knowledge, and an understanding of the business rules that govern how data should be interpreted.

For most business users that barrier is insurmountable without help. Questions queue up, analysts get pulled into low-value query work, and decisions stall, waiting on data that already exists.

A question that should take ten seconds ends up taking two days.

A conversational layer over your database

The NL2SQL data intelligence chatbot places a natural language interface directly in front of the database. A user types a question; the system works out what they are asking, identifies the relevant data, generates and executes the correct query, and returns a clean, formatted result, with a chart if the data calls for one, and three suggested follow-up questions to guide further exploration.

Every query is governed by the organisation's own business logic, applied consistently regardless of how the question is phrased or who is asking.

How it works: the pipeline, step by step

1. Intent classification. Is the user asking for a data lookup, a comparison, a trend, or a chart? The system classifies intent first to route the query correctly.
2. Filter grounding. Ambiguous terms and filter values are resolved against actual database values using semantic search before any SQL is generated.
3. Table identification. Relevant tables are identified using a lightweight catalogue of plain-English descriptions; only one to three tables are passed forward, not the full schema.
4. SQL generation. A query is generated using the full schema detail of the selected tables, with all business rules applied automatically from configuration.
5. Secure execution. The query runs in strict read-only mode. Write operations are blocked at multiple layers before anything reaches the database.
6. Result and follow-up. Results are returned as formatted tables with CSV download and inline charts, plus three contextual follow-up suggestions.

Design decisions that stay smart at scale

Two-layer metadata. A lightweight catalogue routes questions to the relevant tables. Rich metadata (column definitions, synonyms and formulas) is loaded only for the selected tables, keeping every stage focused. Feeding an entire schema into every prompt does not survive a real warehouse.

Business logic as configuration. All data rules (unit conventions, hierarchies, metric formulas, null handling) are encoded in configuration files, not left to the model to infer differently each time. Domain experts update them without code changes, and the effect is instant.

Filter grounding. Natural language terms are resolved to canonical database values via semantic search before any SQL is built, so queries run on verified values, not assumptions.

Intent classification. Factual lookups, year-on-year comparisons, trend analysis and chart requests are each handled by a different pipeline branch, invoked automatically.

Triple-layer security. Data safety doesn't rely on a single control. The path to the database is read-only by construction, enforced three times over:

• Connection level: database access is permanently restricted to read-only mode.
• Instruction level: the model is explicitly instructed to generate only read-based SQL.
• Execution level: every query is scanned for CREATE, INSERT, UPDATE, DELETE and TRUNCATE before it runs.

The difference: traditional access vs. NL2SQL

On the chatbot side, the rest follows from the same design: business rules are encoded once and applied to every query; visualisation is automatic and rendered inline; follow-up questions are suggested as clickable cards; and a change to the business logic is a configuration edit that takes effect instantly.

Where it applies: domain-agnostic by design

The chatbot works with any well-structured relational database. The core system stays the same across deployments; only the metadata catalogue and the business logic configuration are adapted to the target domain. Anywhere a warehouse holds answers that only a handful of people can extract, the same pattern applies.