This is Part 2 of a two-part technical series. Part 1 showed how an Enterprise Data Discovery Assistant recovers legacy logic and produces grounded SQL. Rupak's article on AI-ready data products provides the larger context: agents need machine-readable semantics, active contracts, and engineering guardrails. This post follows the next step—from a business question to governed execution and an explained answer.
All names, identifiers, queries, and results below are synthetic. Quantities are rounded to communicate scale without publishing an internal inventory.
Natural language does not remove the need for data modeling. It makes good data modeling visible to more people.
Our preview tests asked whether business users could explore an enterprise-scale Customer 360 domain—more than 100 million records across multiple curated tables—without first learning schemas, joins, or SQL.
The answer was encouraging, with an important qualification: natural language is the interface, not the semantic layer.
One question hides several decisions
Consider a straightforward request:
Which customer segments had the highest order value last quarter, and how did that change from the previous quarter?
Before SQL can run, the system must resolve what order value means, which field represents customer segment, how orders relate to customers, which calendar defines last quarter, whether the user is allowed to see the requested data—and whether the data product is trustworthy right now.
A language model looking only at table and column names may guess. A semantic view makes the analytical decisions explicit: grain, metrics, time semantics, filters, and supported relationships. Snowflake policies determine who may access the result, while our runtime contract check determines whether the data product is fit to use now.
It defines:
- Logical tables, row grain, primary keys, and unique keys, so the meaning of one row is explicit.
- Dimensions and time dimensions, such as customer segment and fiscal quarter.
- Facts and governed metrics, including aggregation and distinct-count behavior.
- Relationships, including bridge tables for many-to-many associations, so join paths are modeled rather than improvised.
- Filters, synonyms, and question-handling instructions.
- Verified queries, which pair important question patterns with reviewed SQL.
Snowflake recommends semantic views for new Cortex Analyst implementations. They are schema-level objects integrated with Snowflake privileges and metadata—not prompt text pretending to be governance.
A semantic view tells the assistant what the data means. A data contract tells it whether that data product is fit to use now.
For governed business questions in our preview, the assistant performs a mandatory contract check before using the analytical semantic view. It evaluates the target domain's contract health, freshness, latest validation result, and any failure reason.
The contract check is application logic around the agent; it is not performed automatically by the semantic view itself.
From question to governed answer
The flow is deliberately simple:
- The Enterprise Data Assistant identifies the user's intent and target business domain.
- A data-contract check evaluates contract status, freshness, quality, and the latest validation outcome before the business query runs.
- The contract result determines the response path: proceed normally when trustworthy, or attach the appropriate warning when the data is degraded, stale, inactive, or failed.
- Cortex Analyst interprets the question using the selected semantic view, which supplies the governed dimensions, metrics, relationships, filters, and examples needed to generate SQL.
- The SQL runs inside the governed data platform. Snowflake privileges and data-protection policies still apply.
- The response returns the result together with the SQL, definitions, scope, and any required warning.
The distinction matters. When the contract is active, fresh, and passing, the check stays behind the scenes and the user gets a clean answer. A stale or degraded contract adds a caution. An inactive or failed contract produces a prominent warning that the result is not guaranteed before the preview attempts the query. For a higher-risk domain, the same decision point can be implemented as a hard stop.
Cortex Agents can use Cortex Analyst for structured data and route across multiple semantic views. Cortex Analyst first attempts semantic SQL, where metrics, dimensions, and relationships come from the semantic view. When the modeled coverage cannot satisfy a request, Routing Mode can fall back to standard SQL on physical tables. That flexibility is useful, but for governed metrics the fallback should be treated as a different confidence path: expose it for review, request clarification, or block it for higher-risk questions rather than imply that it carries the same semantic guarantees. Snowflake documents this behavior as Routing Mode.
The answer should show its work
The experience should still feel conversational. The difference is that the answer exposes enough evidence for a user or engineer to challenge it.
Synthetic demonstration: no production interface or customer data is shown.
For the example above, the response contract is more important than the visual polish. It should make six things clear:
| What the user sees | Why it matters |
|---|---|
| A concise answer | The user gets the result without reading SQL first. |
| Metric and dimension definitions | Business terms are not left open to interpretation. |
| Time range and filters | The scope of the answer is explicit. |
| Contract warning, when relevant | Users know when freshness or quality may affect trust. |
| Generated SQL | An engineer can inspect and reproduce the query. |
| Warnings or clarification | Ambiguity is surfaced instead of silently resolved. |
That is a more useful standard than “the chatbot returned an answer.”
Accuracy is an engineering loop
Semantic metadata improves grounding, but it does not prove that every generated query is correct.
Important question patterns should be captured in a Verified Query Repository: a natural-language question paired with SQL whose logic and result have been validated by a qualified reviewer. The SQL should use the logical tables and columns defined by the semantic view rather than bypassing them for physical objects. Cortex Analyst can use relevant verified queries to guide similar requests. A verified example is guidance—not a blanket certification of every future answer. Snowflake's Verified Query Repository documentation makes that distinction concrete.
The next layer is repeatable evaluation. Current Cortex Analyst evaluations compare generated SQL results with selected verified queries, track regressions, and record latency. This turns semantic-layer tuning into a measurable build-test-run-improve cycle instead of a collection of impressive demos. Snowflake documents the evaluation workflow here.
We also learned to compare results, not only SQL. Reconciliation must use the same as-of timestamp, fiscal calendar, currency logic, exclusion rules, and entity scope. Two syntactically valid queries can still answer different business questions.
Our practical checklist is:
- Start with a narrow, coherent business domain.
- Define grain, keys, relationship cardinality, metrics, filters, and synonyms explicitly.
- Add reviewed queries for high-value and high-risk questions.
- Test ambiguous wording, invalid requests, boundary cases, and every contract state—not only the happy path.
- Track accuracy, regression, latency, and workload cost with representative questions.
- Show the generated SQL and scope when the audience needs traceability.
Governance does not disappear behind chat
A conversational interface must not become a shortcut around access controls.
Access control and data contracts answer different questions. Privileges determine whether this user may access the data. The contract check determines whether the selected data product should be trusted in its current state. A governed assistant needs both decisions; neither replaces the other.
Semantic views participate in Snowflake's privilege model. Row-access and masking policies applied to underlying tables can propagate to the semantic view and remain enforced. One subtle but important caution from Snowflake's guidance is that sample values stored as semantic metadata are not masked, so sensitive examples should not be embedded there. See Snowflake's development and deployment guidance.
There are product boundaries too. Cortex Analyst is designed for questions that can be resolved with SQL; it is not automatically a general business-insight engine. It also cannot refer to the results of a previous SQL query as if it had retained that result set. Those limits should shape both the user experience and the test suite. The current limitations are documented here.
What changed between Part 1 and Part 2
Part 1 recovered the knowledge needed to rebuild a data product: joins, filters, calculations, ownership, and dependencies.
Part 2 makes approved knowledge queryable:
Recovered legacy knowledge
↓
Governed data product + semantic view + contract
↓
Natural-language question
↓
Data-contract decision
↓
Semantic grounding + governed SQL
↓
Explained result
The language model is useful at the top of this stack because the hard decisions are represented beneath it.
That is the larger lesson from the preview. Natural-language analytics is not a replacement for engineering discipline. Done well, it is a new interface to that discipline—one that lets more people ask useful questions while keeping definitions, access, SQL, and validation visible.
Top comments (0)