Enterprise text-to-SQL: from a simple question to a bounded, reviewable query

Simple questions can hide competing definitions

'How much did the western branch sell this month?' could mean invoiced, collected or net-of-returns revenue. The month also depends on calendar, time zone and transaction date. Syntactically valid SQL does not resolve those choices.

The illustrative workflow starts with an approved net-sales definition and a precise interval. When two legitimate interpretations remain, ask a clarifying question. An exact-looking number and polished chart can make an incorrect interpretation more persuasive rather than more correct.

Provide a semantic data contract

Google Cloud's engineering discussion treats database context and question meaning as central text-to-SQL challenges. A table-name list does not explain invoice relationships, cancelled states, currency units or the appropriate date field.

A bounded analytical view can centralize approved names and calculations where appropriate. The data owner decides what contract is maintainable. Version that contract and include positive examples and common errors so a schema change cannot silently redefine an answer.

For more on this topic, read Data architecture for enterprise AI agents in the Liyan knowledge base.

Make the interpretation reviewable before execution

In the proposed flow, expose the metric, authorized branch, interval, unit and aggregation level before generating a query. Reviewers need a business-readable interpretation as well as SQL. Approving an interpretation is not equivalent to granting access.

Individual-level or unusually fine-grained requests may need restriction or review. Parameters extracted from a question remain untrusted input to validate. Branch and column authorization come from the application's current policy, not from the model's proposed query.

Read-only is one control, not a complete boundary

PostgreSQL documents read-only transactions and row-security policies, including exceptions involving ownership and privileged roles. Test the actual restricted execution role rather than an administrative demo connection.

These mechanisms do not establish that every query is harmless. A permitted read can still expose excessive data, consume substantial resources or call an unsuitable function. Bound accessible objects, inspect query structure and control functions and outputs. A string check for SELECT is not a complete security design.

Enforce execution budgets outside the model

PostgreSQL provides settings such as statement_timeout. Enforce time limits through the execution service rather than merely asking the model to be fast. Choose row, response-size and concurrency limits from the environment's capacity.

An aggregate sales report normally does not need every underlying invoice sent to the model. When a request exceeds budget, do not remove limits automatically. Narrow scope, queue the work or offer a suitable alternative with a traceable explanation.

Evaluate meaning, not just successful execution

Build reference questions with a business analyst, recording metric definition, data version, authorized scope and expected result. Different SQL strings can produce equally correct answers, while a query that runs successfully can double an amount through an incorrect join.

Test returns, cancelled invoices, nulls, month boundaries and forbidden branches. Score clarification and rejection behavior alongside numerical accuracy. Freeze or version evaluation data so ordinary transaction changes are not mistaken for model regressions.

Show the report's boundaries

The example's final answer should include amount, currency, precise interval, metric definition and query time. Disclose incomplete feeds or restricted coverage. Do not extrapolate an authorized branch result into a company-wide claim.

Retain execution identity, metric-contract version and data lineage for review without unnecessarily logging all sensitive rows. Separate management output, technical evidence and raw data so analysts can investigate errors without broadening distribution.

Begin with a bounded use case and a stop route

Start with a small approved metric set and restricted reads. Database writes or financial approvals are separate scenarios needing their own authority and acceptance tests. Name who approves schema and metric changes and reruns evaluation.

Deliver the semantic contract, execution role, validator rules, budgets, reference questions and failures. These are proposed design controls, not a claim that a particular Aivan connector already provides every capability. A useful text-to-SQL system makes the number explainable and its execution controllable.