Skip to main content

Semantic Modeling Best Practices for BI and AI

Summary

  • This video explains how fragmented metric definitions across multiple BI tools erode trust in AI-driven answers, and why a unified semantic layer is essential for both human dashboards and AI agents querying data at scale.
  • Databricks addresses the semantic consistency problem through UC Business Semantics, AI/BI Dashboard semantic models, and the Genie Knowledge Store, which together ensure AI and humans interpret data identically.
  • Presenters share best practices for operationalizing semantics across Unity Catalog, dashboards, and Genie — covering relationship graphs, metric views, cross-table join auto-detection, and common pitfalls to avoid.

Semantic Modeling Best Practices for BI and AI

Watch: Semantic Modeling Best Practices for BI and AI
AI is making self-service data real, but it creates a new challenge: ensuring humans and AI interpret data the same way. When logic is fragmented across tools, inconsistencies emerge, trust erodes, and AI insights become unreliable.
Databricks addresses this with a unified approach to semantics across BI and AI. UC Business Semantics provide governed definitions, AI/BI Dashboards add local semantics, and the Genie Knowledge Store adds domain context to improve how AI answers. Together, these layers enable consistent BI and accurate AI. We’ll cover best practices for designing and operationalizing semantics across Unity Catalog, dashboards, and Genie:

  • Define and manage UC Business Semantics for governed metrics and dimensions
  • Use Dashboard Semantic Models and Metric Views for report logic
  • Use Genie Knowledge Store to improve AI accuracy with domain context and SQL
  • Combine central semantics and local curation across BI and AI
  • Avoid common pitfalls in semantic modeling

Talk By: Chris Eubank, Sr. Staff Software Engineer, Databricks ; Dillon Morrison, Sr Staff Product Manager, Databricks ;

Chapters

FAQs

What is UC Business Semantics in Databricks?

UC Business Semantics is a feature in Unity Catalog that provides governed definitions for metrics and dimensions, ensuring consistent interpretation across BI tools and AI agents. It acts as a central semantic authority so all consumers — dashboards, agents, and analysts — work from the same metric definitions.

How does the Genie Knowledge Store improve AI accuracy?

The Genie Knowledge Store adds domain-specific context and curated SQL to help Genie answer natural language questions more accurately. By encoding business logic, KPI definitions, and domain context, it reduces hallucinations and ensures AI-generated answers align with how the organization defines its data.

Why do fragmented BI tools cause problems for AI?

When metric definitions are spread across multiple BI tools, each tool can produce slightly different results for the same question, creating inconsistency and eroding trust. With AI agents querying data at scale, this fragmentation is amplified — a fleet of agents can generate conflicting answers if there is no single source of truth for metrics.

What are metric views in Databricks and how do they work?

Metric views are reusable semantic definitions that AI agents, dashboards, and human analysts can all query consistently. This video shows how to build metric views shared across Genie and AI/BI dashboards, with automatic detection of cross-table joins and cardinality relationships, and how dashboard visuals update automatically when the underlying metric view changes.

Full transcript

[00:08] Thank you everyone for joining. Uh we're super excited to have you here. My name is Dylan Morrison. I'm a product manager at Data Bricks. I work on a lot of our Genie functionality and then also a lot of our semantic modeling capabilities as well. And I'm joined by Hi, I'm Chris.
[00:22] I'm a software engineer and I work on metric views and dashboards and other pieces of our semantic layer. >> Awesome. And uh I know it's the basically the last session of the second to last day. They always save the best
[00:34] for last. So thank you guys for coming to enjoy uh what should be an awesome session today. And today we're going to talk to you about uh some best practices for semantic modeling in the age of AI.
[00:46] Uh so first most fun slide that we have. Uh none of these are hard commitments. Please don't uh take any dates down or anything like that. And make sure to take your survey at the end as well. And obviously give us five stars.
[01:02] All right. Right. Uh, good afternoon everyone. Thank you so much for joining us today. We're excited to speak with you about a topic that's becoming more and more relevant by the day. How to ensure that your AI has the proper business context
[01:16] it needs to correctly answer your questions. This is arguably the most important thing your organization can do today to effectively leverage AI. And here's why.
[01:28] Since the early days of BI, analysis centered around dashboard authors and dashboard viewers. That's no longer the case. Today, analytical questions are being
[01:40] increasingly driven by agents and chat interfaces, not by people just clicking around on a dashboard. But even when it was people clicking around on a dashboard, it was always a
[01:52] hard organizational problem to get everyone to align on the definition of a key metric. With AI, the risk is now that you have a whole fleet of agents asking a bunch of questions and needing to agree on things
[02:04] like what does revenue mean? How do you slice it? So on the one hand, AI promised to be one of the greatest force multipliers in in data analysis in history. But on the
[02:17] other hand, it can really amplify any issues in your organization if you don't get your house in order. So today, Dylan and I are going to talk to you about how to build your semantics
[02:29] for AI first, both for agentic quering and traditional dashboard use cases. Now, semantic layers have been around for a really long time. They were designed to enable
[02:42] non-technical users to navigate the messy and complex world of databases. Basically to enable self-service analytics but over the years they've really run
[02:54] into two major problems. Yeah. So the first of these problems uh everyone's probably going to be very familiar with. It's that every legacy BI
[03:06] tool from you know Micro Strategy and Business Objects all the way up to Tableau and PowerBI all require you to encode logic directly in the tools. Uh this logic is proprietary. Uh it's not
[03:19] easy to extract. These uh this logic doesn't interoperate. These tools can't talk to each other. So every time you add another tool to your stack, you get yet another definition of the same
[03:31] metric. And uh the average enterprise has something like four different BI tools and you probably have a bunch of custom homegrown apps with your own logic in there as well. So the end result of this
[03:45] is probably what most of you deal with today which is that you have different tools for different analysis. None of the numbers match up in them and there's no real authoritative answer.
[03:57] uh and this is basically the inevitable outcome of semantic logic being tightly coupled to the presentation layer to to the BI tool itself. What you really want is for that logic to live much closer to
[04:11] the data. You want that logic to be coupled with the data not the downstream tools that are cons uh that are consuming it. Uh the second major problem here is all of the upfront modeling that these tools
[04:24] require. Pretty much every one of these legacy BI tools requires you to encode every permutation of every metric upfront and that must be specifically enumerated by hand before anyone can
[04:37] start asking questions. So let's look at inventory as a as a classic example of why this is the case. Inventory is one of those metrics that can't be just neatly encoded as another
[04:51] column on a table in your warehouse. And that's because the way that you calculate inventory changes depending on the context in which you're doing that calculation.
[05:04] So for example, say I want to look at my current inventory. I could look at my inventory in warehouse A, warehouse B, warehouse C, and just sum those things up. You just add them together, and that gives you
[05:16] your current inventory. Uh, but say I want to look at my inventory over time. I can't just add up my inventory from Monday and Tuesday and Wednesday because then I'm going to be double counting or
[05:28] even triple counting. So instead, I have to take the latest value or an average or something else like that. So the way you're actually calculating this metric is going to change based on the
[05:40] dimension you're using to do the calculation. Uh these things can be at different level of detail, different granularities. Again, all these things need to be anticipated upfront and modeled into your semantic layer.
[05:53] So the the owner of this semantic layer, the modeler, their job is basically impossible, right? Because they need to anticipate every question that their end users are going to ask of their data.
[06:06] But of course, that's impossible because businesses are always changing, right? you have new products get launched, uh new teams get formed, new telemetry emerges. Uh all of these types of things
[06:18] beget new questions. And when those new questions are constantly arising, uh what ends up happening is the central data team, the owner of that model, uh that semantic
[06:30] model ends up with this huge queue of change requests that they have to slowly work through. Uh so the end result of all of this is basically that every new question you
[06:42] want to ask of your data ends up being gated by a few semantic modeling specialists who know where every uh use relationship or switch statement is buried in your semantic model.
[07:02] All right. So upfront modeling is is really been a a huge bottleneck in the past. So, if it was a bottleneck, why did everyone put up with it for so long? For a long time, despite the trade-offs, there simply wasn't a better way to
[07:14] quickly uh and reliably build dashboards. So, let's think about what you got in these legacy semantic models. You got consistent SQL generation logic that gave you consistent answers, well,
[07:26] at least within a single tool. You got the ability to declare relationships and customize things like filter flows through relationships. You could define metadata specific to an
[07:38] analysis and perhaps most importantly you could declare your key metrics and your key dimensions all within a single model. So for people building u
[07:50] dashboards through a low code interface and these dashboards can be quite complex. This was a genuinely good deal. It had its issues but really it's AI that shows the the cracks in this foundational layer of the data stack.
[08:04] So let's let's also look about what you were signing up for. These models were pretty all or nothing. If you wanted to declare a measure, you often had to stand up a heavyweight persistent model.
[08:16] If you wanted to make some tweaks, maybe add a table for a specific analysis and you didn't have edit permission on the model. The classic answer is that you clone the model and then your organization is filled with a bunch of
[08:28] clones with duplicate definitions of of key metrics. these definitions could get out of sync and then which which definition do you trust. So overall this was this approach was really assuming that you could
[08:41] pre-anticipate and premodel every possible question. And this was fairly reasonable when the consumers were people uh interacting with dashboards that someone had already built for them.
[08:53] this just really doesn't hold uh when you can have an agent asking any possible question. So overall, this was a reasonable bet in the low code UI dashboard era. It's just
[09:07] the wrong architecture for what's coming next. So by the way, the legacy vendors aren't ignoring AI. Their answer is, hey, just put a co-pilot on top of the models that
[09:20] you've already built. Why change a decades old approach just because of AI? So sure, on the surface that sounds pretty nice. You just plop your AI on
[09:32] top of your existing models and everything just works. But again, look at what this assumes. This is assuming the model is still the source of truth and that AI is just a friendlier uh way of expressing low code
[09:45] interactions. So again, this is assuming that you could anticipate everything up front, which falls apart when you have agents that can ask anything. Another really big assumption is that
[09:58] your vendor specific AI and agents are going to be the only agents navigating your semantic layer. That's really not a safe bet for anyone. So you run the risk of you have an AI agent. It's trying to
[10:11] build dashboards or answer questions on top of another vendor's opaque semantic model with its opaque uh interface and it's just not skilled enough to understand and give you accurate answers.
[10:24] Organizations that respond to AI but just by just doubling down on this legacy semantic stack aren't solving the problem. They're really only setting themselves for additional vendor lockin and an even larger pile of models that
[10:37] AI systems can't reason across. Awesome. Yeah. And so speaking of uh moving past the dashboarding world, uh there's a version of this that probably all of you
[10:50] are hearing uh across this conference and everywhere else that you're going to, you know, keep up on the latest in the data world. And that claim is that, you know, dashboards are dead or dashboards are dying. And in their place
[11:03] are going to be these rich bespoke custom apps that you can kind of vibe code on the fly. Uh, and well, I don't think dashboards are going anywhere. This is the 10th time in my career they've been called dead. Uh, I do think
[11:15] that we all want richer, more intera uh more interactive analytics experiences and apps can definitely get us closer to that. Um, but when you think about the data that's need to that is needed to
[11:28] power a custom app, it looks really really similar, if not identical to the data that you need to power a dashboard, except an app probably has, you know, a wider surface area and more
[11:40] interactivity. So, you probably actually just need more data. Uh but while a dashboard might require you to pre-model a few dozen different query paths, a really rich interactive
[11:53] application will probably require you to uh handcode, you know, hundreds or thousands of those different query paths. Because in one of these apps, every button, every widget, every drop
[12:05] down, a drill through, every different type of interactivity all just expose new questions that need to have been anticipated in advance and pre-odeled in advance. So if your semantic layer today
[12:20] is not keeping up with just a dashboarding use case and you constantly have the queue of requests from your your uh business stakeholders, building custom apps is not going to relieve any of that pressure. It's
[12:33] really just going to multiply it. Uh so the proposal on the table from a lot of these legacy vendors is that you should vibe code these very rich you know interactive deep applications on
[12:46] top of the same monolithic brittle semantic model that you've been using and again we think that's just going to amplify the pressure. We think that's actually completely backwards. The app
[12:59] layer should be the sort of easy and quick and disposable part that you can quickly vibe code together, but the semantics underneath really need to be durable and governed. Uh there was a great blog post that went out uh that's
[13:12] been kind of making the rounds the last few weeks from Anthropic about how they built up their data stack. And if you take a read through that blog, you'll see that 90% of the effort that they describe is still in kind of the manual
[13:24] process or not necessarily manual process, but the uh the human process of curating all of those metrics, getting people to agree on metric definitions, building out the right data marts and and building a very robust semantic
[13:37] layer. Then after that, LLMs can go wild. They can query it, you can write apps, you can do all this great interactive stuff. Um, and that actually brings me to my next point. which is that our sort of
[13:50] take here is that AI is not a reason to put a much nicer interface on the same old semantic models. Instead, our take is that AI actually gives us a reason to
[14:03] redesign semantics from the ground up for an AI first world. And over the last, you know, year or more, we've been doing a lot of experimenting. We've been thinking through this a ton, testing out
[14:15] tons of different frameworks, and we've ultimately landed on three different principles that we're using to drive our approach to building out semantics.
[14:29] The first of these is where logic should live. Uh this is I've been working in BI for 12 years or so at this point and I've always wondered why semantic logic lived in BI tools and there I'm sure there was a very good reason when they
[14:42] were built but to me it always seemed clear that semantic logic should live right next to the data so that all of your downstream consumers no matter how many different tools you use will all be speaking the same language. You just
[14:54] have one spot to iterate. Uh the second is that we believe your semantic layer should be built in an open language not a proprietary one and specifically that open language should
[15:08] probably be SQL since that's the default language in analytics. So we believe in a SQL first approach and this is really important because as sort of Chris was alluding to a minute ago by making this
[15:21] SQL native you are not betting your entire sort of analytics future on one vendor's AI being the only thing that's ever going to work over your data. Uh one vendor's AI is going to know that
[15:34] proprietary expression language pretty well. But you know, Claude, Chat, GBT, everything else in the world has been trained on a much larger corpus of SQL. It's a lot lot better at writing SQL than it is any uh any proprietary
[15:47] expression language. This also SQL of course makes everything interoperable. Uh, and then lastly, and this is where the agentic shift really pays off, and this is something I I hope you pay
[16:00] attention to here, which is that you no longer need to pre-model every permutation of every metric upfront. When the business demands precision, you
[16:12] can still go in there and proi provide an exact definition and include verified SQL statements and benchmarks and all of that great stuff. But for everything else, you can actually let the agent
[16:24] resolve a lot of the ambiguity at query time based on the context that it has, the context that you've given it through the semantic layer as well as the context that it has just built up through usage over time.
[16:40] Uh so let me show you what it looks like. This is what a relationship graph, which is what we call our semantic model. Uh right now we're famous for changing our brands uh branding names all the time. So this might change a few
[16:52] more times. Uh but right now we call it a relationship graph. And this is what it looks like inside of Unity catalog. I really wish I could demo this piece for you, but right now it's just a bunch of text files and doesn't look great. So uh here's a visual of what it will look
[17:05] like. And critically here um we're looking at a data set that follows a roleplaying dimension pattern. I'm sure probably most people in here are familiar with the flights data set. You
[17:18] have a flights table, you have an airport table, and you can join your airport table onto your flight table two different ways. Through a arrival uh airport ID or through a departure
[17:30] airport ID. So there's two different paths between these tables. With a traditional BI tool, you would have to do one of two things. You would either have to duplicate your airport table so you can have two different paths or you
[17:43] would need to declare one of these relationships active and the other one inactive. Um but you'll notice that in our graph it's just these two single nodes and we just have these relationships defined between the two.
[17:56] Uh and then we also include uh instructions. So each relationship carries instructions in the form of just plain language metadata. And this metadata can
[18:09] be used to resolve any ambiguity at query time if the user's intention in their query isn't isn't extremely explicit. Uh, another great feature of this
[18:22] instructions uh, area or all this like arbitrary amount of metadata that you can add is that you can bring a bunch of business context to your semantic model as well. And by business context, I mean
[18:35] the context that your different users are going to bring to your AI surface whenever they ask questions. So I think like you know pretty classic example here would be someone in sales might ask
[18:49] uh Genie how many logos we have. Someone in customer success might ask how many accounts we have. Someone in product might ask how many subscribers we have. Well with all of this metadata you can
[19:02] tell your AI agent that all of these different terms actually resolve to the same you know canonical core customers metric.
[19:15] All right. And so, uh, let's take a look at how we query this with AI. Awesome. Okay. So, that relationship graph that I
[19:27] was just showing,
[19:39] there we go. Exists inside of uh, Unity catalog today. So, let me go ahead and ask it a question.
[19:55] So, which airports have the most departing flights? Uh, and this is a live demo. Hopefully, this runs pretty quick here. And uh what's what I want you to pay attention to in the thinking and I'll expand this out so we can look back in a second here
[20:08] is you'll want to see that it's looking for our relationship graph as the authoritative source to answer this question. Uh then we what we'll want to pay attention to is how Genie resolves
[20:21] any ambiguity. And in this case I asked for departing flights. So we should see in the resulting SQL query that we're join joining airports onto flights using that departure uh ID, not the arrival
[20:35] ID. So we'll just let this cook for a minute here. But we can see that it did find the relationship graph and it did recognize
[20:48] it as the authoritative source for this. It recognized the cardality. It did a bunch of other thinking here
[21:04] and it looks like it's just building the visualization now. So let's take a look at the SQL that gets generated. Uh you can see that we are using a measure parameter. So you know that we're going to be aggregating correctly regardless of the level of detail. Uh in this case
[21:17] we're just a count looking at a count. So it's not that fancy. Um but uh further down in the query we'll see that we are joining
[21:38] Awesome. And then we can do the same thing for uh arrivals.
[21:54] Uh, I won't make you sit through all that thinking again. So, I'll just tee up one that I already showed a little bit earlier or that I prepped before this.
[22:09] Again, we can get down and look at the SQL. And we are joining on our destination instead of our origin. this time. And then for a tougher one, uh we can
[22:21] ask it what airports have the highest arrival to departure ratio. So this is a little bit harder because
[22:33] it's going to this query is going to have to walk both paths in one query. Go through both joins. It should create two CTE and then join those together to give us a good ratio. So, let me have one of these as well.
[22:51] This is some fake data, but we can see that we're looking at the highest arrival to departure ratio. Now, if I go into my thought process and look at the SQL here, we should see two CTE that get one for departures, one for arrivals that then
[23:05] get joined together to give us the result. So pretty simple example here but it does illustrate how Genie and any AI any
[23:17] AI agent that is quering this will be able to resolve that kind of ambiguity based on the user's question and then again I could always in my instructions uh metadata for these relationships I could put down hey if the user isn't
[23:30] explicit when they're asking about delays they're usually referring to departure delays not arrival delays so if there is any ambiguity you want to clear up, you can do it that way. Again, you can also provide exact definitions
[23:43] and specific verified SQL statements in that metadata to ensure that you're calculating or you're running the same SQL every single time. Uh, and this is what it looks like in
[23:55] Genie. Uh, but this will also work for dashboards as well. So, if I pop over to the lakehouse view, dashboards,
[24:07] and I'll create a new dashboard. And uh I'll go ahead and paste in a prompt here. But I'm basically going to ask it to build us a dashboard uh with some KPIs for flights, uh arrival,
[24:19] departure rates, uh delays, all a bunch of other interesting information as well. And we'll author this with Genie because basically doing everything with Genie first is a lot easier than uh manually
[24:32] doing anything nowadays. And we're going to want to look for basically the same kinds of signals in the chain of thought here. We're going to want to see that it referenced our flight analytics relationship graph and that it is
[24:44] constructing all of these queries using that definitive uh semantic model as our source. So this will probably take a little bit longer. So again, I'll bring up one that's pre-made, and we can jump back
[24:56] here in a second, but you can see that it's finding our UC relationships. It's finding the right uh relationship graph, pulling from the right metric views, and it'll go ahead and set up a bunch of
[25:08] different widgets for us. Let's pop over to one that's already finished. Uh so critically, well, I guess first off, you can see it produces a pretty decent looking dashboard. Uh lots of
[25:20] interesting information in here. And what's really helpful is that right out of the box, this is going to be very interactive. So if I click on United Airlines here as my carrier, you'll see
[25:32] that all the tiles will automatically update uh to reflect, you know, to just filter on United. So we get cross filtering out of the box here. And the reason that's the case is because again, all of this is powered by one semantic
[25:45] model. So, Genie knows how every single one of these tiles is related to one another, how filters can be passed from one widget to the rest of them. This is the kind of thing that you're not going to get if you just say points and LLM at
[25:59] uh a database and ask it to produce a custom app or a dashboard for you. That's just going to write a bunch of random different SQL statements to power each of those visualizations. And none of them are going to be consistent. None
[26:11] of them are going to be interactive. So if you think that you're going to get a really interactive awesome app again just by throwing an LLM at it, that's really not the way to do it. You want to have a really strong semantic foundation. So you get all of this kind
[26:24] of interactivity just right out of the box. Let's see if it's finished here. Okay, it's almost done. Sweet. Um, and again, just so you know, I'm not lying. Uh, I can go ahead and cross
[26:36] filter on this one as well, and we'll see this all update. This one actually looks a lot prettier, too. It's nice. Awesome. Okay, so let's see what that would look like if we were doing this
[26:49] with a traditional BI tool. And I'm going to power uh pick on PowerBI here. Um, but in this case, to produce the same kind of dashboard with the same level of interactivity and all of these cross relationship uh metrics like
[27:02] arrival to departure, you're going to have to write a lot of DAXs to do this kinds of analysis. Like a a lot of DAXs. And it's obviously going to be very opaque to anyone that is not a DAX specialist.
[27:15] Uh, and this is because PowerBI, just like a lot of legacy tools, require you to declare, again, only one of these relationships to be active. So, I can only look at arrival flights at a time, or I can only look at departures, or I
[27:29] have to write a bunch of custom proprietary uh, statements in order to look at both. And this looks pretty short, but it's actually, you know, probably like a little bit over 200 lines of of DAX that you need to write,
[27:42] which I don't think anyone uh loves particularly doing. Uh and again, this this used to be a very acceptable trade-off in just a world of dashboards, right? But now with AI, that trade-off
[27:54] just doesn't really make sense, which is why we built our uh our semantic model to be completely AI first and to be adaptable to an AI first world. so that any of your uh downstream consumers be
[28:07] it a dashboard or Genie as we just saw or a custom app or any other consumer all of them can just speak the exact same language and query the same objects at the same time. Um one other benefit
[28:20] about having uh the way that we've built out our semantic models is that the whole model is really a living artifact and it grows and evolves iteratively over time. And I'm going to let uh Chris
[28:32] show you what I mean by that. All right. So with monolith, there's a bunch of upfront modeling for every dashboard. But model once doesn't mean that everything needs to be predefined
[28:44] centrally by some kind of omnisient data team. Modeling can and often does happen at the edge. Someone doing ad hoc analysis in a query uh or in a dashboard
[28:56] and then really the best me metrics and dimensions can get promoted down to the central model. So in this approach the model grows iteratively with you. Uh it evolves as your business evolves rather than being gatekeeped by a central team
[29:09] which again needs to manage a big queue of tickets. So this iterative approach also prevents duplication. So users prototype at the edge and they don't need to create a whole new model leading
[29:21] to model and measure sprawl. Uh they just need to promote the very best. So I'm going to show you what this looks like.
[29:47] all right. So, I'm going to build on the dashboard that Dylan just built. And so, imagine for a moment that I'm uh an analyst and ops and I've asked it to create a new widget and a new measure around severely delayed flights. So here
[29:59] I'm really in the exploratory phase. I'm asking Genie to do this. Maybe I'll keep this measure, maybe I won't. The point is I don't have to uh clone a model. I can build this locally in my dashboard.
[30:11] And what we'll expect to see Genie to do is extend my dashboard local model and then build a widget on top. So again, this is very much on the edge. And we see that it is uh editing a data set
[30:23] calculation and a new widget will should be showing up on the bottom.
[30:47] All right. So there we have severely uh late late flights by month. And again I was I was simulating an analyst doing something at Hawk. Let's say this is actually a pretty useful me metric. The VP of ops wants this to be available for
[30:59] everyone. So I will ask using Genie to promote this measure to UC
[31:12] and again I'll be this will be built on top of UC's governance model for the sake of this demo. Uh I'm an admin so yeah not just anyone can push stuff up. You need the right permissions but
[31:25] for sake of demo we're just going to let it rip. All right. So, this this metric again started from the dashboard. I was doing some modeling at the edge. It's now in UC.
[31:38] And of course, this is really only going to be useful or most useful if I can use this measure everywhere.
[31:50] So, here I'm going to ask Genie to show me my severely delayed flights by month. And again, this is a measure that did not exist just even a few minutes ago. I created it in the context of a dashboard, vetted it, thought it was
[32:04] useful, pushed it down to UC. So, I'll let this this run for a little bit.
[32:24] Okay. So here we have hey this thing is being built on top of a measure and we see once again I've promoted this this ad hoc measure that I built in the context of a dashboard down to UC and
[32:37] it's safe to consume through the the measure aggregation function. So we don't have to worry about Genie hallucinating what's the definition of this measure. It's it's part of our metric view which is centrally managed
[32:49] and safe to consume through SQL.
[33:02] going to give you a viz. There we go. >> All right. Now we have a viz. So that's the whole loop. You start local, you move fast, you promote uh your measures and dimensions when they prove useful. And the moment it lands in UC, every
[33:15] consumer gets it for free. your dashboards, your genie, your agents, your customb coded app, one definition everywhere. So that's what it looks like when your semantics actually live in
[33:28] your platform. All right, so we want to leave you with three things. First, the platform is the point. When
[33:43] your semantics, your data, your governance, your compute, and your AI all live in one system, you get one semantic layer that everything reads from instead of needing to federate two
[33:55] or three systems that you need to spend time keeping in sync. Second, modeling every possible question in advance was never really going to work. It was a losing game even during
[34:08] the low code UI dashboard era and it's even more of a losing game today when you have agents that can ask anything really quickly all in parallel.
[34:20] Third, rigid and trustworthy aren't the same thing. You can have precision when the business genuinely needs it. For example, we provide assets like metric views and SQL.
[34:33] And you can use metadata so that your agent can resolve ambiguity and handle correctness everywhere else. You don't have to trade one for the other. So if there's one thing to take away from this talk, it's this.
[34:46] Build your semantic layer for agents, not just for dashboards. Organizations that do so will be able to ask better questions, get answers that they can trust, and not have to manage
[34:59] many systems. Thank you very much.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.