Why Direct Text-to-SQL Hits a Governance Wall

Text-to-SQL has become very good at producing SQL. That success makes the next failure harder to see.

A failed query stops. A valid query built on the wrong business interpretation can travel all the way into a decision.

The distinction matters because a question such as “Which stores are losing regular customers?” contains choices that SQL cannot settle on its own. What counts as regular? Losing compared with which period? Are new stores included? The generated query can be valid while implementing an interpretation nobody intended.

The issue is not model intelligence. It is the absence of an inspectable representation between the question and the query.

A counterpoint to the Bitter Lesson

Rich Sutton’s “The Bitter Lesson” argues that general methods that scale with computation ultimately outperform approaches built around human knowledge. It is an important warning against encoding brittle expert rules into the learning method.

Our counterpoint is narrower: general methods still operate inside a representation of the problem. Chess search operates over legal moves and board states. Language models operate over tokens. In business analytics, the missing representation is often the intended analysis: metric, population, comparison, grain, filters, and material assumptions.

That is our claim, not Sutton’s.

SQL is execution, not agreement

SQL is good at specifying how to compute an answer. It is a poor interface for agreeing on what the business question means.

Consider “year-over-year sales growth in the Northeast.” A query needs to bind at least:

• the approved sales calculation;
• the definition of Northeast;
• fiscal or calendar periods;
• same-store or all-store population;
• absolute or percentage change;
• any currency or return treatment.

A strong model can choose plausible values for each. The governance question is whether those choices came from approved context, whether unresolved choices were surfaced, and whether a reviewer can see the intended analysis before the number appears.

Showing SQL after generation helps an engineer inspect implementation. It does not give a business reviewer a practical way to validate the interpretation.

Retrieval helps, but it does not make the decision

More schema, query history, documentation, and examples can improve generation. Anthropic’s account of its internal analytics system describes a large corpus of SQL and substantial context engineering around the model. That is evidence for the system around the engine, not for direct generation without structure.

Retrieval can reveal two approved definitions of “active customer.” It cannot decide which one the current meeting intends unless a policy or phrase resolves the choice. At that point the system should show the ambiguity and ask—not silently rank one definition above the other.

Put an inspectable object in the middle

Our design choice is to turn the question into a visible analysis plan before SQL executes. Available business and schema context grounds the plan. When unresolved business meaning could materially change the analysis, Spotonix asks and waits for clarification. In Copilot mode, the user then accepts the plan before query generation continues.

Query generation currently uses both the original question and the plan. The resulting SQL is checked against material bindings in the accepted plan before execution.

That boundary matters. We are not claiming a fixed plan-to-query compiler, identical SQL across runs, or that a plan makes mistakes impossible. We are claiming that the business interpretation becomes visible and reviewable before execution, and that the query can be checked against it.

The wall is governance, not generation

Better models will keep improving SQL generation. That is good. But generation alone does not answer the questions a production buyer should ask:

• Which business interpretation did the system choose?
• Which source authorized each material choice?
• Where did it ask instead of infer?
• Can I inspect the plan and the query that ran?
• What happens when the structured path cannot safely commit?

Direct text-to-SQL hits a wall when the organization needs to govern the answer rather than admire the query. The way through is not a less capable model. It is a review point where people can see what the question means before the model turns that meaning into code.

See the interpretation before execution: how Spotonix works · try the demo