In this chapter
- Why bronze always ships and silver always stalls.
- The medallion redrawn as the people each layer actually needs.
- The three-body problem: what a lakehouse does without a conceptual anchor.
- How work routes around missing decisions, and what that costs downstream.
Every stalled lakehouse program tells the same story in the same order. Bronze ships in weeks and the team celebrates: sources connected, tables landing daily, green ticks on the ingestion dashboard. Silver is scheduled next, and silver never quite arrives. It slips a sprint, then a quarter, then quietly shrinks until what ships under the name is not what the diagram promised. When the reckoning comes, the blame lands on the platform or on the engineers, and both verdicts are wrong. This chapter is about the mechanism that stalls the middle layer, because until you can name it, you will keep buying bigger platforms to fix a problem that was never technical.
Bronze is the only layer one discipline can finish alone
Count the people it takes to land a source table in bronze. A data engineer builds the ingestion. Someone who owns the source system explains what the extract actually emits and which field moves when a row changes. A platform engineer handles storage, identity, and compute. All three roles sit inside technology, all three are already on your organization chart, and all three are bookable this week.
Bronze asks nothing of you beyond that. There is no modeling to do, because the source system already made every structural decision, and no metadata to negotiate beyond what the source publishes. There is no meeting where two departments have to agree on anything. A team can land two hundred tables without asking anyone what a single one of them means, and because the work is pure technology, it is exactly what this generation of AI tooling accelerates best. That is why every tool ships source-to-bronze first, and why the early weeks feel so good: ingestion runs, row counts match, the dashboards glow. It feels like a stable era, and stable eras end.
Now count the people it takes to publish a governed revenue number in gold. You need a data modeler for grain and conformed dimensions, a steward who can say which definition is authoritative, and a business owner who can define the measure and defend it when departments disagree. Then you need an analytics engineer to implement it and a semantic model developer to expose it. Half of that list does not report to you, and most of them are paid for a different day job.
That asymmetry, not technical difficulty, decides your running order. Bronze goes first not because it is easiest, but because it is the only layer a single discipline can finish without asking anyone else for a calendar slot.
The diagram nobody draws
Every medallion architecture diagram you have seen is a diagram of technology: three boxes, arrows, and a vendor logo in each corner. Strip the technology out and draw something else instead, the people each layer actually needs.
Figure 2.1: the involvement grid. Ten roles down the side, three layers
across, weighted by how much of each person’s time the layer consumes.Read it by column, not by row. Bronze is a narrow band of engineering. Gold is wide, but it is predictable, because by the time a number gets published everyone already accepts that it needs a business owner. That leaves the middle column, and it is the one worth staring at, because it is nearly solid. Silver is the only layer where engineering, architecture, modeling, governance, and the business are all core at the same time. That is the diagram you never saw, and it is the one that predicts your delivery dates.
One staffing error hides at the top of the stack too. Ask most teams who owns gold and they name the reporting team, on the reasonable-sounding grounds that gold is where the dashboards read from. But gold is dimensional modeling: fact grain, conformed dimensions, a deliberate strategy for history. The reports live above it, on a semantic layer of measures and business-friendly names. Collapse those two into one box and you have quietly handed the dimensional modeling of your business to whoever built last quarter’s dashboard.
Regardless of stack. The grid is the same grid on Databricks, on Snowflake, on Microsoft Fabric. No platform choice adds a steward to your program, and none of them frees an hour of your business expert’s calendar.
Why does the silver layer stall when the code is easy?
The usual explanation for a thin silver layer is that the transformations are difficult. They are not. Deduplicating a table, conforming a code list, handling late-arriving records: these are well understood problems with well understood solutions, and your engineers can do every one of them. The Databricks glossary asks for data that is “matched, merged, conformed and cleansed”, and every one of those verbs is mechanically easy and organizationally expensive.
What silver actually needs is a decision, and the people who can make it have the least available time. Somebody has to say that billing’s account and support’s login are the same customer. Somebody has to say which system wins when the two disagree, write that ruling down, and then hold the line the week two departments count differently. None of that is an engineering problem with a technical answer waiting to be found; these are business decisions, and the grid shows exactly who they belong to: the steward who is half of somebody’s job, the business expert who gives you an hour every two weeks, the modeler shared across three programs.
Three suns and no anchor
There is a name for a system of massive bodies with nothing to anchor them. In Liu Cixin’s novel The Three-Body Problem, a planet orbits three suns, and that single fact makes its sky unpredictable forever, because three bodies pulling on each other produce chaos no formula can tame. Build bronze, silver, and gold without an agreed model of the business and your lakehouse inherits the same physics.
The project was supposed to start before bronze. Somebody was meant to define what the business means by customer, order, and account: the conceptual model, the working vocabulary, the modelers’ bridge from chapter 1. That work is the first thing cut, because bronze does not need it. Then silver arrives, and its job sounds mechanical, integrate and conform the data, until you ask the only question that matters: conform it to what? Without an agreed model there is no target shape, so each pipeline improvises its own. Bronze drags silver back toward the source structures, gold drags it toward whatever this quarter’s dashboards demand, and every engineer’s private guess about what a customer is adds another mass to the system.
The real lesson of the three-body problem is sensitivity, because tiny differences in starting conditions compound until prediction fails. A definition guessed slightly wrong in silver gets joined, aggregated, and re-aggregated until gold serves two revenue numbers to the same meeting, and nobody can say which one is right, because right was never written down. When the chaos becomes unbearable, data teams do what the novel’s civilizations do: they rebuild. The second warehouse, the third lakehouse, better technology every time, the same missing model every time, and the same chaos wearing newer file formats. The industry calls that loop replatforming, but it is the same sky.
The rename pass
Here is how the stall looks from inside, because it never looks like a stop. The work routes around the missing decisions. Each pipeline improvises a local answer, because a local answer unblocks the ticket and a meeting does not. On the slide, the architecture still looks like a medallion. Underneath, silver has quietly become a rename pass over bronze: the same source-shaped structures with friendlier names, and a patchwork of views stitched over the top to gloss over the agreement nobody made.
Name what that leaves you with, which is a replication service. You have copied your operational systems into a lakehouse with better file formats and a fresh coat of medallion vocabulary, and copying is not integrating. The cost lands the first time someone asks a question that spans business units. How many customers do we have, and which of them buy from both product lines? The platform has no answer, because the answer never lived in any system you copied.
None of this is a new disease. Bill Inmon defined a data warehouse in four words: subject-oriented, integrated, time-variant, non-volatile. Three of the four still get built as a matter of course, and integrated is the one the industry quietly let go. Kimball’s conformed dimensions tell the same story from the other direction. Those disciplines did not stop being right, they stopped being convenient, and the tooling drifted toward the convenient side, where everything can be inferred from sources and nothing has to be agreed. The industry has started saying this out loud. Practitioner essays now argue that the medallion is a communication device rather than an engineering blueprint, that it is not data modeling at all, and even Databricks’ own summit hosted a session asking what is wrong with it. So the diagnosis is spreading. What is missing is a method, and the method is the rest of this book.
Staff the handshakes, record the decisions
The reflex fix is structural: stand up a bronze team, a silver team, and a gold team. That rebuilds the silo the medallion was supposed to dissolve, and now tickets get thrown over two new walls instead of one. Staff the boundaries instead. There are three of them, and each has its own guest list.
- Source to bronze. The source owner and the data engineer agree on schema, keys, change capture, freshness, and what happens when the source changes shape without telling anyone.
- Bronze to silver. The engineer, the modeler, the steward, and the business expert agree on entities, business keys, source precedence, duplicate handling, and history. This is the highest-interaction boundary in the architecture, and it is also the one most programs never schedule.
- Silver to gold. The modeler, the analytics engineer, and the business owner agree on grain, dimensions, measures, and how much history the business actually needs. This handshake runs backwards as often as forwards. “I need customer segment as it was on the order date” is a gold requirement that only silver can satisfy, and with no return path it gets solved inside a report, once, badly, and then solved again next quarter by somebody else.
Metadata to capture. Every decision the bronze-to-silver handshake produces is a recordable fact rather than tribal knowledge: which source records count as the same customer and why, which system wins when two disagree, how duplicates are resolved, how much history is kept and at what grain. Written down where the work can read them, those rulings become the thing silver conforms to. Left in the meeting, they evaporate, and the next pipeline guesses again. Chapter 5 turns this into a working discipline.
The people part. You cannot hire the grid, and the goal was never to hire it. The goal is to spend the scarce hours you get, the steward’s afternoon and the business expert’s hour, on the decisions only those people can make, and to stop burning those hours on plumbing. Read that way, the involvement grid stops being a hiring plan and becomes a meeting schedule.
So the silver layer fails for one reason wearing many costumes: decisions nobody was scheduled to make get made anyway, by default, at the keyboard, and unrecorded. The fix is not a bigger platform, and it is not more heroic engineering. It is agreeing the business language before you store anything, knowing what your sources actually hold, and recording the mappings between the two, which are chapters 3, 4, and 5. First on the agenda is the question this chapter kept circling: which system wins when two of them disagree about a customer.