Build bronze, silver, and gold without a business model to anchor them and the layers drift apart. Every layer’s meaning then depends on the layers around it, nothing holds still, and small errors compound until delivery stops being predictable. In Liu Cixin’s The Three-Body Problem, a planet orbits three suns, and three bodies pulling on each other produce chaos no formula can tame. The medallion architecture has three bodies of its own, and without a business model your lakehouse inherits the same physics.

Does medallion architecture need a model before bronze, silver, gold?

The project is supposed to start before bronze. Somebody should define what the business means by customer, order, and account. That’s the business model. Data modelers call it the conceptual data model or the business ontology. It’s their work, and it’s the first thing cut, because bronze doesn’t need it.

Bronze is replication, and the source systems have already made every structural decision for you. A team can land two hundred tables without asking what a single one of them means. Ingestion runs, row counts match, the dashboards glow green.

Why does silver keep improvising? The chaotic era starts here

Silver is where the three bodies begin to pull. The job sounds mechanical. You integrate the sources and conform data in silver. But conform it to what? Without an agreed model there’s no target shape, so each pipeline improvises its own. Bronze drags silver 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. We pulled that improvisation apart in what actually lives in a silver layer.

The real lesson of the three-body problem is sensitivity. 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. Nobody can say which one is right, because right was never written down.

Data teams rebuild and call it lakehouse replatforming. They build a second warehouse, then a third lakehouse, with better technology every time, the same missing model every time, and the same chaos wearing newer file formats.

Stability is orbiting one sun

In the story, a stable era arrives when the planet falls, for a while, into orbit around a single sun. That’s the fix, and it isn’t more engineering. Give the medallion architecture layers one fixed body to orbit. The business model everyone skipped is that sun.

What goes in the business model? It’s a description of the business that holds still, independent of any source system, in five parts.

  • Entities: the things the business talks about, such as customer, order, and account.
  • Attributes: the properties each entity has, and the type and format each one carries.
  • Relationships: how the entities connect (an order belongs to one customer, a customer holds many accounts).
  • Definitions: the written meaning of each entity and attribute, so that “customer” has one answer rather than one per pipeline.
  • Ownership: who in the business is accountable for each definition, and who has to agree before it changes.

Define customer once and the rest follows. The system doesn’t settle because you worked harder. It settles because meaning stopped moving.

Put the sun in without stopping the engineers

You already know the objection. Nobody gets a quarter of data modeling workshops before the first table lands. You don’t need one, because neither side has to wait for the other.

Start with the business model as real metadata in the catalog, not boxes in a drawing tool. A workshop in plain language gives you a first model to review, and engineering never waits for it to finish. Mapping joins your sources to that model whichever team arrives first, even for a table nobody has modeled yet. Classify an attribute once and let every column mapped to it inherit the classification.

That metadata isn’t documentation sitting next to the pipelines. It’s what generates them.

  • Bronze stays replication. Nothing changes about landing your sources, so ingestion never blocks on the model.
  • Silver gets a target shape. Each accepted mapping records the business attribute a column means, so two sources that both carry a customer point at one definition, not each pipeline’s guess.
  • Gold comes back together. Marts are built from the entities and attributes the model already defines, so the two teams that took two revenue numbers into one meeting now read one definition.
  • Governance travels with the code. Classifications, ownership, and lineage are attached to the model, so they arrive with the first release instead of six months after it.

Most lakehouse stacks rebuild the three-sun arrangement out of tooling. A modeling tool sits in one place, transformation code in another, and a catalog shows up late to document whatever survived. Pull them into one system instead, where the business model sits at the center and bronze, silver, and gold are generated in orbit around it. The model isn’t a picture of your architecture. It’s the thing your architecture is made from.

So the prescription is short.

  1. Define the entities your business already argues about.
  2. Point your sources at them.

Why the silver layer fails, in The Data Lakehouse for Everyone, is the long form of this argument.

You don’t need a fourth layer or a bigger team. You need a sun.

In DeltaVault, the business model lives on a live diagram inside the catalog, a guided workshop interviews you to build its first draft, and Map & Match proposes the matches that join your sources to it.