Anyway, thank you for joining. So this is the September webinar, it's called Snowflake AI and the Rise of the Semantic Layer. It's quite a grandiose title, but I am James Austin, I'm the Services Director at InterWorks. I've been here for fourteen years, but I've been in the BI space a little longer than that, maybe seventeen or eighteen years. I came primarily from the front end perspective, so the Tableau's and Power BI's of the world, but these days I find much more of my time being spent inside Snowflake, and to be honest, I'm really enjoying the transition, so I will do my best to walk you through this topic. Today's topic is exciting. It's a little intimidating, but it's a new set of offerings that are available within your Snowflake instance. That's assuming you're already a customer. If you're not, then I guess this is a bit of a teaser and preview for some of the things that could be available if you transition. I may be the one presenting today, but the content has very much been a team effort, and an international team effort at that, so special thanks to Tim Carell who delivered this webinar a few weeks ago to a US audience, and then all the way over to Australia to Paul Middlewick, our solutions director who helped review the material. Right, thank you is out the way. Earlier this summer we attended pretty much in force the Snowflake Summit Conference in San Francisco and if you listened to the keynote speeches, the presentations, the labs, there's one thing that came across loud and clear, and that is Snowflake is all in on AI. The company sees AI integration as a massive integral part of its strategy, and to further its goal the AI offerings are very much woven into the fabric of its product. For some time now, it's kind of been hard to describe Snowflake as simply a cloud data warehouse. It doesn't really do it justice. I think today it's more being positioned as an AI first cloud data platform, and this move towards AI is significant. I expect, to be honest, that's why many of you have joined us, and you know technology companies like Snowflake, they move super quickly. Other industries, healthcare, financial services, maybe the change is slightly slower, and the appearance of some of these AI tools can be a little bit overwhelming. So whether you're a long term Snowflake user, just getting started, hopefully you will get something out of today's session and invigorated to, see what else is out there. Right, let's have a look at what we're covering today. We've got a fair bit to tackle. We're going to give you an overview of the Snowflake AI landscape. It's centered around two user facing tools that are on the platform, then we'll dive into semantic layers in general. Make sure you've got a firm grasp of the concepts, because after that we'll move into the Snowflake implementation and its semantic layer, and what they call the semantic view. We're going to wrap things up with a live demonstration, fingers crossed that goes okay, and, and then we'll have a quick preview of some of the upcoming features that are going to be released by Snowflake in the next few weeks months. I'll repeat it again, but Vicki's kindly explained that we do have the Zooms Q and A feature. Please make use of it. If you have questions, I'll invite you to enter them there. We'll review those questions, but we can discuss them at the end, and any that we don't have time for, we will do our best to reach out to you in the next couple of days. Right, let's get started. When you have a little look at the SnowSight user interface, there's a left hand menu called AIML. Quite frankly there's a long list and some of those features can be confusing, you know, what does each of these do? How does it help me? Do I have to be a data engineer to be able to use it? Do I have the right roles and permissions? So we're going to try and simplify this down, focus our attention on two of the main AI offerings, and these are fully integrated into the platform. First of all Snowflake Code Work and then Cortex Code, which is now being rebranded as simply Coco, I think is super cute. These tools are designed to be the user facing entities that you're going to be using, so they're going to be the ones that you're probably hands on when you get inside the tool. We're not going to be getting too technical during our discussions today, but I will tell you that under the hood of both Cowork and Coco is an LLM, it's such a large language model, brain if you will, and that is built by Anthropic. This is the same company that offers the Claude set of AI tools, they have become increasingly visible in the AI space, and Snowflake announced that partnership with Anthropic late last year, and since then the two companies have partnered to bring Cowork and Coco into the Snowflake platform. Snowflake building the scaffolding and then Anthropic providing the LLM to sit on top of, and then power these two products. For most people, technical or not, the only parts of Snowflake AI suite you're ever going to interact directly with will be co working Coco, so we're going to take a closer look there. Snowflake Cowork is the conversational AI agent built into the Snowsite UI that lets non technical users ask natural language questions, get responses pulled from the structured tables, the unstructured documents, No knowledge of SQL is required, so simply put Cowork is a chatbot, but it's a chatbot that's wired directly into your organisation's data. One of the primary use cases for a tool like Cowork is to move those ad hoc data requests away from the IT team or your analytics team, and bring it to the business users, you know the managers, the execs. What were the top 10 instant ticket categories for last year? Which stores in the North Of England accounted for the biggest increase in net revenue? For many organisations, those questions are currently being answered either by submitting a ticket or emailing somebody on the right team, and then waiting for a response. Now, I honestly feel like I've been saying a sentence like that for maybe ten years, and inevitably there has been an answer for it. Some tool that is making inroads into ad hoc data querying, but, and this is quite a big but, with co work and the proper configuration, we are as close as ever to having those answers obtained directly in near, near real time, through natural language. So no tech skills required. We are getting super close to that holy grail. There are already some more advanced features built into the Cowork product, and, well one that might hold a little interest for people is called user skills. This is one that allows you to take a routine task, something you perform regularly, and you can automate it and schedule it into a workflow. As an example, when you the first thing you need when you get to your desk might be the numbers from yesterday's outbound call center. So you can have co work perform that query and have the data waiting for you when you boot up the machine. Two other slightly more advanced capabilities are deep research, which coordinates like this multi step investigation across the company's data to answer some bigger open ended why type questions, but it gives you all the sort of fully cited sources and allows you to investigate further, And the last one is artifacts, which is when you spin up a chat and you start having that conversation and it gets to something that is useful for you, you can start to build those into persistent shareable objects, charts, tables, dashboards, and then other teams can interact with it. I'm not going to get into those in any more detail than that, so we're gonna we're gonna leave it at that, but before we move on, I just wanted to address something that comes up pretty regularly. In fact, I remember asking exactly the same thing. So I already pay for Claude. I have it on my desktop and I use it daily, so I've got the got the application running. So if Claude and co work have the same brain underneath, why don't I just point my copy of Claude at Snowflake and use that? And the answer is you definitely can, right? And I want to be clear that this isn't some backdoor hack either. Snowflake and Anthropic jointly built, an official connector has been marketed, you know, this is a real sanctioned integration, and it isn't particularly difficult to set up either. Snowflake has documentation describing this four step process. You can complete it in about twenty minutes and Claude can connect to it directly, and then so there's no separate software, nothing else is required. Right? And that word easy is probably what should give you pause here. Like when was the last time you heard easy integration and robust governance in the same sentence? Probably never, because easy really isn't the same thing as safe. So let's say you configure the setup. You've connected your copy of Claude straight to Snowflake. Once that connection exists, you've effectively opened up a new door into your data warehouse, and how that door is built really does matter. So the connection that runs underneath, whatever permissions your team assigns it, if that role is broader than it needs to be, then the AI can reach in, see and touch more than was ever intended for it. There's also, some additional, maybe less intuitive risks like prompt injection. This is not exactly a new issue, but, certainly hasn't been around for too long. So this is where a document, like a support ticket or something that the AI has been asked to read can contain hidden instructions and hijack what it does next, and to be honest that risk is real. There are disclosed incidents of exactly this happening at the moment. Final one is, a more broad AI type question, and this is where does the data actually go once it leaves Snowflake? Claude's LLM might have an app on your laptop, but it doesn't run on your laptop, It runs on Anthropix cloud infrastructure. So how long will that data be retained? For how long? What is passed over open web? It's an important question for anyone in a regulated industry, and to be honest it's one that your compliance team will definitely want an answer to. So the connection from claw to snowflake is safe by definition, but if you open it up, it's your responsibility to build that connection obviously. You've got to secure it, you've got to monitor it, and you've got to do all that rather than just having it pre configured, pre tested, backed up by the organization that issued it and you know, we move away from this can you, rather you move into this world of you know should you or if you're gonna, please do it carefully. Talk to your IT security team, I'm sure they'll have an answer for you. Unless of course you are the IT security team visiting this webinar to learn about it, in which case reach out to us, we'd love to have a chatty. This scenario does reveal one of the sort of big selling points for Snowflake's AI tools like Cowork and Coco though. They're already built inside of Snowflake's security perimeter, and they are governed by the same role based access that you use when you log in and that you touch any other data objects. So co work and co co recognize who the user is that's logged in, they make all the inquiries to the data warehouse via that default role. So if you as a user can't see private customer data just with a direct SQL query, then you're not going to be able to see that data using Cowork or Coco either, and you know the best part is that the configuration is already done. Your Snowflake administrator doesn't have to do anything extra to add this new functionality. So as compared to an external connection scenario, you know pointing your desktop Claude straight at it, when you use any of Snowflake's AI offerings, your data it all stays put. The LLM, Power Ring, Cowork and Coco really does reside within Snowflake's security boundary, so your data is never sent across the open internet, and this isn't just like some clever marketing. Snowflake's AI trust and safety document, obviously I've read it, it really does commit to that in writing. Okay, sorry about all the security bits, if you're still with me, then let's move on to some more fun stuff. So we looked at co work. The other side that we mentioned was Snowflake's Cortex Code or Coco, and this is an AI coding agent that sits, as you know by now, natively inside Snowflake. You access it directly, there's a little kind of side tab pop out, it sits there inside the Snow site UI. There is a standalone desktop application that can connect as well, I think there's even a command line interface available, I haven't used it, but there are adapters that allow connections from IDEs like Versus Code and there's extensions for Microsoft Excel and other programs. So it can be an integrated part of your world. Cocoa itself can write and edit SQL queries, beyond that store procedures, functions, it can maintain python notebooks, it can build DVT packages, there is loads that it can help you with built right there inside the Snowflake platform. So you're granted permission to access those selected objects and then it conforms to all of the role based access controls set down by your security team and guides you along the way. So what's it used for? Well, just about everything these days. Many of us here at InterWorks find that Coco is super useful in debugging. We use it to tune queries, like identify orphaned key references, compare two entire schemas one against the other to see what the differences are. Super useful if you're moving something from a development environment across to a UAT, know turn Coco loose and it will perform that analysis, give you the results, and way faster than any human ever could. If I'm honest, it's rare that I spend a session inside Snowflake where I won't use Coco at some point. Super valuable tool. It definitely speeds up the development and the testing. Cocoa has two main functions. It's the interface between the developer and the system. That's pretty key, and it classifies and assigns the tasks. So then it kind of collates the output between multiple independent workflows. The process very much works on like a plan approve execute loop, so it interprets what you're asking it, shows you what kind of plan it has for you, and then it sits there waiting for permission to proceed. If you go and agree, say yes crack on with that, or I give you permission to view that object, then it calls the appropriate tools in the background and starts completing that task. Sometimes it adds a little added extra in there just for completeness or kind of suggests where you might want to go with it, so it's not always entirely limited to the task that you ask, but, it is still very, very useful, but the point is there is that human in the loop. I will note just for completeness that there are definitely other AI tools available beyond Cowork and Coco. We've got Cortex Agents, there's Cortex Analyst, there's Cortex Search. I'm not going to cover those topics today, but there is plenty of material available both on the InterWorks blog and elsewhere about some of those objects. So I said in my intro that Snowflake is all in on AI and it's clear that the direction the platform is going, you know, Snowflake, Cocoa can be used straight out of the box, and you know all of this stuff shows that this is not going to stop. This momentum into the AI platform is going to run for some time yet. It is all out of the box, but in some ways there is a limit to the results that you can get from either tool. There is a limit to the usefulness of the results that it can throw back at you, and that usefulness is because there is a missing piece to this puzzle. The missing piece, you know, this is the missing piece that really does turn that AI usefulness up a dodge, up a notch when we're talking about how it might talk to your data. You Now computers themselves, not AI, but computers are super good at maths. They're good at matching. They can commute, can sum two integers. They can assess whether the data in field A is identical to the data in field B, but what they don't have is understanding. They know that maybe there's a currency field called EBIT and they're able to, you know, to do maths on that. They understand how it's calculated, similarly if you point an AI tool at that, it is going to be able to tell you that maybe EBIT is up 3.1% year over year in Q2, but it doesn't really understand the concept of what that means, why and how it can deep dive further to become super, super useful. The missing piece of the puzzle is the semantic layer. Now this is a decade old idea, you know it is the way that we can give your snowflake instance the understanding that it needs to answer questions that really do dive deeper into your data rather than just raw statistics. This is the semantic layer. The concept is old. The idea has existed in analytics for decades, and it has recently been making inroads into the data warehouse space. It has most recently been positioned, sorry, it's mostly been positioned you know in this layer between the data and the reporting layer. So there is this kind of middle ground that is the semantic layer. The idea is that it provides additional context, so tools like Power BI and Tableau can start understanding the data a little bit more clearly. It in the past has not been a necessary component. You know many companies completely, correctly saw the utility in it and implemented this kind of idea. So why are we now starting to see the semantic layer being discussed as this must have component within your data platform? Well, the advent of AI integration has really supercharged the semantic layer. It's pushed it into a much more pivotal role. As we mentioned, the context provided by the semantic layer is really critical to allow tools like Cowork and Coco to give the user the practical, actionable responses. In a lot of cases, the more robust your semantic layer, the more benefit you'll realize from your AI implementations, which is huge, right? You're paying for this stuff, fortunately the semantic layer is going to be able to act in both those capacities. The same definitions, formulas and aggregations will serve really well for the reporting, as well as the AI integration, which adds another layer of benefit to this define once, use everywhere strategy, which is inherent to the semantic layer concept. The information provided via the reporting layer will be as consistent and reliable as the responses to queries in a tool like Coco and CoWork and vice versa. I'll quickly give you the stock definition that you might get online, and then we'll build on that. So, a semantic layer is a transition layer sitting between raw complex data storage and the people who need to use that data. It provides a means for turning commonly used terms specific to your organisation into a means of extracting the data those words represent. It also standardises definitions and calculations, so similar data requests provide consistent and reliable results, and I like that, but it doesn't get to the crux of what the semantic layer really does. What we need is an analogy. I'm gonna have you think about a restaurant. So behind the counter are the cooks, the ingredients, the tools like a saute pan, there's ovens. On the other side you have the dining room where there's the customers, and they're trying to order a meal. Now think about the restaurant experience if the customer had to know how to make the dish they wanted when they submitted that order. So they needed to know what ingredients, what order they need to be assembled in, how long they'd be cooked for, at what temperature. You know, you can't just go and sit down, you would have to do some research, get some preparation before you ever get seated, and customers wouldn't know what ingredients are available. One person calls a chilli might be very different from, what something else would associate to that dish. Let's flip it around and, put ourselves in the kitchen. So the cooks would then get these orders and they try and interpret what was being asked for. Maybe sometimes they would understand it and they would smash it. For others, the kitchen staff are just going to sit there guessing, and more often they're going to get it wrong, right? If an order came in that included an ingredient of pepper, then they might mean ground black pepper, they might mean sweet pepper, they might mean jalapeno pepper, they might mean chili pepper, and if you get that wrong, then the dish is probably going be ruined. So what's needed in this restaurant world is a way to standardise and provide simple language so that the order process, the request from the customer can be fulfilled exactly as expected. How did they solve this? With a menu. Nothing, nothing complicated. This is a list of offerings that the restaurant can provide any moment in time, right? The customers can choose what they want and the kitchen staff knows exactly which ingredients, which tools, meaning that they can, you know, get the order right every single time. Even if that restaurant has locations all over the country, there may be a chilli that you had last week in Newcastle will taste exactly the same as the chilli that you're now ordering again in Birmingham. So over time that menu might change, but those changes are done in a really orderly fashion. Maybe as new seasonal, vegetables come in, that menu will start to change, but the kitchen always knows what's on the menu and they know how to make it. And you may have seen where I was going with this, but the semantic layer is very much your menu. So it's the collection of offerings that are available in easily understood language. The user doesn't need to know the formulas, the industry jargon, or the name of that specific column for any one piece of data. All of that is baked into this semantic layer, and so even when the data layer changes, the semantic layer can be adjusted to ensure that those consistent results remain. That So means when a stakeholder orders quarterly sales by region from the venue, the response is generated consistently each time. Move that to the world of snowflake, and we get something called a semantic view. Now this is a kind of physical manifestation inside of your data warehouse, and it is a full data object. We'll come to that in just a sec because that word object, is kind of interesting. It's not a document that is sitting off to the side somewhere, right? It is not like a PDF that has to be written and stored somewhere. It's not a wiki page that is off to the side. It lives right there in your database, inside the same schema as your tables, sitting right next to the data that it's describing, and that matters a lot more than maybe it sounds like it should. So we'll get to that in a sec. Semantic view. I'm going to give you a quick example of what this looks like. At its core, the semantic view is built from a handful of building blocks. There are five of them actually. So first you've got your logical tables, and they just map the business ideas like the menu items, customers and orders maps the ideal, the idea to the real table. Then next you've got the relationships and that tells Snowflake how to connect those tables, so it can quietly handle those joins for you. Then come the three pieces that do the real translation work. You've got the facts, which are the raw numbers at the sort of finest grain of detail. You've got the dimensions and these are the things you'd want to slice or filter by like region, store, order date, and then finally we've got our metrics. These are the actual business numbers that people care about. Maybe that might be total revenue or total orders, and you write all of that once in a single statement and from that point forward any person, any report, any AI tool that asks for average customer rating gets exactly the same answer calculated in exactly the same way every time. A very quick bit just to avoid confusion. We're pretty familiar with the term database view. This is the named query that provides a curated look into an underlying table, but it doesn't understand anything about your data, it merely hands you the data when you ask for it. Different to what we're describing today, the semantic view. It's kind of a shame that they've got a similar naming convention, but they will will cope. It's also worth saying that the semantic view object is a replacement for how Snowflake used to handle this. It used to be a file, so the distinction might seem mute, but it really does streamline the creation and administration of the semantic layer. So before the semantic layer information resided in a YAML file and that was placed inside file storage, and because a file is not considered the database objects, those semantic YAML files didn't get the same permissions that you'd be expecting. It didn't show up in your governance tools and if you wanted to track changes, then there was a whole bunch of hoops to jump through. The Snowflake semantic view by, by definition kind of fixes all of that. It's a native object. The semantic view inherits all of Snowflake's full security model, so you can share it, publish it like any other data asset, and best of all for the data engineers amongst us, can manage it exactly like software. You can version it in gits, you can peer review any changes before they ship, so you can catch those bad joins or whatever before it ever reaches the user. There's even a DBT package built specifically for semantic views, so you can define your metrics using DBT if you're already doing it that way. Creating the semantic hue that is done in kind of one or two ways. I mean there's kind of some middle ground between it but you know the natural question how does it get built and, the reality is there is write it by hand, full full effort, full control, you you build it and you've your data engineering team can spend a while getting that together, or you can switch on the autopilot and let it loose. Let's look at the full control because, you know, this first path is one that you're probably a little bit more familiar with in the data engineering space. It's the same as you'd write any other database object. You're deciding every table, every relationship, every metric and you know your data engineering team are honestly going have to work their way through it, but it's what you'd expect from any well governed, idea that you get the most precise option, but it's also the slowest, and you have to make sure that you get it right and it assumes that someone on your team already deeply understands the data. You can obviously fire up Cocoa and get it to work with you and write, so all the syntax is kind of handled, but the business logic and things is still very much down to you. So write it yourself is an absolutely valid option. The other one, the other path, which is what we're going to go over in the demo today is a new feature, and it very much changes the perspective on all this. So there is now this offering called the semantic view autopilot, and this is as close to an easy button as you can get. So you point your autopilot at the data and it writes the first draft of the semantic view for you. It looks at how the tables are structured, it looks at how people have actually been querying the data in the past, and then it starts inferring the metrics on its own. There's still work to be done after that, but it really is a leap into getting this, you know, to a first MVP kind of stage, and here's the feature that garners a lot of interest. So if your organisation already has business logic built into visualisations BI tools like a Tableau workbook or a Power BI, then the autopilot can read those Power BI files and bring that logic straight into the semantic view. So you're not starting from scratch. You're migrating what your team has already spent years building, and you know really turning that multi day modelling exercise into something that can happen in minutes. It's kind of cool, but we'll get there. I'm currently working alongside a project right now that's helping a client build their first cloud data warehouse. Exciting for them, and one of the questions that comes up is where's the finish line? When is my data warehouse done? And as you might guess, that answer is never. There is constantly data flowing into it, which means there are adjustments being made, new lines of business, new marketing strategies, you know, all of this yields maybe a new revenue stream, and the data warehouse needs updating as your organisation's needs change, and just like your data warehouse, as that evolves over time, a semantic view is not going to be something that you build once and walk away from. You really think of it as more of a living document than a finished blueprint, and that's actually the point, right? As your business changes, new questions come up, new data gets added, the definitions need to keep pace. So the real question isn't how do you build one? It's more how does it stay accurate for six months or so. A lot of that upkeep is automatic or close to it, so Snowflake watches how people are using the somatic view, what they're asking, what questions come up short and it surfaces suggestions. That could be to add a new metric or include a related synonym, so or anything that is being regularly shown from people's natural queries during the during the course of their day can start to be brought in, and on top of that there's an ongoing accuracy check that runs in the background. So kind of something like a school report that retests the semantic view against a known set of business questions every time something changes. So enough update accidentally breaks something, it hopefully shows up before your business users ever notice. I'm gonna pause very quickly. I know that there are hands raised, questions coming in. We will work with that, towards the end. I'm gonna just sort of rattle through these next couple of slides, get into a demo, and then we'll, get into the Q and A. It does work on a kind of use it flag it kind of scenario, so if when you're using co work you spot something that's wrong, you flag it, it gets logged and it can then be sort of built into a workflow to make some of those corrections. So you've built it. The next question is how do you use it? Well, if it's being if it's an AI tool that is inside Snowflake that is using this semantic view, you don't need to do anything. It is all built right there, ready to use those, semantic views, which is yeah, that's perfect. If it is a BI tool that your organization is using, wanting to point to that, that new semantic view, then it's maybe not going to be quite so automatic. Once it's built, you can query a semantic view directly. So on the left hand side there, you've got to select from semantic view. The syntax is slightly different, but you'll get used to it. On the right hand side there, we've got just a kind of CocoCodework query that was asking data from the semantic view that we're going to build in a second. The AI side of it works really well. The BI side of it might need a little bit of, a little bit of work on your part. The good news is that the act of just deploying a semantic view by itself is not going to break anything. Your existing reports are still going to work. They're going to still be pointing to the underlying tables. They're just not going to leverage the benefits of the semantic view until you make that flip, and to be clear, your, some reporting tools are not going to need a special plug in, some might, but if the calculations were taking place inside the reporting tool, and you want to utilise the new semantic view, you swap the data source, and then you know, everything kind of gets a little bit simpler from that point. Rather than inside of your tool, you're joining five tables together and calculating it yourself, you're flipping that to be just ask the semantic view for that metric. There's also a good chance that you don't need to rebuild all of the graphics either. Tools like Tableau have a replace references feature that can swap those calculations to those new metrics and it will do it across the whole dashboard suite. I'm conscious of time, so I'm actually just going to kind of flick this slightly. Tableau it is already built in Power BI, Excel and some others may not be. It is a new feature, so expect these to be built into the tools pretty rapidly. If you need help assessing whether the current BI tool that you're using is, is applicable, obviously ask your vendor, but you can also reach out to us and we'll, learn alongside you. Okay, let me quickly dive into the demo side of things because otherwise we are going to run out of time. This is Snowflake for those of you who haven't seen it. I'm currently in catalogue, and I am looking at 14 tables that are that have recently been brought in from a different, instance of Snowflake, so I don't have a lot of background or history with these. We've loaded the tables and then we are wanting to drop this new semantic view on top of it. We can see inside of the schema at the moment we only have the tables. So next we move into Cortex Analyst. So this is, the kind of cheat sheet, the guided view, and to start building a semantic view, if it's your first one, there's going be a little button down here, if not you can create it up on the top right, and this starts getting into a little wizard to help you rattle through this stuff. We said before that we have this ability to explore Tableau data sources and Power BI data sources to pull out some of the logic, and you can absolutely do that. So this is the place to start start working in that way, but you can also start querying the existing, SQL queries that have been used against this data set. That is what we are going to do for this moment. Now if you were looking at a set of tables that's been in use for a long time, when you go to browse those queries, oops sorry, when you go to, look at the query history, you are going to see a whole load of information against those tables. I only actually have one because I haven't really been doing anything to this, so it's not going to work me just querying or looking at what's been used in the past. I'm going have to do it a slightly different way, and that is to add some verified queries into the mix, and these verified queries are things like, you know, what is the total revenue by property for 2024, and then an associated query that I know answers it, and I was able to glean these from my previous instance, but Snowflake here doesn't have any knowledge about them. So we can load the CSV file, we can select which is the question and which is the query, and we start firing into these things. Now I said before that the semantic view used to be based upon a YAML file. We're going to be using the new semantic view, so we are very much sitting in this world and let's give it a name. Because of those queries that I threw at it, it was able to determine that I'm going to need all 14 of these tables. That's fine. We then move into which columns have been required and again, because the queries that I gave it, it picked and, chose some of those, maybe not all of them, but I would very much say that you're building this semantic view for the future, not for right now, so I would probably just build it all. And we fire this off. Now at this point it is going to whir away in the background. Now when I ran this last time, it took about two minutes. I'm very much hoping it doesn't take the full ten minutes or this is going to be a slightly boring demo for you guys. Whilst this is kind of buzzing away in the background, I just wanted to talk a little bit about those verified queries. So here was one of them. So what is the total room revenue by property for 2024? There was then a query that was, found to be useful from our previous work. Some of that might live within a Tableau workbook or a Power BI workbook, some of it might live within queries that people have used in the past. Either way, we've got a question, we've got a SQL statement and then a sensible set of answers that comes out the back of it, so we treat this as a verified query. The file that I loaded in was a CSV file that just had a whole bunch of these. Now you don't necessarily need to do this step if you've got an existing set of tables that has had a lot of use. I don't, so I did have to do this step. Let's jump back and see how it's getting on. It is still wearing away. Well, whilst it's building, let's see what's actually kind of being created here. We've got our 14 logical tables. We decided which dimensions and facts we wanted to be included within here. What we're missing at the moment is the metrics, so those just from pointing and shooting were not built, so this is part of this wizard to try and include some of these metrics, and towards the bottom when we get past this, we move into this verified queries world, which is what we were just suggesting. We are slowly loading. I'm wondering whether we have time to take a quick pause and take a question or actually no, whilst this is loading, I am going to jump back very quickly and talk about the billing model for this kind of thing. So this is for the sort of finance y people, and Snowflake is a pay for what you use platform, so adding in any of these AI features is not going to directly affect the bill. Now first of all, you've got storage. The cost here is negligible. So firstly storage is super cheap and secondly the semantic files are tiny, especially compared to the way that the data size is, you know, the data size is being queried. There is no separate license to turn this on, you just, you know, you could turn it on or off, but there is no separate license, so there's no additional payment there. There is no flat fee, it is purely on what you use, is what you consume, and that's exactly the same as anything else that you can compute, same as your notebooks, same as your ad hoc queries. But success works both ways, right, and, I'm not going to gloss over that. If you turn these on, the cost will scale with adoption. So that means if co work massively takes off within your team, and it does tend to, then your bill is going to reflect that success. The nice thing is you're not flying blind here. Snowflake does give you some controls, set spending limits, and there is a whole cost management section on the left hand side. There's a little spanner icon, find the cost management. There is tons in there to get you started. Beautiful. Let's see how we are going. Woah, my geese is still working. Well, in which case, I'm going to take a very quick pause and take a drink. Always the curse of the demo, but it's going to take a little longer than usual. This happens quite a lot whilst you're doing this, and just to kind of point out that underneath this you won't notice it, but there is still a YAML file, and the nice thing is whenever you're building these things, it does this validation section, so you'll see that whirring away quite, quite, quite often. This is looking a little bit, a little bit happier. So the schematic view is built, which means if I go and have a little query into my schema, I should now see both my tables and my new semantic view, And if I were to have a quick look, much like the screenshots that I had before, there's these five sections of it. We've got our tables, we've got our relationships, we've got our facts and our dims. We haven't yet added in any metrics because that takes one extra step, but they would be, built in as you go down at the bottom there. Okay, the metrics themselves to build in are done in this way. They are kind of steered towards you, but you do need to do this accept step. You've got to check that the logic is accurate. You may want to edit the naming convention if you're not particularly happy with it, and then you accept those into your semantic view. So against the factor of inventory, we now have a total property count. You can obviously keep working with, keep adding in as you go. The one thing just to remind you guys of is that the save button is very useful here, otherwise do all of this work and nothing ever actually happens. So you've got to save it, then those changes get reflected back into the semantic view. The great thing is this is just, as I said, a living, breathing document, and we'll just keep updating as we go. Fantastic. We are rapidly running out of time and I did want a little bit of a few moments just to flick through some of the questions. So I'm going to completely dive through all of this. We can, share the slides afterwards, but I really would like to spend at least a couple of minutes with a Q and A. I haven't been looking at the chat at all. Hopefully we have Chaitanya or CJ on the line who maybe has been having a little look through these. Are there any that you would think are appropriate to have a conversation about CJ? There was one question or remark about while defining the semantic layer, we have this mess that we have so many models and there are so many star schemas, and how can we then translate? So does our semantic layer or does a semantic layer is simply a replica of all those bits in, lumped into one YAML specification. So it's not like that. I think it is important to understand the difference between semantic view, which is a Snowflake construct, and a semantic layer, which is a logical concept. And semantic layer is a logical concept that is agnostic to Snowflake. You should be able to implement your semantic layer using various tools. But for that, the most important thing is that you agree upon the semantics. Right? That is the most important word in that phrase or that concept is the semantics. That means that there cannot be multiple definitions of what revenue means. There cannot be multiple definitions on what a purchase date means or when an invoice will be generated and so on and so forth. Unless and until all these things are agreed upon and a spec or they are defined and a spec of that is ready, defining semantic views or implementing semantic layer for that matter in any of the tools is not going to be much helpful. So it's very important to understand that tools are now enabling us. So once the concept is ready, once the definitions are ready, once the things are all agreed upon, using tools like so building it itself was a very tedious task before. You had to have different tools. You had to have, them orchestrated and so on. But now with help of Snowflake, once your definitions are ready, you are very easily able to implement them. This is, I think, an important aspect of this to understand. Awesome. Thank you very much, CJ. We have probably another one that we could look at if there is another one that you thought was appropriate. Rest of the questions I had answered indeed in the chat or in the Q and A panel itself. If there are more, do contact us. We will be happy to answer them for you. Exactly that, yes. So we are out of that time. Please reach out to us. We would love to hear your comments and your ideas or your experiences of using these. There is a big difference between the theory of how to build these and the practical implementation in a wild environment. So please, give it a go, reach out to us if you get stuck. We are here and very, happy to help you. Today has hopefully been a little bit of a an eye opener, an introduction to some of these features that maybe you weren't so familiar with before, and they are very, very powerful. I've, said along the way that there are some notes of caution, especially if you're trying to use Clawd Desktop and things, but, it is a very, very exciting world that we are moving into. I said before this idea of moving into ad hoc querying with natural language and the semantic, view being implemented, it is all bringing us so close to that business user, ask the question, gets a sensible result out the back of it that can be trusted. It's a super exciting time. Thank you everybody. I appreciate your time, and, yeah, we will speak to you very soon, I'm sure.