Text to SQL with visible query execution

Text-to-SQL can let a manager ask a data question in ordinary language. It also creates a dangerous shortcut when a model can see the whole warehouse, choose an unapproved definition, or run a write operation.

Expose a narrow catalogue of read-only business questions only when the team can own each metric definition. The first release needs approved data, visible execution, and a clear owner.

Restrict the question to approved data

Start with a question catalogue. Each entry should name the measure, period, dimensions, permitted filters, source view, freshness, owner, and examples of requests that belong outside the catalogue.

Expose purpose-built views rather than the entire warehouse. A view can hide operational fields, standardise joins, and make access decisions easier to review. The model can then generate SQL against a surface designed for reporting.

Use a closed answer schema with fields such as:

• result and unit;
• metric definition;
• period and filters;
• source view and freshness;
• executed SQL;
• access scope; and
• refusal reason when the request cannot be answered.

The schema makes omissions visible. It does not turn an undefined metric into a valid one.

Show the query beside the result

The interface should show the executed SQL, metric definition, filters, period, and source timestamp beside the result. A reviewer can inspect the query, while the data owner can check whether the definition matches the business policy.

Visible SQL supports review. It does not by itself establish business correctness. A syntactically valid query can still calculate the wrong measure, use a stale view, or answer a different question from the one the user intended.

Keep a link to the data catalogue and a way to report a wrong result. Store the model and prompt version only as much as the organisation's retention policy allows, and avoid placing unnecessary personal data in logs.

Define metrics before exposing them

A measure such as revenue or active customer can have several valid definitions. The data owner should approve one definition for the catalogue, including exclusions, currency, timezone, and refresh schedule where those details matter.

If finance and sales use different meanings, present both as separate named measures. A model should not resolve a policy disagreement by choosing whichever description resembles the question most closely.

Keep the first catalogue small. A few recurring questions reveal whether self-service helps and limit the number of views and tests the data team must maintain.

Keep writes technically impossible

Use a separate database role with no write privileges. Add a validator that rejects multiple statements, data-definition commands, comments, unapproved relations, system functions, and other operations outside the reporting grammar. Apply a row limit and timeout appropriate to the warehouse.

The database permission is the final enforcement point. Prompt instructions can explain the scope to the model, but they should not be the only control. Review the PostgreSQL row-security documentation when row-level access forms part of the design.

If users need to change a record, create a separate command workflow. It should validate the requested fields, show the proposed change, require approval, and keep a record of the result.

Test answers and refusals

Build a reviewed set with:

• valid paraphrases of approved questions;
• date boundaries and timezone cases;
• ambiguous terms and missing filters;
• stale or delayed source data;
• attempts to access an unapproved view;
• attempts to write or run multiple statements; and
• questions that should be refused or routed to an analyst.

Evaluate measure choice, filters, period, result against a reference query, source freshness, access enforcement, and refusal behavior separately. NIST's AI Risk Management Framework recommends documented test sets, measures, and monitoring before and during operation.

Review the test set when a view, metric definition, parser, model, or access policy changes. Keep a data owner involved in the sign-off.

Extend the catalogue deliberately

A new measure follows the same process as a change to a management report: an analyst approves the view, the owner documents the definition, and tests cover valid requests, ambiguity, access, and refusal. Question history can suggest demand. It cannot approve a new metric by itself.

Add joins and dimensions only after the existing questions remain stable. If users mostly ask causal or predictive questions, text-to-SQL may be the wrong layer. An analyst, semantic model, or separate forecasting workflow may be required.

Sources and next decision

The NIST AI RMF Core provides a useful framework for governing, measuring, and monitoring an AI system. For a business-specific scope, bring recurring questions, view definitions, roles, and freshness requirements to a process scan.

FAQ

Should the model see raw tables? Keep it on approved views where possible. Raw warehouse access expands the data, definition, and permission surface before the team has tests for it.

Is a read-only role enough? It prevents writes through that connection. It does not solve wrong definitions, excessive data access, stale sources, or unsafe handling of results.

What should an out-of-scope request return? A clear refusal with the reason and an owner or route for a new question. Do not fabricate a number to make the interface look complete.

Sources

• PostgreSQL: Row Security Policies
• NIST AI Risk Management Framework 1.0