# Ontology on Snowflake: How to Make AI Actually Understand Your Data | Snowflake Summit 2026 **Channel:** Snowflake Developers **Source:** https://www.youtube.com/watch?v=Ooan6cErKCM **Transcript page:** https://www.withtranscript.ai/video/Ooan6cErKCM ## Chapters - 0:05 — Introduction and Ontology Fundamentals - 5:22 — Ontology-Driven Architecture and Layering - 12:11 — Agent Orchestration, Tooling, and Wrap-Up ## Transcript **[0:05]:** All right, thank you everyone for coming and hope everybody enjoyed the summit so far. If you have been building a system in the enterprise, you probably have noticed the hard part is even the model. It's not the compute. It's that AI doesn't understand what your business means. How many of you have built an agent that confidently gives the wrong answer? Show of a hand. All right. That's what happens when meaning is missing. Today is about fixing that. Making meaning explicit, scalable and usable without leaving Snowflake. **[0:46]:** The formal term of that layer of meaning is ontology. Ontology on Snowflake, unifying data, making semantic scale and grounding AI reasonings. Let me show you how. By the end of the session, I want you to leave with a clear understanding of what an ontology is and how to build one natively on Snowflake and why. That's the missing layer that makes your AI actually works. **[1:18]:** My name is Tian Xiajia, Principal AI Architect at Snowflake. I lead the AI ML go to market and solutioning for enterprise customers. I help organizations land AI successfully in the enterprise setting. Leverage Snowflake AI data Cloud so, four parts of our story today. We will start with a problem, then a key idea. **[1:43]:** Then we will build a solution layer by layer. And I will leave you with a tool that does it all for you. Let's start it. **[1:53]:** Let's start with the why. **[1:57]:** In the AI era, companies don't compete on who stores more data. They compete on who understand how their business actually works. But today there is a big gap. Facts lives in database, definitions live in people's head or scattered documentations. And the AI system. **[2:21]:** I expected to somehow infer reality from raw tables. Look at the left side of the slides. That's what we store and what we are feeding to AI today. Tables, foreign keys, cryptid column names. And we hand this to the agent and expect it to understand our business. **[2:44]:** Now let's look at the right. That's how the real world actually operates. There are objects, peoples, teams, contracts. And they are related to each other in specific ways. For example, a person works for a team. **[3:01]:** A contract binds them together. This isn't schema, it's reality. The result of that gap, brittle SQL, duplicated logic and AI, that sounds confident, but actually gets things wrong. So the goal is simple. We move from joining roles to reasoning over concept. **[3:25]:** So let's talk about what. **[3:28]:** Before we solve this, I need to clear up the biggest confusion in this space. People use ontology and knowledge graph interchangeably. They are not the same thing. Think of it this way. The ontology is a blueprint. **[3:45]:** It says a person can work for an organization. A player is a type of person. A club is a type of organization. And these are abstracted rules. What's allowed to exist and how things can relate. **[4:03]:** You define once, it rarely change. The knowledge graph, on the other hand is the building. It's what actually got built from that blueprint. Mbappe is a player plays for Real Madrid, a club that's a concrete fact specific and changes every transfer window. See how they connect. **[4:28]:** The blueprint says persons can work for organizations. The building says Mbappe plays for Real Madrid. One is the rule, the other is the instance. And you need both, but you keep them separate. The blueprints evolve slowly and intentionally. **[4:48]:** The building changes more frequent. That separation is what gives you stability and flexibilities at the same time. This separation is a key that drives how to model and store them on Snowflake and thus enable query them separately. Remember this one sentence? The ontology defines what relationships are and allowed. **[5:16]:** The knowledge graph materializes which ones actually exist. **[5:22]:** Okay, let's talk about how. So how do we actually build this? Here is the five layer architecture and I want you to take away with one sentence. Facts store once meanings defined as configurations and the intelligence orchestrated dynamically. Think of it as building a house. **[5:48]:** Layer one is your foundation, your physical storage. Two tables, that's it. Everything in your business is either a node or an egg. Layer two is your ontology metadata. This is where you declare what things means. **[6:08]:** Classes, hierarchies, relationships, all configurations, no code. Layer three are generated automatically. A compiler reads your metadata and produce views. You never read this by hand. The bottom three are the data layer. **[6:31]:** And then layer four are three purpose built semantic models, each designed for different kind of questions. And finally layer five is quartile agent it orchestrating everything intelligently at runtime. So five layers, everything native on solvate. **[6:53]:** So let me show you what happens when someone asks a question. Let's see in motion. This is how a query flows through the system. The user types something in natural language. It hits Quartile's agent, the brain at the top. **[7:09]:** The agent doesn't try to answer the question itself. Instead it asks what kind of question is this? Then it picks the right tool or multiple tools in parallel and merge the result. A question about specific players goes one path. A question about all personnel goes another. **[7:32]:** A governance question goes yet another. And graph traversals different tools entirely. The user never think about routing, they just ask. This system figures out the rest. That's the promise of ontology driven architecture. **[7:53]:** Okay, let's build this layer by layer. Start with the bottom. Layer one is radically simple. Two tables, the nodes. Tables stores everything that exists. **[8:08]:** The edge table stores every connection between things. Both use a variant columns for flexible properties. And look at the SQL on the right. Player is a node, club is a node, Place four is an edge between them. That's it. **[8:30]:** So here is why this matters. When you are business, add a new entity type, say a referee. You don't create a new table, you don't run a migration. You just insert nodes with type referee. The schema never changes, facts are stable, meanings evolves above. **[8:55]:** So now we layer the meaning on top. And this is where it starting to get interesting. Layer two is pure configurations. You are writing declarations, not code. Person is a type of thing. **[9:11]:** Player is a type of person. Coach is a type of person. You are building the inheritance tree just like object oriented programming but for your data. Then you declare concentrates. Only a player can play for a club. **[9:29]:** This is the blueprint in actions defining what's allowed. And here's the beautiful part. When your business involved new roles, new relationship, it's just one simple insert statement. Now schema rewrite, not a pipeline. Rebuild one row of metadata, the system adapts. **[9:54]:** Now who actually build abstractions? Not you, our competitors. Layer 3 is my favorite part. You call a stored procedure generate ontology view. It reads your metadata defined in layer 2 and discover that a person has two concrete subtype player and a coach. **[10:15]:** And the generated view called ontology person that unions them automatically. Look at the result on the screen when you query the ontology person. You got both coaches and the player unified under one abstract concept. You didn't write that SQL, the compiler did. And when you add a new person subtype next month, rerun the compiler. **[10:41]:** The view expands every query that use ontology person just works zero code changes downstream. **[10:52]:** So here the design decision take us a while to figure out. We tried to build a gigantic semantic view that tried to rule them out. It didn't work. Why that? Because showing Real Madrid result last season and show me all personnel in our organization are fundamentally different questions. **[11:13]:** One needs speed and specificity, the other needs polymorphism and abstractions. So we split into three purpose built lenses over the same mentality. First is the knowledge graph model fast concrete attribute rich your operational layer semantic view on node and edge tables that enable query the graph directly using SQL including multi hop query. Second is the ontology model abstract polymorphic. When you ask about people and guide Players and coaches, whatever exists. **[11:52]:** This is where AI reasoning shines. And the last is the governor model, the system describing itself. What type exists, what relationship are defined? Who has access Same truth underneath? 3 optimized interface on top. **[12:11]:** So let me make this real. Same club, two different questions, two different answers. Who plays for Real Madrid? Concrete queries go through the knowledge graph model. You got all players, fast specific, every attribute right there. **[12:28]:** And who works for Real Madrid is the abstract query. Go through the ontology model. Now you get players and the coach. It automatically crosses type boundaries. Nobody had to code. **[12:43]:** Also check the coaches table. The ontology knew that players and coaches are both people who work for the club. That's an aha moment. The abstract model evolves with your business and at team doctor next year they just appear, no query changes. **[13:05]:** So this is the final layer. The brain ties it all together. Quartet's agent is not a monolithic AI that tries to do everything. It's a conductor leading an orchestra. Each musician, each tool is specialized. **[13:27]:** The conductor's job is to know which instrument to bring in and when. For example, who works here? The agent calls abstract semantic model. What is the shortest path between the two entities? That's a graph analytics. **[13:44]:** What entity types exist in our model? Governance tools. And sometimes it caused multiple tools in parallel that merge the result into one coherent answer. This is what I mean by intelligence through coordinations. No single model can do it all. **[14:02]:** But an orchestrator over specialized tools, that scales. **[14:09]:** Okay, now I can see some of you thinking five layers, three semantic model, a compiler, an agent. That's a lot of work. It is. So what do we do? We automate it. **[14:25]:** I'm super excited to introduce the Ontology Stack Builder. It's a COCO skills. You invoke it and it works you through the entire stack in an interactive and gated workflow. You give it your tables, your business questions. It introspects the schema, propose an ontology. **[14:48]:** What is the classes? What are relationship there? Is there any hierarchies? Then it launches the this visual graph editor you see on the right. You can drag nodes, draw relationships, inspect coverages. **[15:02]:** Once you approve the design, it generates all the SQLs, deploys layer one through three and create a semantic view and wires up the cortex agent and validate everything end to end. Seven faces, each has a gate. It's human in the loop. You stay in control. You control what entities relationship God created and the full flexibility to modify and update. **[15:31]:** The heavy lifting COCO handles that. What used to take weeks or even months of handwritten SQL building ontologies and manual setting up the agent now one session. You can create the entire stack and get the ontology driven knowledge graph agent within an hour depending on the complexity of your data. **[16:00]:** Let me leave you with one picture that tell the whole story. **[16:07]:** At the bottom is your data. Custom tables, sales tables, product tables, raw facts. This is where 99% of organizations stop. They hand this to AI and hope for the best. **[16:27]:** In the middle is the ontology. It's nothing but is the business concept that connected by meaning. Customer Persona, revenue stream, product category, market trend. This is the missing bridge, the layer that transform raw roles into something AI can actually reason about. **[16:55]:** At the very top is the AI agent. When someone asks how can we improve ourselves in Q3, the agent doesn't just scan the table, it traverses the ontology, find the right customer Persona, identify the relevant market trend, connect it to product categories and produce an answer grounded in business reality. Data gives you fact, ontology gives you meaning and the agent gives you intelligence. Together one system native to Snowflake. **[17:38]:** So thank you and let us know what you think and take a minute to read the sessions. If you like it, remember the problem where we started with okay, AI doesn't understand your business doesn't understand what your business means. Now you have seen the fix. Three takeaways. First make meaning explicit, store facts once, define meaning as metadata and let the system generate the rest. **[18:09]:** 2. Use purpose built lenses, concrete knowledge graph for speed, abstract ontology for reasoning and governance for the trust. Third, let the agent orchestrate intent driven routing. No hard coded passes and you can start building today using the ontology stack builder skills in COCO takes your tables and gives you back the full stack and the ontology aware agent that understand your business and all assets are publicly available from the solution to the COCO skills. I will be at the Platform Peak booth this afternoon and Thursday morning. Feel free to stop by. Thank you very much.