What Are Snowflake Semantic Views & Cortex Analyst?

A Snowflake semantic view is a native Snowflake object that defines the business meaning of your data --- the metrics, relationships, and vocabulary --- on top of physical tables, so that Cortex Analyst can answer plain-English questions with accurate, governed SQL. Cortex Analyst is Snowflake's managed text-to-SQL service: a user asks "what was net revenue by region last quarter?" and Analyst returns the right number. The semantic view is what makes that possible --- it is the layer that tells the AI what "net revenue" means, how the tables join, and which phrasings map to which columns.

Semantic views and Cortex Analyst matter because they solve the central failure mode of natural-language analytics. A language model pointed at raw tables can write SQL that runs and returns a number that is simply wrong --- it guessed the join, or summed the wrong column, or used a metric definition nobody agreed to. By forcing Analyst to read a curated semantic layer instead of raw schema, Snowflake replaces "plausible SQL" with "governed SQL." The accuracy of the answer moves from the model's guess to a definition a human approved.

Semantic Views Defined

A semantic view is a first-class schema object in Snowflake --- created and managed like a table or view --- that captures the semantic model of a business area. Where a regular SQL view is just a saved query, a semantic view is a structured description of meaning: it names the logical entities, declares how they relate, and defines the measures analysts care about, in business terms rather than column references.

Snowflake recommends semantic views over older approaches (such as semantic model YAML files staged in a directory) for Cortex Analyst, because as native objects they carry governance natively: role-based access control applies to the view itself, so a semantic view is not just a query convenience but a governed asset. In practice, a semantic view behaves like a data product --- a packaged, owned, governed unit of meaning that consumers (human or AI) read from.

How Cortex Analyst Uses Semantic Views

The chain that produces every Cortex Analyst answer is deliberately consistent and traceable: the user asks a question, Analyst maps it onto the semantic view, the view resolves to SQL against the underlying tables, and the result returns as a governed answer.

What a Semantic View Contains

A semantic view encodes the layers of meaning that raw schema leaves implicit. The richer and more accurate these definitions, the better Cortex Analyst performs.

• Logical tables --- Business entities (customers, orders, regions) mapped to the underlying physical tables.
• Relationships and join paths --- How entities connect, so Analyst never has to guess which key joins to which --- the single most common source of wrong text-to-SQL answers.
• Facts and dimensions --- The measurable values and the attributes you slice them by.
• Metrics --- Named, defined business measures ("net revenue = gross revenue minus returns and discounts"). This is the heart of the semantic view: the agreed calculation, not a per-query reinvention.
• Synonyms --- The different ways people phrase the same thing ("revenue", "sales", "turnover" all map to one metric), so natural-language questions resolve reliably.
• Verified query examples --- Sample question-to-SQL pairs that ground Analyst's behavior on known-good patterns.

None of this is exotic --- it is the same business logic a semantic layer has always carried. What is new is that it lives as a governed Snowflake object that an AI service reads directly.

Open Semantic Interchange (OSI)

Semantic definitions have historically been locked inside whichever tool created them --- a BI tool's model, a transformation layer's metrics, a warehouse's views --- forcing teams to rebuild the same definitions repeatedly. The Open Semantic Interchange (OSI) is an open initiative Snowflake announced in September 2025, alongside Salesforce, dbt Labs, BlackRock, and RelationalAI, to fix this. OSI defines a vendor-neutral standard for semantic models, so a definition of "net revenue" can move between tools instead of being trapped in one.

For semantic views, OSI matters in both directions. It means the metric you defined elsewhere can be imported into a Snowflake semantic view, and --- more powerfully --- a governed definition maintained in a catalog or data product can be exported as a Snowflake semantic view without hand-rebuilding it. The definitions Cortex Analyst relies on can originate from a single governed source of truth.

Governing Semantic Views with Dawiso

As soon as several departments build their own Cortex agents, the number of semantic views grows quickly --- a sales agent on pipeline and revenue views, an HR agent on headcount and payroll views, a customer-care agent on tickets and CSAT views. That scale is the real governance problem: without a map, no one can confidently answer whether the customer-care agent can reach payroll data, or which views break if a table changes.

Dawiso addresses both halves of the problem:

• Scan in for visibility. Dawiso connects to Snowflake and scans Cortex agents and their semantic views into one interactive data lineage --- the agent as a node, the semantic views feeding it, and those views connecting down to the real tables. Answering "what data can this agent see?" becomes a lookup, not an investigation.
• Generate back out via OSI. A Dawiso data product already carries the business definitions, glossary terms, and mapping a semantic view needs. Dawiso exports it through OSI to generate a governed semantic view inside Snowflake --- so the definitions an agent depends on come from a governed source rather than being rebuilt by hand.

The full workflow --- scanning agents and views into lineage, and generating governed views back into Snowflake --- is covered in Govern Snowflake Cortex Agents and Semantic Views. For the wider AI suite these views feed, see Snowflake Cortex.

Conclusion

Semantic views are the difference between Cortex Analyst guessing and Cortex Analyst knowing. They move the definition of a business metric out of each ad-hoc query and into a governed, reusable object that an AI reads directly --- and OSI keeps that definition portable rather than locked to one vendor. The technology is in place; the remaining work is governance: making sure the metrics, relationships, and synonyms inside each view reflect definitions the business has actually agreed on. Get that right, and "talk to your data" stops being a demo and becomes something you can trust.