# Why Enterprise AI Needs a Governed Meaning Layer: Introducing Snowflake Horizon Context > Source: > Published: 2026-06-26 04:12:49+00:00 It’s quarterly business review day. The CEO asks a straightforward question: *“What was our Q3 revenue?”* Finance reports **$142.3M** — based on recognized revenue per ASC 606, excluding deferred contracts and unbilled commitments. Sales reports **$156.8M** — based on closed-won bookings including multi-year deals recognized at signing. The new AI executive assistant, queried via Slack, returns **$149.1M** — an average it computed from two dashboards it found in the company wiki, one of which was deprecated six months ago. Three numbers. Three systems. Zero trust. This isn’t a data quality problem. The underlying data is correct in each context. This is a **context fragmentation problem** — the same term (“revenue”) carries different business meaning depending on who defined it, where it lives, and what rules govern its calculation. And here’s the uncomfortable truth: **AI doesn’t create this problem. AI amplifies it.** Large language models don’t hallucinate because they’re broken. They hallucinate because they lack the governed business context needed to resolve semantic ambiguity. When an AI agent encounters “revenue” without knowing which revenue definition applies, it makes a choice. And it makes that choice confidently, with no indication that it guessed. This article introduces **Snowflake Horizon Context** — the governed meaning layer that bridges data, analytics, and AI — and explains why it’s architecturally necessary for any enterprise deploying AI at scale. Most AI initiatives don’t fail because of model capability. They fail because of context. Specifically, three types of context failure: In a typical enterprise, business logic lives in at least six places simultaneously: ``` | Location | Example || ------------ | -------------------------------------------- || Tableau | Calculated fields defining "Active Customer" || Power BI | DAX measures for "Monthly Recurring Revenue" || dbt | Metric definitions in YAML || SQL Views | Transformation logic for "Net Revenue" || Confluence | Business glossary entries || Spreadsheets | Finance team's metric definitions | ``` Each definition is locally correct but globally inconsistent. A Tableau calculated field for churn uses a 90-day inactivity window. The dbt metric uses 60 days. The product team’s internal dashboard uses 45 days for “at-risk” customers. None are wrong — they serve different analytical purposes. But when an AI agent tries to answer *“What’s our churn rate?”*, it has no way to resolve which definition is authoritative for the question being asked. Metadata catalogs tell you that a column named rev_amt is a NUMBER(18,2) in the finance.revenue table. That's structural information. It tells you nothing about: AI needs **meaning**, not just structure. The gap between schema metadata and business meaning is where hallucinations live. Even when context exists, it’s typically passive. It sits in Confluence pages that nobody updates. It lives in business glossary tools that aren’t connected to query engines. It exists in dbt YAML files that only data engineers read. For context to be useful in an AI-native world, it must be: The difference between a catalog and a context layer is the difference between a dictionary and a native speaker. A dictionary tells you what words mean in isolation. A native speaker resolves meaning in context, with nuance, with awareness of who’s asking and why. These three terms get conflated constantly. Let’s be precise: **Metadata** answers: *What exists?* **Semantics** answers: *What does it mean?* **Context** answers: *What does it mean right now, for this consumer, with this intent?* Horizon Context operates at all three levels, but its differentiating value is at the third level — **resolving meaning in context**. This is what enables AI agents to answer “What was Q3 revenue?” correctly regardless of who asks, what tool they use, or which AI system processes the question. Horizon Context isn’t a single product. It’s an integrated architecture of components that capture, govern, and serve business context across the enterprise. Let’s walk through each component and its role in the architecture. The foundation layer. Horizon Catalog is the unified metadata repository that stores not just schema metadata but **semantic metadata** — business definitions, ownership, certification status, lineage, classification, and usage patterns. Think of it as the system of record for “what exists and what it means.” Unlike traditional catalogs that passively store descriptions, Horizon Catalog actively serves context to downstream consumers. When Universal Search indexes assets, when Contextual Computing resolves a business question, when an AI agent needs to understand a table — Horizon Catalog provides the authoritative answer. Connectors ingest metadata from external systems. They don’t move data — they capture context. A Tableau connector ingests workbook definitions, calculated fields, data source configurations, and usage statistics. A dbt connector ingests model definitions, metric YAML, test results, and documentation. The key insight: connectors capture **business logic that would otherwise be invisible to Snowflake**. A Tableau calculated field that defines “Active Customer” as “last login within 30 days” is a business rule. Without the connector, that rule exists only in Tableau — invisible to AI agents, invisible to governance, invisible to anyone who doesn’t open that specific workbook. Snowflake’s OpenLineage integration captures cross-platform data lineage. This is critical for answering questions like: *“Where does this number come from?”* and *“What breaks if I change this table?”* When a dbt model transforms raw Salesforce data, passes it through staging models, lands in a mart table, gets consumed by a Semantic View, and surfaces in both a Tableau dashboard and an AI agent — OpenLineage stitches that full path together into a navigable graph. OSI is the interchange format that enables semantic definitions to flow between systems. It defines a standard schema for business metrics, dimensions, relationships, and rules that any compliant tool can consume. This is how Snowflake avoids becoming yet another proprietary semantic silo — OSI ensures portability and interoperability. The implementation layer. Semantic Views are governed, versioned, queryable semantic definitions that live in Snowflake. Unlike traditional database views (which define *how* to transform data), Semantic Views define *what* data means — including metrics, dimensions, relationships, time grains, and access policies. Semantic Views are the single most important component for AI trust. They’re what Contextual Computing reads when resolving a business question. They’re what Cortex Agents query when answering users. They’re the authoritative source of business meaning. We cover implementation in depth in Part 2. The authoring and management environment for Semantic Views. Semantic Studio provides a visual interface for defining metrics, validating semantic models, testing queries against real data, and promoting definitions through governance workflows. The discovery layer. Universal Search indexes all catalog metadata, semantic definitions, documentation, and lineage — making it searchable by humans and AI agents alike. When Contextual Computing needs to resolve *“What does churn mean in our company?”*, Universal Search finds the certified definition without requiring anyone to specify where to look. The AI orchestration engine. When a Cortex Agent or external AI system needs to answer a business question, Contextual Computing handles the hard part: resolving which semantic definitions apply, constructing a governed query, executing it with appropriate access controls, and returning the answer with full provenance. Contextual Computing doesn’t generate SQL from scratch. It **resolves context, then generates SQL from governed semantic definitions**. This is the difference between an AI that guesses and an AI that knows. Model Context Protocol (MCP) integration allows external AI systems — Claude, GPT, custom agents — to access Horizon Context through a standardized protocol. MCP servers expose semantic views, catalog metadata, and query capabilities as tools that any MCP-compatible client can consume. This is architecturally significant: it means the governed context layer isn’t locked to Snowflake’s AI products. Any AI system that speaks MCP gets the same trusted context, the same certified definitions, the same access controls. Several design principles underpin Horizon Context that are worth making explicit: **1. Context lives with the data, not with the consumer.** Business definitions aren’t stored in Tableau, Power BI, or ChatGPT. They live in Snowflake, governed centrally, consumed universally. This eliminates definition drift at the source. **2. AI queries through semantics, never through raw schema.** AI agents don’t get direct SQL access to tables. They get access to Semantic Views — which embed the business rules, access policies, and metric definitions that make answers trustworthy. **3. Governance applies at the meaning layer, not just the access layer.** It’s not enough to control who can see data. You must control who can define what data means. Metric certification, semantic ownership, and change management are first-class governance concerns. **4. Lineage is end-to-end, not point-to-point.** Lineage must trace from source system through transformation, through semantic definition, to consumption endpoint. Partial lineage (table-to-table only) doesn’t answer “Where did this AI’s answer come from?” **5. The system is open, not proprietary.** OSI, OpenLineage, and MCP are standards-based. Horizon Context ingests from any system with a connector. It serves to any system that speaks MCP. Lock-in would defeat the purpose of a universal context layer. Lesson Learned:In one implementation, Finance and Sales spent six weeks debating the definition of ARR. Building the semantic model took three days. Aligning on meaning took six weeks. Horizon Context doesn’t eliminate governance discussions — it makes them visible and resolvable. The technology is never the bottleneck. Organizational alignment is. Architect Note:Most organizations discover more business logic buried in Tableau calculated fields than in any formal documentation. Metadata Connectors often become a governance discovery exercise — surfacing definitions nobody knew existed — rather than just a technical deployment. Production Reality:The biggest risk isn’t getting Horizon Context wrong. It’s deploying AI without it. Every month you run AI agents against raw schemas is a month where inconsistent answers erode executive trust in your AI program. The longer you wait to establish governed context, the harder it is to rebuild that trust. *Next in Part 2: We roll up our sleeves and build the semantic layer — walking through Semantic View design, metric certification, governance patterns, and the common mistakes that derail implementations.* *Follow* *SnowflakeChronicles**for production-ready implementation guides, architecture deep dives, and practical lessons learned from enterprise data platforms.* #Snowflake #DataEngineering #ArtificialIntelligence #DataGovernance #SemanticLayer [Why Enterprise AI Needs a Governed Meaning Layer: Introducing Snowflake Horizon Context](https://pub.towardsai.net/why-enterprise-ai-needs-a-governed-meaning-layer-introducing-snowflake-horizon-context-7a15765c133f) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.