Our take: medallion architecture is a shared vocabulary, not a specification. It helps a data team, a governance team, and an executive board hold the same picture in their heads; which is genuinely valuable. But the things that decide whether an AI agent gives trustworthy answers on your data are mostly things medallion does not describe: where access control sits, whether business definitions are attached to physical structures, and whether you can still explain how a model got its data six months from now.
We put that to four practitioners in a recent WhereScape panel discussion, From Bronze to Gold: Medallion Architecture Best Practices for AI Readiness, featuring Mike Magalsky of infoVia, Trung Ta of Scalefree International, Simon Meacher of Engaging Data, and Paul Watson-Gover, Senior Solutions Architect at WhereScape, moderated by WhereScape Solutions Architect Alex Perry.
They disagreed on plenty – and even agreed on a few points! What follows is the seven lessons the conversation kept returning to and a 90-day plan for acting on them.
Why AI readiness is different from analytics readiness
Medallion architecture organizes a data platform into three progressively refined layers: bronze for raw ingested data, silver for cleansed and integrated data, and gold for curated, consumption-ready data products. The pattern is documented by the platform vendors that popularized it, including Databricks and Microsoft Fabric.
None of that is new. What is new is the consumer. A person reading a report brings skepticism to it and checks a strange number against what they already know. An agent does not. Trung Ta framed the consequence in terms of blast radius: a bad number on a dashboard produces one bad decision by one person, while the same bad number reaching an autonomous agent can trigger a customer refund, an email to a client, or a supply chain order — at machine speed, with nobody in the loop.
That is the shift the rest of this article is about. Data that is good enough to report on is not automatically good enough to act on, and the distance between those two standards is where the work sits.
Lesson 1: AI readiness is human readiness, plus a margin
Ask what AI readiness means and you usually get a list of new things to buy. The panel started somewhere less exciting.
Paul Watson-Gover made the point directly: the things that make data ready for AI are the things that make it ready for people, plus more. Integration, quality, and settled definitions all had to be there anyway if you wanted data anyone could trust. What changes is the removal of the human validator, and that removal raises the bar rather than moving it.
Mike Magalsky’s working definition is worth writing down: delivering the right data to the right people at the right time, where “right data” means someone has already decided how the data relates and integrates rather than leaving an agent to guess, and “right people” means access control and governance are wrapped around it.
The practical implication is that most of your AI readiness backlog is not AI work. It is the integration, definition, and governance work that has been deferred for years because reporting tolerated the gaps.
Lesson 2: The readiness that fails first is organizational, not architectural
The most useful story of the session was not about layers at all. Simon Meacher described watching an entire data team walk out the door.
The setup was ordinary. The team was serving the business with a dimensional model and a steady output of Power BI dashboards. Then AI arrived as a top-down decision, and demand for changes to the data set increased by something like a hundredfold. The team had neither the tooling nor a change process built for that rate. A few people left, the workload redistributed onto those remaining, and the function collapsed — after which the organization had to rethink how it served data to the business at all.
Mike Magalsky described the same underestimation from the other end. A CIO at a healthcare organization told him the plan was to put all the data in one place and turn AI loose on it. His response was that they should hope for a generous credit card limit: at best they would pay for a great deal of compute, and at worst they would pay lawyers to get them out of a data breach.
A practical test before any AI initiative starts: if the volume of change requests hitting your data team increased tenfold next quarter, what would break first — the platform, the process, or the people? Most teams can answer that honestly in about a minute, and the answer is rarely the platform.
Lesson 3: Medallion earns its keep as vocabulary, not doctrine
Trung Ta credited medallion’s popularity to two things. It imposed software engineering discipline on cloud object storage at exactly the moment first-generation data lakes were turning into data swamps. And the metaphor is trivially explainable to an executive board, which matters more than architects like to admit.
Simon Meacher extended that. Bronze, silver, and gold mean subtly different things to an IT team, a governance team, and a data owner, but all three groups hold the same picture and can have a productive conversation. That shared conceptual model, not the technical content, is what made it spread.
Paul Watson-Gover offered the counterpoint, and it is worth sitting with: much of medallion’s popularity is marketing. You ingest data, you transform it, you present it. That is what a data warehouse has been since the discipline started. Someone attached labels to layers the industry already had.
The cost of treating it as doctrine is a pattern most teams will recognize. Silver becomes a mix of bronze and silver, or of gold and silver, because someone made a tactical decision to ship something and intended to sort it out next month. The lines blur, the governance around what belongs where blurs with them, and the debt compounds until you have re-created the silos the warehouse was built to eliminate.
Mike Magalsky located the real value more precisely than the framework does: the silver layer. An integrated, historized, auditable data set is your enterprise memory. Gold is what you build on top of it; bronze is what you feed into it.
Lesson 4: Push enterprise rules left, let audience definitions live right
Demarcation is where most implementations actually struggle, and the panel got specific about it.
Enterprise-wide business rules belong in silver. Define them once and reuse them as building blocks. The definition of a full-time employee is a good example: encode it once rather than reimplementing it in four data products. Access control belongs left for the same reason — which roles see which rows, which columns are masked for whom.
Rules that legitimately differ by audience belong in gold. Revenue is the classic case. Sales wants credit when the deal closes; finance wants it when the payment clears. Neither is wrong, so the definition floats right, where each consumer gets the version it needs.
An audience question asked whether there is a platinum layer, and the answers were more interesting than the question. Mike Magalsky pointed out that Data Vault practitioners already split silver in two — the raw vault holds integrated source data with no business logic applied, the business vault holds derived structures built on top of it — so an argument for four layers exists in practice. Paul Watson-Gover floated a different use: a platinum layer for data fixed and uninterpretable by design, such as a filed quarterly earnings report.
The consensus landed on a principle rather than a number. The right number of layers is whatever your organization can define, defend, and enforce. For a smaller team, a strict three-layer medallion can be over-engineering. This is the kind of decision worth resolving during data model design, where changing your mind costs a diagram rather than a migration.
Lesson 5: Draw the AI boundary at access control, not at a color
The question teams ask most is which layers AI should be allowed to touch. The answer that emerged is less about layers than about who is asking.
The rule from the discussion: anything reached by the general user population must sit to the right of where you implement access control. That line does not map neatly onto bronze, silver, and gold.
Applied to each layer:
- Gold is where production AI belongs for business users. The data is curated, definitions are settled, and access control has been applied. With semantic context in place, an agent can reasonably operate here without a human reviewing every answer.
- Silver suits exploratory and data science work. It has passed quality gates and referential integrity checks but has not been rolled up into business aggregations, which makes it the right grain for model training and investigation. Paul Watson-Gover’s caveat: without semantic information about what is in there, poking around is dangerous, and it should not run unattended.
- Bronze is for the data team, not the business. Mike Magalsky actively encourages engineers to use AI against bronze as an accelerant — building the silver model, drafting access control policies, generating test harnesses — provided it stays behind the right security walls. Simon Meacher added a neat use case: point an agent at bronze, test it against silver, and have it report the gaps.
Turning a general-purpose agent loose on the whole lake is the failure case, and it fails on cost before it fails on governance. Trung Ta’s warning was blunt: teams that do not watch consumption will let an agent scan an entire data lake to answer one question, repeatedly.
Lesson 6: The semantic layer is not a layer, and it may outrank your modeling style
If one theme deserves to outlive the recap, it is this one. Every panelist converged on it from a different direction: the semantic layer is not a fourth layer; it is metadata about the data in the layers you already have.
Trung Ta described it as functionally a data catalog — the mapping from physical columns to business concepts, so a group of tables becomes “customer” or “party,” and a column named something like revenue_2026 is explicitly identified as gross, net, or recognized revenue.
That mapping is what stops an agent from finding a few columns that look like sales and costs and inventing a profit calculation of its own. As Paul Watson-Gover put it, AI is capable of being confidently wrong. Semantic context does not eliminate that risk; it mitigates it, which in a regulated environment is the difference between a defensible answer and an indefensible one.
Two implications follow, and both cut against how the term is normally used. First, semantic context is needed in silver as well as gold — if exploratory work happens there, that layer needs descriptive metadata for the same reasons. Second, for AI readiness specifically, semantic context may matter more than the modeling decisions teams spend most of their time arguing about. Paul Watson-Gover’s version was that it outranks how you structure the platform or which modeling style you choose, because without available context the rest does not save you.
If you are deciding where to spend the next quarter of readiness effort, business definitions and descriptive metadata will return more than another round of layer refactoring.
Lesson 7: Lineage breaks quietly, and metadata-first is what makes it defensible
Governance discussions tend to stay abstract. This one got specific about a failure that is easy to miss.
Simon Meacher described real problems with AI models built on a silver layer that keeps moving. The data team makes ordinary, legitimate changes. Those changes break lineage, and the ability to answer how a model got its data — and therefore how it reached its conclusion — goes with it. He has seen teams respond by versioning table structures, some linking versions to commit hashes in a Git repository, so they can state the shape of the data at the moment it was handed to the model. Nobody has a settled answer. Regulated industries will need one, because being right is not sufficient when you also have to show the working.
Mike Magalsky framed the underlying choice as two camps. In the first, you write code to do whatever you need, then reverse-engineer lineage from that code afterward. In the second, you define source-to-target mappings and business rules first, then generate the code from them. Lineage, governance, and access control are all sets of business rules that can be expressed as data and enforced by generated code — an idea he traced to Chris Date’s short book What Not How.
This is where a metadata-driven approach stops being an architectural preference and becomes an audit requirement. When mappings, rules, and transformations are captured as metadata, documentation and lineage come out of the same source that generates the code, which is why we have always generated both from one place rather than asking teams to maintain them separately.
The honest tradeoff: defining rules before generating code is slower at the start and much faster from the second change onward. Teams under pressure to show something in a fortnight often choose the other path, and the bill arrives later as a body of code nobody can explain.
A 90-day AI readiness plan
None of the above requires an AI strategy document. It requires the unglamorous work of making data structured, governed, and explainable, which as Mike Magalsky pointed out is most of the job.
Days 1–30: Decide and document.
- Write down what each layer is for, and get governance and the data owners to agree before anyone builds. Retrofitting a demarcation means telling people to stop working the way they learned.
- List your enterprise-wide business rules — the ones that must mean the same thing everywhere — and mark which are currently implemented more than once.
- Identify where access control is actually enforced today, and draw the AI boundary there.
Days 31–60: Attach the context.
- Add business definitions and descriptions to the physical structures in gold, then in silver.
- Reconcile the definitions that differ by audience and decide which ones are allowed to differ.
- Pick one narrow AI use case and run it end to end against gold, so you learn what context is missing before scale makes it expensive.
Days 61–90: Make it survivable.
- Test lineage by asking a question you would need to answer for an auditor, and see how long it takes.
- Version what you hand to models, so a change in silver does not sever the trail.
- Stress-test the organization, not just the platform: model what a tenfold increase in change requests does to your team’s throughput.
Our work on data modeling for AI readiness goes deeper on the practice, metadata-driven design covers the principle, and teams standardizing on Data Vault for the silver layer will find that Data Vault automation maps onto the raw-vault and business-vault split described above. Platform mechanics vary; our walkthrough of building a medallion lakehouse on Microsoft Fabric is one concrete example.
Medallion architecture is a data design pattern that organizes a platform into three progressively refined layers: bronze for raw ingested data, silver for cleansed and integrated data, and gold for curated, consumption-ready data products. It is a convention, not a formal standard, and organizations adapt the number and definition of layers to their needs.
Not on its own. The layers give you a shared vocabulary and a sensible flow, but AI readiness depends on things medallion does not specify: semantic metadata mapping physical structures to business concepts, access control applied at the right point, data quality sufficient for automated action rather than human review, and lineage you can produce on demand.
It depends on the user and the use case more than the color. Production AI serving business users generally belongs in gold, to the right of where access control is enforced. Exploratory and data science work fits silver, provided the layer is documented. Bronze suits the data team using AI to accelerate modeling, testing, and policy work, kept behind internal security boundaries.
Silver holds integrated, historized, quality-checked data — the enterprise memory everything else is built from. Gold holds purpose-built data products for specific audiences, with aggregations and audience-specific rules applied. Enterprise-wide rules and access control usually belong in silver so they are defined once; definitions that legitimately vary by consumer belong in gold.
There is no standard platinum layer. Some teams make a case for a fourth, and Data Vault implementations already split silver into a raw vault and a business vault. The more useful framing is that the right number of layers is whatever your organization can define, defend, and enforce.
Generally not a separate layer. A semantic layer is descriptive metadata: business definitions, terminology mappings, and context – attached to data you already have, closer to a data catalog than to a physical layer. It matters in silver as well as gold, and for AI readiness it is arguably more consequential than the choice of modeling style.
Because you have to justify the result. When a recommendation influences a decision, someone eventually asks how the system got there, and lineage tied to metadata shows an auditor or a user how the answer was produced. It also breaks quietly: a routine change to silver can sever the trail between a model and the data it was trained on.
Where to get started?
The panel’s through-line was that AI readiness is unglamorous. It is definitions, governance, semantic context, and provenance — work that was always worth doing and that AI has made unavoidable. Medallion architecture helps you discuss that work with people who do not share your vocabulary. It does not do the work for you.
The full panel discussion is available on demand, including the audience questions on permissions, data mesh, and where a platinum layer might fit.
