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

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: the conceptual model, the business ontology, the work of the data modelers. That work is the first thing cut, because bronze does not 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. In the story, this is a stable era, and stable eras end.

Why does silver keep improvising? The chaotic era starts here

Silver is where the three bodies begin to pull. The job sounds mechanical, integrate the sources and conform data in silver, but conform it to what? Without an agreed model there is 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, and nobody can say which one is right, because right was never written down.

In Liu Cixin’s story, civilizations rebuild again and again, each destroyed by a sky it could not predict. Data teams run the same loop and call it lakehouse replatforming: a second warehouse, then a third lakehouse, 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 is the fix, and it is not more engineering: give the medallion architecture layers one fixed body to orbit. The conceptual data model everyone skipped is that sun.

What goes in the business model? A description of the business that holds still, independent of any source system, with 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 does not 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 do not need one: that seam is what DeltaVault was built around.

Start with the business model, which lives on a live diagram inside the catalog as real metadata rather than boxes in a drawing tool. A guided workshop interviews you in plain language and builds a first model to review, and engineering never waits for it to finish. Map & Match proposes which business entity each source table represents and which attribute each column maps to, every suggestion carrying a confidence score and a written rationale. Accept a match for a table nobody has modeled and you get a skeleton entity that carries governance immediately. Classify an attribute once and every column mapped to it inherits the classification.

That metadata is not documentation sitting next to the pipelines: it is what generates them.

  • Bronze stays replication. Nothing changes about landing your sources, so ingestion never blocks on the model.
  • Silver stops improvising. Every accepted mapping from source column to business attribute is a conform rule, so two sources mapped to the same entity integrate the same way by construction.
  • Gold comes back together. Marts are built from the entities and attributes the model already defines, so two teams asking for revenue read the same 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 in one place, transformation code in another, and a catalog that shows up late to document whatever survived. DeltaVault pulls them into one system where the business model sits at the center and bronze, silver, and gold are generated in orbit around it. The model is not a picture of your architecture. It is 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.
  3. Let DeltaVault render the layers.

Chapter 2 of The Data Lakehouse for Everyone is the long form of this argument: Why the silver layer fails.

You do not need a fourth layer or a bigger team. You need a sun. Book a working session and we will model your first domain and generate the Databricks code from it in the same sitting.