Most data teams start with the stack. They ask which lakehouse, which ingestion tool, and whether it can pull the six new sources landing next quarter. That’s the cart. The horse is the conceptual data model, what your business means by customer, by order, by active policy. The horse is usually still standing in the field when the cart rolls off.

The two directions produce different things, and neither one produces the other. Top-down gives you the conceptual data model: business glossary terms, named entities, the units of work that connect them, definitions and classifications. It can’t tell you what data actually exists, which system holds it, or what the columns are called.

Bottom-up gives you schemas, columns, keys, constraints, and the staging tables built on them. Nothing there says what the business means by customer, which grain revenue is counted at, or which definition a column is supposed to satisfy.

Neither side, on its own, answers the question that matters: which source table is which business entity. That’s a mapping, not a sequence.

Starting with the source systems is a habit, not a mistake

Nobody gets this wrong on purpose. Data teams are built out of database people, and the questions they can answer are technical ones. Can this tool read that source? How do we land two thousand objects without the extract falling over? Which layer does this table belong in? Source systems are concrete. You can inspect their schemas and measure their failures.

Business meaning offers nothing so solid. It offers a workshop, three competing definitions of active customer, and a steering group that meets on Thursdays. So the technical work starts, for the simple reason that it can start.

Connections get made, tables get landed, staging gets built. Meanwhile the business side is doing real work of its own, on its own track: the business glossary, the classifications, the concepts the company actually runs on. You end up with two tracks and two vocabularies, and no shared surface between them.

This is the meaning before machinery problem in its most expensive form.

What breaks when the conceptual data model arrives after the warehouse

You find out how far apart those tracks ran the day somebody finally puts the warehouse in front of the business. Every table is there, and every table is correct. But the thing you called Customer turns out to be a billing account. Revenue is counted at the wrong grain. Half the attributes the glossary insists on never made it past staging. That’s months of good engineering, aimed slightly wrong.

Both of the usual remedies cost one team its momentum. Freeze the pipelines until the model is signed off, and engineering sits waiting on a committee. Build now and document later, and data governance spends a year chasing a warehouse it never got to shape.

Somebody always goes second.

Should you model top-down or bottom-up first?

Both remedies treat this as a sequencing problem, a choice between top-down and bottom-up data modeling. It isn’t. Each team should keep working in the idiom it thinks in, and the two should be joined early rather than reconciled late. Our other posts on data modeling take that join further.

That means both sides keep their own front door. Describe how the business works in plain language, and the AI business modeling workshop proposes the concepts the business names along with the units of work that connect them. Each one lands on the model’s own canvas with its reasoning attached, as a node you accept, rename, or dismiss.

Point DeltaVault at a source instead, and source system discovery pulls its schemas, columns, keys, and constraints into a review screen. That screen shows exactly what the import adds, changes, or removes before anything lands.

The join is the part most tooling leaves to a meeting. In DeltaVault it’s a mapping, and the mapping is the deliverable. Map & Match proposes which business entity each source table represents, then which attribute each column maps to, and nothing changes until a person accepts it.

Map & Match works whichever team got there first. If the modelers arrived first, accepting a match is a lookup. If the engineers did, accepting a match for an unmodeled table creates a skeleton entity, marked as derived, that carries governance from that day and waits for the modelers to adopt it.

Alignment stops being a meeting

Once the two sides are hitched, agreement becomes a property of the metadata instead of an outcome of a workshop. Classify the Email Address attribute once. Every column mapped to it carries that classification, across however many landing tables, staging tables, and vault satellites the attribute touches.

You read how far the loop has closed straight off the mappings and definitions your team already authored. So “are we aligned yet” gets answered on a screen rather than in a status report. Naming conventions and modeling invariants run as checks when metadata is committed, and the strict ones stop the commit outright.

The cart and the horse were never a question of order. The question was how to hitch them:

  1. Connect one source.
  2. Sketch the entities your team already argues about.
  3. Run a match between them.