Governed Text-to-SQL: What Enterprise Teams Should Require

That distinction matters because a query can run successfully and still answer the wrong question. It can use the wrong definition of revenue, join at the wrong grain, omit a fiscal-calendar rule, or return rows the asker should not see. Governance addresses the system around query generation—not just the fluency of the model.

What is governed text-to-SQL?

Governed text-to-SQL is a natural-language analytics workflow with enforceable controls before, during, and after SQL generation. A useful implementation typically connects six layers:

1. Scoped data sources: the system knows which databases, schemas, and tables are available for the task.
2. Business semantics: table meanings, column descriptions, metric definitions, and analysis rules give business terms an approved interpretation.
3. Query generation: the model translates the question into a query using that context.
4. Execution controls: queries run with bounded, preferably read-only access, timeouts, cancellation, and explicit result limits.
5. User-specific permissions: table and row scope follows the person asking rather than relying on a prompt instruction.
6. Review evidence: the user can inspect the SQL, returned data, relevant definitions, and audit trail.

DataFact’s public data analysis overview describes this pattern as natural language entering a semantic layer, followed by visible SQL and read-only execution. Its documentation also warns that two users in the same workspace may see different tables or rows because access depends on the connection and dataset policies. That is expected behavior in a governed system, not necessarily an error.

Governed text-to-SQL vs. basic text-to-SQL

Requirement	Basic text-to-SQL demo	Governed enterprise workflow
Business meaning	Infers from schema names	Uses maintained definitions and rules
Ambiguity	Often guesses	Can ask a clarifying question
Execution	May run whatever it generated	Uses bounded, preferably read-only execution
Permissions	Prompt instruction or shared connection	Applies user-aware table and row scope at execution
Review	Shows a prose answer	Shows SQL, results, and relevant context
Change control	Uses today’s definitions	Can preserve and compare definition versions
Auditability	Chat transcript	Retains the question, query, sources, and answer

The table is a buyer’s model, not a claim that every product uses the same architecture. Ask a vendor to demonstrate each control with your own schema and access model.

The seven controls to evaluate

1. A semantic layer that business owners can review

Raw schema labels are rarely sufficient. amt_net_3 does not tell a model whether it represents booked revenue, recognized revenue, or a post-refund amount. The system needs maintained descriptions, metric logic, relationships, and domain rules.

Ask who owns each definition, how changes are reviewed, and whether the definitions are visible outside the prompt. In DataFact, those artifacts are maintained in an analysis model and can be reviewed rule by rule.

2. Clarification instead of confident guessing

Questions such as “show margin by region” hide choices: gross or contribution margin, sales or operating region, calendar or fiscal period. A production system should identify material ambiguity and ask a targeted follow-up question.

During evaluation, include deliberately underspecified questions. A useful answer is not always a number; sometimes it is the smallest question required to avoid a wrong number.

3. Visible SQL

The generated query should not disappear behind a summary. Analysts need to inspect joins, filters, grouping, ordering, and limits. DataFact states that generated SQL is shown next to the result for review.

Visible SQL does not prove correctness. It creates a review surface where a knowledgeable person can detect an error and explain how the result was produced.

4. Bounded, read-only execution

Natural-language analytics should begin with least privilege. For an analytical assistant, read-only database credentials, per-request timeouts, cancellation, and explicit result caps reduce the operational blast radius.

DataFact documents read-only execution, request timeouts, cancellation, and stated result caps on its product page. Confirm the exact behavior in your target deployment and database.

5. Permissions applied outside the prompt

“Only show the user rows they may see” is not an access-control mechanism when it exists only as model instructions. Table and row rules should be enforced by the platform and connection context when the query executes.

A practical test uses the same question from two accounts with different regional scope. The correct outcome may be two different results. DataFact’s data-access guide explicitly notes this user-visible effect and cautions against treating an empty result as proof that no matching source rows exist.

6. Versioned definitions

If a metric definition changes, the organization needs to explain why an old report differs from a new run. Versioned analysis models make it possible to associate an answer with the definitions used at the time and compare changes later.

This is a governance requirement, not merely a convenience for developers. Finance, compliance, and operating reviews all depend on being able to reconstruct how a published number was calculated.

7. Evidence and audit history

An audit trail should connect the original question to the generated query, result, definitions, and final answer. When documents also inform the answer, citations should link to the retrieved source content.

DataFact’s documentation makes an important qualification: citations are conditional. A database-only analysis or model-only answer may not include a document citation. Even when a citation exists, a reviewer still needs to decide whether the source supports the specific claim.

A practical pilot plan

Use a small, adjudicated question set rather than an open-ended “try anything” demo.

1. Select one business domain and one governed schema.
2. Build a question set from real analyst requests, sized to cover the important intents and failure modes rather than an arbitrary target.
3. Include easy lookups, multi-table joins, ambiguous terms, empty results, restricted rows, and time-sensitive metrics.
4. Record the accepted interpretation and validation method for each question outside the model.
5. Run every question as at least two users with different access scopes where applicable.
6. Review generated SQL, numerical results, clarifications, latency, failures, and audit artifacts.
7. Re-run the set after changing a definition to test change control and reproducibility.

Do not reduce the outcome to one accuracy percentage. Track wrong-but-plausible answers, permission failures, unhelpful refusals, and cases where the system should have asked for clarification.

For a fuller scorecard, see How to Evaluate an Enterprise AI Data Analyst Before Rollout.

When governed text-to-SQL is not enough

Some business questions require a policy, contract, slide deck, or report as well as database rows. Text-to-SQL can calculate performance; it cannot discover a contractual threshold that never entered the database.

That is a multi-source problem. The system needs document retrieval that preserves source location and structured-data analysis that preserves business semantics. Read Document RAG vs. Text-to-SQL for the decision framework.

Frequently asked questions

Is text-to-SQL safe for production databases?

It can be used more safely when execution is read-only, credentials are least-privilege, requests are bounded, permissions are applied at execution, and queries remain reviewable. No model output should be treated as an access-control boundary by itself.

What makes text-to-SQL “governed”?

The defining feature is enforceable context and control around the query: approved semantics, user-specific access scope, bounded execution, visible evidence, change control, and audit history.

Does visible SQL guarantee the answer is correct?

No. Visible SQL makes review possible. Correctness still depends on the question interpretation, semantic definitions, joins, source data, execution context, and result interpretation.

Should business users see the SQL?

They may not need to read it, but analysts and owners should be able to inspect it. A business-facing explanation and a technical evidence trail serve different reviewers.

Can governed text-to-SQL answer questions across PDFs and databases?

Not alone. A cross-source question also needs document retrieval and a reasoning workflow that can compare evidence from both channels. DataFact’s public Data Agents page describes multi-source runs as a product pattern. However, the current Agent-type documentation does not list a separate multi-source creation path, so confirm configuration and availability in the intended workspace.

The buying question that matters

Do not ask only, “Can it turn this sentence into SQL?” Ask, “Can we show which definitions, permissions, query, data, and version produced this answer?”

That is the line between an impressive translation demo and an analytics system a business can defend. Explore DataFact’s approach to governed data analysis or try the public, read-only Demo.