Speak before you store

In this chapter

• Silver conforms to a model people write down first. The business’s agreed language, recorded before anything is stored.
• A usable model is small and has rules. Six kinds of fact, nothing about platforms, and three rules that keep it honest.
• The model comes out of people. A meeting settles it, documents feed it, and sources only witness it.
• A naming standard has to run. Ordered rules a newcomer or a machine can apply without a question.

What does your silver layer conform to? The official guidance never answers. Microsoft’s medallion guidance for Fabric asks silver to fix errors, standardize formats and remove duplicates without ever saying against what.

People answer the question by writing down the business’s agreed language before anything is stored: its entities, attributes, relationships and names. That record is a conceptual model, which plenty of teams call the business model. It comes first, it lives outside every platform, and it answers the first question any data raises: what does this data mean?

So it isn’t documentation, which records a system that already exists. It’s what your architecture is made from. Silver conforms to it, every mapping from a source ends in it, and it’s part of what any generator must be told before it writes a line.

Can AI infer your business model from the schemas?

The tempting shortcut is to let the machines write it. Point an AI at your source schemas, ask for a business model, and you’ll get your source schema with better labels. It couldn’t be anything else, because the schema was all you gave it to read.

That isn’t the AI’s failure. The schema was never trying to explain your business. A schema records how an application persists something, not what it means.

You may have three tables with customer in the name: a billing account, a login, and what your sales team means by the word. Which one does finance count as a customer? None of them records it. That answer lives in a glossary, a requirements document and a two-year argument, and no engine can extract what was never persisted.

So the model has to be spoken before it can be stored.

That sounds expensive until you notice your business expert’s scarce hours get spent either way: in a 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 modest, boring and decisive. It holds six kinds of fact.

• Entities, the named business concepts, each defined in words the business will sign. Define the customer your organization argues about in meetings, not the textbook one.
• Attributes, the facts recorded about each entity, named and defined in business language. Definitions sit on attributes, not columns. So a renamed source column costs a mapping, not a meaning.
• Relationships that read as sentences. Customer places Order. Read aloud in its direction, each must be something your business would say, or you’ve caught a misunderstanding early.
• Synonyms, recorded rather than resolved. Keep one preferred term and the rest as aliases. That way, when two departments use different words for the same thing, the model already knows.
• What kind of thing each concept is. It’s an event, which happens, or a concept, which simply is, and it answers one question: who, what, where, when, why or how. That’s its category.
• How the business tells one occurrence from another. An order number or a membership number tells them apart. That’s the business key. An honest flag that none exists yet is just as valuable.

Categories let a template, a reviewer or an AI treat an Order differently from a Customer without being told twice.

Notice what isn’t on the list: data types, indexes, load schedules, history strategies, table designs, platform names. Let one in and you’ve coupled your business language to a system. The language dies with it.

Three rules keep it honest

Leave a workshop’s notes undisciplined and every capitalized word becomes an entity, while order status turns up as a thing of its own. That’s noun soup. Three rules prevent it. Because they’re written down, they also stop a machine guessing at the answer later.

The first failure is a fact filed as the wrong kind of thing. So everything you learn about a concept is exactly one of three kinds. Identity is how the business tells occurrences apart. A relationship is a verb phrase pointing at another concept. Context is a descriptive fact about the concept alone. Sort in that order every time, and order status lands as a fact about the Order. That’s the sorting rule.

The second failure is every happening becoming a concept. A happening earns concept status only when the business names it and identifies it separately, as a Payment by its payment reference or a Flight by its flight number. A happening nobody identifies is a relationship between the concepts it involves. Statuses such as placed, confirmed and shipped are states, never concepts. That’s the happening test.

The third failure is the invented key, manufactured from the concept’s name because nobody named an identifier. So a business key has to be quoted by the business or clearly implied by what it says. When it isn’t, you flag the gap. That’s evidence for keys.

A flagged gap is a work item, while 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. So model review becomes a checklist instead of a matter of taste.

None of this is new. Lawrence Corr’s BEAM method runs people-first modelstorming aimed at the dimensional gold layer. John Giles has long argued that Data Vault work must start from a conceptual model. And Ensemble Logical Modeling, from Remco Broekmans’s From Stories to Solutions, supplies the separation the sorting rule 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 got settled and the model walked out in five people’s heads. The transcript, filed as minutes, was source material all along.

This book’s worked examples come from one demo dataset: Maluga, an outdoor-living retailer, and its garden webshop, Willibald. Willibald’s orders also arrive from a roadshow, in a separate file with one row per product line.

In one nine-minute meeting, a domain expert, an architect and an engineer settle 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 is membership, the other the role of contact person, and they answer different questions. The distinction is load-bearing. Orders placed by a club’s contact person are attributed back to the club.

Merge the lines and the revenue report goes quietly wrong for months.

Figure 3.1: the two lines every new reader wants to merge. One says Jane is a member of the club, the other says Jane is the person the club put forward to deal with the company.

The same meeting shows the rule behind evidence for keys holding under pressure. The club record carries three discount fields nobody can define. Instead of inventing names, the room flags the gap and logs an open question for the business. And nobody there has read a modeling book.

Once your team knows the conversation will drive a conceptual model, you run it differently. You push for precision while the people who hold it are in the room. Is that a role or a membership? Which address do we mean? The transcript becomes the specification the meeting was always trying to write.

Who has to be in the room? The meeting needs a business expert who owns the meaning, someone who knows what the data holds, and someone running the sorting rule and the happening test in real time.

An hour here saves a sprint of keyboard guessing later.

Documents feed it, sources witness it

Much of your organization’s language is already written down in glossaries, requirements documents, vendor data dictionaries and domain notes. Treat those as governed inputs, versioned and re-read every time the model is worked on, not pasted once into a prompt. A definition your team argued its way to deserves to be read, not guessed from a column name.

Figure 3.2: the same fact traveling. Panel one, the meeting transcript: club membership distinguished from the club’s contact person, in a source whose language is German. Panel two, the glossary: a Gardening-Club Partner entry defined in business language, with the source term VereinsPartner recorded as an alias. Panel three, the entity record: Club Partner, synonyms VereinsPartner and Member Partner registered rather than erased, technical name CLUB_PARTNER derived by rule.

Sources come last, and they arrive as witnesses. They can truly say which concepts show up in practice and which identifiers get used. Cross-examine them and map what survives into the model.

But a witness doesn’t hold the pen. The business does.

Could someone who joined yesterday run your naming standard?

Naming is part of the model, not a cosmetic pass at the end. Every concept and attribute carries a business name people say in meetings and a technical name the platform carries, plus registered synonyms. The naming standard turns the first into the second. That’s where most standards fail.

Most need judgment at some step, so one business name can come out two ways. And when the order of the rules lives in two places, the copies drift until your documentation describes a name no generator ever produced.

The fix 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 in a fixed order, abbreviations first, then casing. Define that order once and apply it everywhere. Then Club Partner becomes CLUB_PARTNER by rule, not by whoever typed it first. That’s an executable naming standard.

The test is mechanical. Hand the standard and ten new attribute names to someone who joined yesterday, or to a machine. If the technical names come back without a question, you have a standard. If any step needs judgment, you have a poster, a rule on the wall that nothing can execute. It won’t survive the first real load of source columns.

The cheapest deliverable you will ever ship

Count the platform decisions above. There are none. A conceptual model costs a handful of well-run meetings. That makes it the cheapest deliverable in your program and the longest-lived. Platforms come and go underneath it. The agreed definition of a customer outlives them all.

The people part	A business expert who owns the meaning, someone who knows the data and someone running the method agree the model, and the business signs each definition.
Metadata to capture	Record every entity with its definition and who signed it, its attributes, synonyms and preferred term, category, relationships and business key (or its flagged absence), and the naming rules in order, where the work can read them.
Regardless of stack	The conceptual model needs no engine, file format or license.

In DeltaVault today

DeltaVault, our metadata catalog, draws your conceptual model as a live diagram on each model’s Canvas tab. You double-click empty canvas to add an entity and drag from one entity to another to draw a relationship, naming the role it plays. Entities carry categories from your organization’s own set, and each category says whether it is an event or a concept and which question it answers.

Click an entity to open its side panel, where you edit its attributes (business and technical names, descriptions), its synonyms and its tags. The technical name follows the business name through your naming convention until you set one yourself. A definition stays Draft until someone clicks Approve definition, which records who approved it and when; any later edit returns it to Draft.