Overview
Most organizations have spent years building out Bronze, Silver, and Gold layers in their medallion architecture, refining raw data into clean, reportable tables. But this latest episode of The Dashboard Effect podcast argues that structure, built for BI tools and human analysts, was never designed for a large language model asking its own questions. The hosts introduce the concept of a “Platinum Layer,” a new architectural tier built specifically to bridge the gap between traditional medallion architecture and the requirements of AI, so that a model can accurately interpret and query business metrics without the ambiguity that trips up even experienced analysts.
The conversation moves quickly from concept to practice, covering the documentation, data modeling, and infrastructure choices that make this new layer work in a production lakehouse. See how Blue Margin’s Managed Data Platform helps organizations build the AI-ready foundations this episode describes.
What This Episode Covers
Defining the Platinum Layer (0:00 – 1:00)
The episode opens by naming the problem: Gold layer tables built for dashboards and reports carry assumptions that a human analyst understands intuitively but an AI model does not. The Platinum Layer is presented as the missing piece, a purpose built tier that sits on top of standard medallion architecture and prepares data specifically for consumption by large language models. The hosts frame this not as a replacement for existing architecture but as an addition to it, one aimed squarely at making AI outputs trustworthy.
Markdown Files for Context (1:00 – 3:19)
Because AI models are non-deterministic, the same question can produce different answers depending on how the underlying data is described, or not described, to the model. The hosts make the case for maintaining plain markdown files inside the lakehouse that spell out business definitions, calculation methods, and known data gotchas in plain language. Without this documentation, a model is left guessing at which column represents revenue or how a metric should actually be calculated, and it will guess wrong often enough to matter. This section treats documentation as infrastructure, not an afterthought.
Modeling for AI (3:19 – 5:28)
Traditional BI modeling favors star schemas with carefully managed denormalization, built around the assumptions of tools like Power BI. The hosts explain why AI models need the opposite approach: extreme denormalization down to a single, well defined grain. They use invoice data as the example, showing how a model querying line-item detail can easily miscount invoice totals if the grain of the data is not obvious and consistent. Getting this modeling decision right is presented as one of the highest leverage choices in building a reliable Platinum Layer.
Cleaning and Curation (5:28 – 6:37)
Gold layer tables often accumulate columns and logic added for a specific chart or a one-off report request, and that clutter carries real cost once an AI model is querying the same tables. The hosts recommend a deliberate curation pass that strips out report-specific fields and obscure logic that lacks general utility. The goal is a dataset that reads as clean and intuitive to a model as it would to a new analyst on day one.
Nightly Materialization (6:37 – 7:43)
Standard views work well for BI tools that can tolerate a few seconds of query latency, but the hosts point out that on-demand LLM queries need to feel instant to the end user. Their recommendation is to materialize the Platinum Layer nightly rather than relying on views computed at query time. This tradeoff, freshness for speed, is discussed as a reasonable one given how most business questions do not require up-to-the-second data.
MCP Servers as a Gateway (7:43 – 9:30)
The episode closes on Model Context Protocol servers as the mechanism that actually connects an LLM to this curated data. The hosts describe a tiered approach, with tightly scoped servers exposing a narrow set of vetted questions to business users, and more open configurations available to analysts who need to build complex, ad hoc queries. This distinction matters for governance as much as for usability, since it controls who can ask what of the underlying data.
Who It’s For
This episode is worth your time if you are a data engineer maintaining a medallion architecture, a BI leader evaluating how AI fits into an existing analytics stack, an analytics team lead thinking about governance around AI data access, or anyone who wants their organization’s LLM tools to return numbers people can actually trust.
Why It’s Worth a Listen
The most valuable idea in this episode is also the simplest: a model is only as reliable as the documentation and structure behind the data it queries. Organizations that have already invested in a mature Gold layer may assume they are AI ready, and this episode makes a clear case for why that assumption often does not hold. The gap between “reportable” and “AI queryable” is real, and the hosts give a concrete list of what closes it.
The discussion of modeling grain is particularly useful for teams that have run into the classic problem of an AI model confidently returning a wrong total. Hearing the invoice line-item example laid out so plainly makes the fix, extreme denormalization to a single grain, much easier to justify to a team that may be reluctant to move away from familiar star schema patterns.
The closing segment on MCP servers is worth sitting with even after the episode ends, since it reframes AI data access as a governance question rather than a purely technical one. Organizations that get the Platinum Layer right, and pair it with a thoughtfully tiered MCP setup, put themselves in a strong position to let both business users and analysts query their data through AI with confidence rather than caution.
