This year, many data teams have added AI agents to their roadmaps. The excitement is real: an agent that turns a two-day analysis into a two-minute conversation can change how analysts and business teams work together.<\/p>\n
But agents are only as reliable as the data foundation beneath them. Point them at raw tables or outdated metadata, and they may sound convincing while being wrong<\/strong>. This article outlines a practical framework for generating and deploying governed semantic views on Snowflake.<\/p>\n Three failure patterns show up repeatedly once agents move from demo to production:<\/p>\n All three trace back to one root cause: there\u2019s no standardized, enforced<\/em> process governing how a semantic definition gets created, reviewed, versioned, and promoted. Tooling that helps you author semantic views faster doesn\u2019t solve this by itself \u2013 speed and governance are different axes, and an organization can have plenty of one and very little of the other.<\/p>\n Ask five teams \u201cwhat is the total number of active members in Q1 2026?\u201d without a shared semantic layer, and you may get five different numbers. Each team applies its own filters, joins its own tables, and defines \u201cactive\u201d differently \u2013 and an LLM asked the same question with no grounding will hallucinate a sixth answer that sounds just as confident as the other five.<\/p>\n A semantic layer solves this by sitting between the raw warehouse and every consumer \u2013 dashboards, spreadsheets, and now AI agents \u2013 and answering three questions the same way, every time: which tables hold this data, what filters apply, and what\u2019s the aggregation logic and grain. Snowflake\u2019s own documentation frames this as addressing the mismatch between how business users describe data and how it\u2019s actually stored in database schemas \u2013 for example, defining \u201cnet revenue\u201d once, consistently, as In Snowflake, the semantic layer is implemented as a semantic view<\/strong>, a schema-level object stored directly in the database that defines business metrics and models entities and their relationships, which Cortex Analyst \u2013 Snowflake\u2019s text-to-SQL tool, can then query in natural language. Cortex Agent is the AI orchestrator that holds one or more semantic views, alongside search services and custom tools, and decides which resource answers a given question \u2013 the same architecture underpinning Snowflake CoWork(formerly Snowflake Intelligence).<\/p>\n Here\u2019s what that specification looks like filled in with a real example. Below is a semantic view over a SaaS billing dataset \u2013 two logical tables (billing and customers), joined on customer ID, with three certified revenue metrics defined once:<\/p>\n (Trimmed for readability \u2013 the full generated file includes every column comment and access modifier. <\/em>Repo<\/u><\/em><\/a> has the full semantic definition )<\/em><\/p>\n What\u2019s not in question is that this object works. What is<\/em> in question is: how does a semantic view like this get created in the first place?<\/em><\/p>\n Before the pipeline itself, it\u2019s worth being precise about the two governed inputs it depends on.<\/p>\n The core idea is simple to state: treat semantic view generation as a governed software release, not a one-off modeling exercise.<\/strong> In practice that means five components, each enforcing a rule that an informal process typically leaves optional. Before walking through each one, it helps to see the whole pipeline end to end, and then how that pipeline fits into the wider Snowflake architecture \u2013 the two diagrams below cover exactly that. <\/p>\n Zooming out one level: this pipeline is only the build-time half of the picture. Figure 2 shows how it fits alongside the systems that actually consume its output \u2013 Cortex Analyst, Cortex Agents, Snowflake Cowork, and the BI tools discussed later in this article. <\/p>\n The full code for the below components breakdown is here<\/a><\/u>.<\/p>\n An orchestration script connects to Horizon and the metric inventory and pulls, for a given domain, only certified metric formulas and tagged schema. This step is deterministic \u2013 it retrieves already-approved facts, it doesn\u2019t infer anything:<\/p>\n The process pulls schema and tag context directly from Horizon tag references.<\/p>\n This is the first structural difference from usage-inference approaches worth stating plainly: this pipeline only ever proposes definitions that trace back to a pre-approved source, rather than a definition surfaced because it was the most common pattern in someone\u2019s query history<\/strong>. Popularity is a useful discovery signal; it isn\u2019t the same claim as governance sign-off.<\/p>\n An LLM of choice (Claude, GPT, Qwen, GLM etc) converts the extracted context into a strictly formatted dbt model using the Why Agent Quality Breaks Down<\/strong><\/h2>\n
\n
What a Semantic Layer Actually Does<\/strong><\/h2>\n
SUM(gross_revenue * (1 - discount))<\/code>, rather than leaving the calculation to be reinvented in every report.<\/p>\nWhere This Lives in Snowflake<\/strong><\/h2>\n
name: SAAS_BILLING\ndescription: Combines customer records with subscription billing details\n to support certified MRR, net MRR, and churned revenue metrics.\ntables:\n - name: BILLING\n base_table: { database: FINANCE, schema: ANALYTICS, table: FCT_SAAS_BILLING }\n dimensions:\n - name: BILLING_DATE\n expr: BILLING_DATE\n data_type: DATE\n - name: PLAN_TYPE\n expr: PLAN_TYPE\n data_type: VARCHAR(20)\n facts:\n - name: MRR_AMOUNT\n expr: MRR_AMOUNT\n data_type: NUMBER(10,2)\n metrics:\n - name: TOTAL_MRR\n expr: SUM(billing.MRR_AMOUNT)\n - name: NET_MRR\n expr: SUM(billing.MRR_AMOUNT) - SUM(billing.DISCOUNT_AMOUNT)\n - name: CHURNED_REVENUE\n expr: SUM(IFF(billing.IS_ACTIVE = FALSE, billing.MRR_AMOUNT, 0))\n primary_key: { columns: [BILLING_ID] }\n - name: CUSTOMERS\n base_table: { database: FINANCE, schema: ANALYTICS, table: DIM_CUSTOMERS }\n dimensions:\n - name: COMPANY_NAME\n expr: COMPANY_NAME\n data_type: VARCHAR(100)\n - name: INDUSTRY\n expr: INDUSTRY\n data_type: VARCHAR(50)\n primary_key: { columns: [CUSTOMER_ID] }\nrelationships:\n - name: CUSTOMER_BILLING\n left_table: BILLING\n right_table: CUSTOMERS\n relationship_columns:\n - { left_column: CUSTOMER_ID, right_column: CUSTOMER_ID }<\/code><\/pre>\nThe Two Governance Pillars Behind Every Certified Metric<\/strong><\/h2>\n
\n
certification_status=\"Certified\"<\/code> tag is the green light for th at column\u2019s metadata to be used in a semantic view at all.<\/li>\nThe Framework: A Governance Harness for Semantic View Generation<\/strong><\/h2>\n
Governance Framework Flow Diagram<\/h3>\n
![\"Semantic](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/07\/image-1-hev07m.webp\")
<\/figure>\n<\/div>\nSystem architecture<\/h3>\n
![\"Governance](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/07\/image-2-hev07m.webp\")
<\/figure>\n<\/div>\ncursor.execute(f\"\"\"\n SELECT metric_name, description, expression, base_table\n FROM GOVERNANCE_DB.SEMANTICS.METRIC_INVENTORY\n WHERE certification_status=\"Certified\"\n AND base_table IN ({table_list})\n\"\"\")\nmetrics = [\n {\"metric_name\": r[0], \"description\": r[1], \"expression\": r[2], \"table\": r[3]}\n for r in cursor.fetchall()\n]<\/code><\/pre>\ncatalog_query = f\"\"\"\n WITH physical_schema AS (\n SELECT table_schema, table_name, column_name, data_type, comment AS column_description\n FROM {database}.INFORMATION_SCHEMA.COLUMNS\n WHERE table_schema IN ({schema_list}) AND table_name IN ({table_list})\n ),\n horizon_tags AS ( {real_time_tags_cte} )\n SELECT p.table_name, p.column_name, p.data_type, p.column_description, t.tag_value AS privacy_tag\n FROM physical_schema p\n LEFT JOIN horizon_tags t\n ON p.table_name = t.table_name AND p.column_name = t.column_name\n\"\"\"<\/code><\/pre>\nComponent 2 \u2013 Constrained Generation<\/strong><\/h3>\n
dbt_semantic_view<\/code> package syntax. The key control is constraint: the system prompt fixes the output schema and clause order and requires every generated field to map to a catalog or inventory entry instead of the model\u2019s own judgment. A trimmed version of the actual system prompt used in this pipeline:<\/p>\nSYSTEM_PROMPT = \"\"\"You are an expert Data Engineer building dbt semantic\nmodels for Snowflake.\n\nYou will receive a JSON context payload with:\n - metrics: certified metric definitions (metric_name, expression, table)\n - catalog: physical columns per table (table, column, data_type,\n description, tag)\n - table_descriptions: [{ table, description }] \n source table in Snowflake\n\nProduce ONE valid dbt model file using the Snowflake-Labs dbt_semantic_view\npackage. Output ONLY the raw file contents. No prose, no markdown fences,\nno preamble.\n\nRequired clauses, in this exact order, separated by newlines:\n\n {{ config(materialized='semantic_view') }}\n\n TABLES (\n
![\"Cortex](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/07\/image-3-hev07m.webp\")
<\/figure>\n<\/div>\n![\"Finance](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/07\/image-4-hev07m.webp\")
<\/figure>\n<\/div>\n![\"Snowflake](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/07\/image-5-hev07m.webp\")
<\/figure>\n<\/div>\n![\"Runtime](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/07\/image-6-hev07m.webp\")
<\/figure>\n<\/div>\n