Speak before you store | The Data Lakehouse for Everyone

In this chapter

Why the conceptual model is the first deliverable, on any stack.
What a usable model contains, what it never contains, and the rules that keep it honest.
Meetings, documents, and sources: where the model actually comes from.
Naming as ordered, executable rules rather than a wall poster.

Chapter 2 ended on the question that stalls the middle of every lakehouse: conform it to what? The official guidance never answers. Microsoft’s implementation page for the medallion architecture in Fabric asks silver to “fix errors, standardize formats, and remove duplicates” without ever naming the thing it is standardizing toward. This chapter supplies that missing target. Before anything is stored, you agree the business language and write it down: the entities, the attributes, the relationships, and the names. The industry calls that artifact a conceptual model, plenty of teams call it the business model, and both mean the same thing. This book says conceptual model, though the label matters less than the timing. It comes first, it lives outside every platform, and everything else in this book maps into it.

So resist the reflex to file this under documentation. Documentation records a system that already exists, while the conceptual model is what your architecture is made from. The silver layer conforms to it, the mappings in chapter 5 terminate in it, and the metadata contract in chapter 8 serializes it.

Can AI infer your business model from the schemas?

The tempting shortcut is to let the machines write the model. Point an AI at your source schemas, ask it for a business model, and you will get one. What comes back is your source schema with better labels, and that is the only thing it could be, because the schema was the only thing you gave it to read.

That is not a failure of the model. The schema was never trying to explain your business in the first place. A relational schema tells you how an application chose to persist something, not what that something means. You may have three tables with customer in the name: one is a billing account, one is a login, and one is what your sales team actually means by the word. The fact your model needs, which of the three your finance team counts as a customer, was never recorded in any of them. It lives in a glossary, in a requirements document, and in a two-year argument. The semantics that matter most were never columns, and no engine can extract what was never persisted.

So the model has to be spoken before it can be stored. It comes out of people, which sounds expensive until you remember the grid from chapter 2: your business expert’s scarce hours get spent either way, either in a scheduled meeting that produces a recorded model, or at the keyboard, one improvised pipeline decision at a time.

A usable model is smaller than you think

Teams put off conceptual modeling because they picture a cathedral: a wall-sized diagram, a year of workshops, a binder nobody opens. A usable model is nothing of the sort. It is modest, boring, and decisive, and it contains six kinds of fact.

Entities with definitions. Each named business concept carries a sentence or two the business is willing to sign. Not the textbook definition of a customer, but the one your organization argues about in meetings.
Attributes with business names. These are the facts the business records about each entity, named in business language. Because the definition sits on the attribute rather than on any column, a renamed source column costs you a mapping, not a meaning.
Relationships that read as sentences. Customer places Order. Order contains Product. Read each one aloud in its direction and it has to be a sentence your business would actually say, because a relationship that fails that test is a misunderstanding you have caught early.
Synonyms, recorded rather than resolved. Real businesses have synonyms, so record which name is the preferred term and keep the rest as registered aliases instead of forcing a winner. When two departments use different words for the same thing, the model already knows.
Categories. Each concept says what kind of thing it is, either an event, something that happens, or a concept, something that simply is, along with which question it answers: who, what, where, when, why, or how. Categories are what let a template, a reviewer, or an AI treat an Order differently from a Customer without being told twice.
Business keys. These record how the business tells one occurrence from another, such as an order number or a membership number. Just as valuable is the honest flag that no such key exists yet.

Notice what is not on the list: data types, indexes, load schedules, history strategies, table designs, platform names. Those belong to later chapters. Let one in and you couple your business language to a system, and the language dies with the system.

Three rules keep it honest

A model with no discipline degrades into noun soup: every capitalized word in the workshop notes becomes an entity, and order status arrives as a thing in its own right. Three rules prevent that, and because they are written down, they are also what stop a machine guessing at the answer later.

The sorting rule. Anything you learn about a concept is identity, relationship, or context, and never two of those at once. Identity is how the business tells occurrences apart; relationship is a verb phrase pointing at another concept; context is a descriptive fact recorded about the concept alone. Run the sort in that order every time, and order status lands as a fact about the Order instead of a concept of its own.
The happening test. A happening earns concept status only when the business names it and identifies it separately: a Payment tracked by a payment reference, a Flight tracked by a flight number. A happening nobody identifies is the relationship between the concepts it involves, and statuses such as placed, confirmed, and shipped are states, never concepts.
Evidence for keys. A business key has to be quoted by the business or clearly implied by what it says. When no identifier is named, flag the gap rather than manufacturing a key out of the concept’s name. A flagged gap is a work item; an invented key is a defect wearing a badge.

These rules are mechanical on purpose. A person in a workshop and a machine reading a transcript can both apply them and reach the same answer, which is what turns model review from a matter of taste into a checklist.

None of this discipline is new. Lawrence Corr’s BEAM method runs people-first modelstorming aimed at the dimensional gold layer, John Giles has argued for years that Data Vault work must start from a conceptual model, and Ensemble Logical Modeling, set out in Remco Broekmans’s From Stories to Solutions, supplies the identity, relationship, and context separation this chapter leans on. Take the discipline from whichever school your team already reads.

The meeting is the model

The most productive modeling session your team ran this week did not happen in a modeling tool. It happened in a meeting, where a real question finally got settled and the model walked out in five people’s heads. The transcript sat there the whole time, filed as minutes, when it was source material.

To see those rules run by actual people, watch a working session. The worked examples in this book come from a demo dataset: Maluga, an outdoor-living retailer whose garden webshop is called Willibald. In one nine-minute meeting, a domain expert, an architect, and an engineer settle the corner of the model where the confusion lives, namely the two lines between Customer and Club Partner that every new reader wants to merge. The ruling is a model in a sentence: one line says Jane is a member of the club, the other says Jane is the person the club put forward to deal with the company. Membership versus role, two relationships answering two different questions. The distinction is load-bearing, because orders placed by a club’s contact person are attributed back to the club, so merging the lines sends the revenue report quietly wrong for months.

Conceptual entity-relationship diagram of Customer, Club Partner, Order, Position and Product, with two distinct highlighted lines between Customer and Club Partner: one for membership, one for the contact person role.

The same meeting shows the key discipline holding under pressure. The club record carries three discount fields nobody can define, and instead of inventing names and letting the guess harden into fact, the room logs an open question for the business. That is the flag-the-gap rule, executed by people who have never read a modeling book.

Once your team knows the conversation will drive a conceptual model, you run the conversation differently. You push for precision while the people who hold it are still in the room: is that a role or a membership, and which address are we actually talking about? The transcript stops being minutes and becomes the specification the meeting was always trying to write.

The people part. The meeting needs three chairs filled: a business expert who owns the meaning, someone who knows what the data actually holds, and someone holding the method, running the sorting rule and the happening test in real time. This is where chapter 2’s scarce silver hours go, and an hour here saves a sprint of keyboard guessing later.

Documents feed it, sources witness it

The meeting is not the only input. Your organization has already written much of its language down in glossaries, requirements documents, vendor data dictionaries, and domain notes. Treat those artifacts as governed inputs: versioned, and re-read every time the model is worked on, rather than as text pasted once into a prompt. A definition your team argued its way to deserves to be read directly, not guessed at from a column name.

One fact moves from meeting transcript through glossary entry to governed entity record, and the German source term survives as a synonym because the business rather than the source holds the pen.

Sources come last, and they arrive as witnesses. Your systems have true things to say about which concepts show up in practice and which identifiers actually get used. Cross-examine them, map what survives into the model, and remember that a witness does not hold the pen. The glossary entry in the figure shows the pattern in miniature: the German source term is kept as a synonym while the concept it names is defined in the business’s preferred language. The source contributed evidence, and the business kept the pen.

A naming standard nobody can execute is a poster

Naming is part of the model, not a cosmetic pass at the end. Every concept and attribute ends up carrying at least two names: the business name people say in meetings and the technical name the platform carries, along with the registered synonyms. The naming standard is the bridge between the first two, and most naming standards fail one simple test, which is that they cannot be executed.

An executable standard is a short stack of ordered rules: which term is preferred when synonyms exist, which abbreviations are allowed (a finite approved list, not a habit), and the derivation rules applied in a fixed order, abbreviations first, then casing. The order matters, because a standard whose order lives in two places will eventually hold two versions of it, and at that point your documentation describes a name no generator ever produced. Define the order once and apply it everywhere. Club Partner then becomes CLUB_PARTNER by rule, not by whoever typed it first.

The test is mechanical execution. Hand the standard and ten new attribute names to someone who joined yesterday, or to a machine, and if the technical names come back without a question, you have a standard. If any step requires judgment, what you have is a poster, and posters do not survive the columns arriving in chapter 4.

The cheapest deliverable you will ever ship

Metadata to capture. Everything this chapter produces is a recordable fact: each entity, its definition, and who signed it, each attribute and its business name, each synonym and the preferred term, each category, each relationship written as a readable sentence, each business key or its flagged absence, and the naming rules in the order they apply. Write them down where the work can read them, because chapter 5’s mappings and chapter 8’s metadata contract consume exactly this list.

Regardless of stack. Read back through this chapter and count the platform decisions. There are none. No engine was chosen, no file format debated, no license bought. A conceptual model costs a handful of well-run meetings, which makes it the cheapest deliverable in your program, and the longest-lived one. Platforms come and go underneath it, while the agreed definition of a customer outlives them all.

That model is half of the agreement your silver layer needs. The other half is knowing what your sources actually hold, because sources drift, surprise, and occasionally lie. Chapter 4 puts the witnesses on the stand.