For years, SQL has powered dashboards, reporting, Tableau environments, and business intelligence. That existing work contains something valuable: the definitions, filters, joins, and calculations an organization already uses to understand its business.
Text-to-SQL becomes useful when an agent can work with that context. A question in natural language still needs to resolve to the right data and the right business logic.
Semantic data models and semantic views can make those definitions explicit. A useful starting point is to agree on what each metric means, which records it includes, and how the business expects it to be calculated.
A representative question is: "What was our biggest sale in the past month?"
That sounds simple, but the agent needs to know what counts as a sale, which amount to compare, and which date range the question means. "Past month" might mean the previous calendar month or a rolling period. The semantic definitions and the conversation need to resolve that ambiguity.
The 5-Step Blueprint
Step 1: Start With the Data Models
Before generating SQL, establish which tables and models answer the business questions. Understand their grain, the relevant fields, and how their records relate.
When an agent and an existing report draw from the same underlying tables, the report's logic can provide a useful validation reference. Sharing tables does not automatically mean the answers will match.
A join, filter, or metric calculation can change a result substantially. The model needs the meaning of the data, not just a list of column names.
Step 2: Define the Semantic Layer
Semantic definitions and YAML-based configuration can describe what the agent should work with:
- Metrics and their business definitions
- Dimensions and filters
- Relationships between the models
- Join requirements
- Custom instructions for interpreting questions
- Verified questions paired with validated SQL
The file is a maintained description of the business context. If that context is incomplete or inconsistent, the agent has more room to choose the wrong logic.
There is a useful terminology distinction: a Snowflake semantic view is a schema-level object; YAML is one way to define it. Legacy semantic-model YAML files are a related configuration format. See Snowflake's semantic-view YAML specification.
The purpose of this layer is to make the business meaning explicit and reusable.
Step 3: Enforce Governance
The agent should operate within the access granted to the application and the user. Instructions can describe those limits, while database roles, permissions, and execution controls enforce them.
For a question-answering workflow, a read-only execution path and a defined set of permitted data sources provide a clearer starting point than unrestricted database access. Sensitive fields and customer-level data need the same access boundaries they would have outside an AI conversation.
The agent should also ask when a business term or relationship is unclear. Guessing can produce SQL that runs successfully and still answers the wrong question.
Step 4: Validate Against Existing Reports
Compare generated results with a trusted report or an independently checked query against source data. Agree on acceptance criteria for the metric and use the same time window, filters, and level of detail on both sides.
If the results differ, inspect the calculations, joins, and filters behind the reference report. Then trace the generated SQL to identify which part of that logic is missing or different.
Correct the cause and repeat the comparison. A matching total is only useful when both queries answer the same business question; adjusting the output until it looks close is not validation.
That validation matters because a plausible answer is easy to accept. A trusted answer needs evidence that it represents the same business question under the same conditions.
Step 5: Save Verified Queries and Keep Improving
When a question produces validated SQL, save the question-and-SQL pair as a verified example. That gives the agent a checked reference pattern for similar requests.
Snowflake's Verified Query Repository documentation describes this use of example questions and corresponding SQL to improve Cortex Analyst's accuracy.
A verified query is a reference pattern, not a cached answer that makes every future request correct. Data changes, definitions change, and a similar-looking question may use different filters. New results still need an appropriate level of checking.
The feedback loop should update the semantic definitions, instructions, and verified examples when a recurring misunderstanding appears.
Measuring Whether It Helps
Track answer quality, the questions that still need analyst review, and the effort required to maintain the semantic definitions. Compare results under consistent conditions before making claims about accuracy or time saved.
An evaluation should include ambiguous questions, missing data, and requests outside the agent's supported scope. The agent should ask for clarification or explain a limitation when a reliable answer is unavailable.
The Broader Principle
SQL continues to be central to this work. The valuable business logic often already exists in reports and stored procedures.
The engineering challenge is to expose that meaning through good models, clear semantic definitions, controlled access, and repeatable validation. That is what turns a natural-language interface into a useful way to explore business data.