Snowflake built its roots and reputation as a power data warehouse. Working with large sums of structured data and semi structured data is a breeze in Snowflake. With the push toward AI BI, constructing Snowflake semantic layer makes sense, if you have the right process and governance structure in place.
LLMs and advancements in AI have shifted who and how data turns into actional information within a typical enterpise. Data storytelling, data exploration, and using descriptive statistics is in the hands of anyone with access to Claude. In fact our opinion is Claude has reached a level up to par with professional analysts and data scientists.
Semantics Originate with BI: Building Snowflake Semantic Views
No company is starting their semantic layer discovery and execution with a blank canvas. Tableau and Power BI operate more than a quarter of the entire Business Intelligence landscape. Business and data semantics converge within your BI platform, so it only makes sense to inherit metrics, filters and other critical inputs that truly define the last mile of business understanding. A semantic layer built purely on top of a database with no context to business delivery more likely to fail when it reaches AI / BI tools that ultimately consume data. Snowflake natively consumes published data and table relationships.
Refining a Semantic Layer with Analyst –
This is the stage where you get out what you put in… Rarely if ever does the data warehouse, semantic layer, and labeling of BI reports / dashboards align. This is your opportunity to course correct and set yourself up for success, if you are using AI to either build BI assets or use AI directly to analyze your data.
Recommendations
- Teams that treat the semantic layer as a database labeling exercise are setup to fail.
- Do not connect AI directly to Snowflake semantic layers without validating existing BI use cases and results
- Engage BI builders and analysts with domain expertise to test, validate and lend data context.
- Do not blindly use “AI” to inference meaning and definitions if you do not know them.
This phase is where subject matter expertise is just as important as technical competency. Snowflake has taken the correct route to align queries to business questions. Rather than looking at code and meta data and and making up questions, Snowflake will at least scan real queries executed before it makes up questions. Most of them are basic, and that is by design.
The difference between a functional agent and a truly useful agent conceptually is the depth and richness of your semantic layer.
Verified Queries and Log Monitoring
When you build business intelligence, you have something to ground yourself during data validation and user acceptance testing. Snowflake has taken the correct route to align queries to business questions. Rather than looking at code and making up questions, Snowflake will scan your query history.
Inferencing Semantic Views Risky
Inference based semantics feels magical as a creator to establish depth and meaning behind your data. The idea of having “something is better than nothing” does not play out when it’s time for asking questions of your data. That can turn to semantic disconnects in your organization when AI observed meaning does not translate to business alignment and understanding. This is one of the AI / BI risks that we highlight and often cross train SMEs and analysts to get involved while building and administrating Snowflake semantic layers.
Adding depth with Tags
One of our original gripes with the Snowflake semantic layer was the lack of depth in meta data, which directly conflicts with the patterns we have found most successful with AI to remove ambiguity and deliver contextual depth needed to accurately translate business questions to the right metrics and attributes. Building one semantic view for a single topic makes for a great demo. When you have hundreds of marts across 5 lines of business, you need tags for reconciling semantic disconnects.
Activating your Snowflake Semantic Layer with AI
Once you have your Semantic layer built, you can connect directly from your BI platform, build Snowflake agents, or connect Claude to Snowflake directly. The benefit is the layer of context to help convert plain English questions to the underlying queries. This is where Snowflake’s “verified” queries and monitoring capabilities make a huge leap over direct AI to SQL and legacy BI reporting and dashboard semantic layers. We are working on formal eval results to highlight the lift in applying Snowflake Semantic layer and Snowflake Agents as an interface.
3 Tips for Planning your Snowflake Semantic Layer
- Snowflake Cortex Analyst is a an amazing feature. The architecture is sound and the direction is right. But the difference between a functional agent and a truly useful one is not the platform and tools. It is the depth and richness of the semantic layer behind it.
- Semantics do not originate in a database. They originate in the BI tools your business has relied on for years. Inheriting that context, validating it against real query history, and extending it with tags and analyst input is not optional work. It is the most important work to build production grade semantic models.
- The teams that treat this as a labeling exercise will get labeling results. The teams that bring domain expertise, validate against existing BI, and close the gap between database definitions and business understanding will build something truly useful.
