Why the schema decides everything

If the only artifact that reaches you is the physical one, three things happen, and none of them look like your problem at the time.

• You approve a schema shaped like an export. When nobody writes down the business's own version, the tables end up mirroring whatever file arrived first: a payment provider's CSV, a spreadsheet tab, an app's internal event log. That shape is an accident of who emailed what, and it becomes the shape of every number you are given for the next five years.
• Disagreements become invisible. Two people can agree completely on DECIMAL(12,2) and disagree completely on what a sale is. The physical model has no vocabulary for that argument, so the argument gets postponed to a meeting where it looks like a reporting bug.
• Ownership drifts to the wrong place. The conceptual model is the business's to own, and when the business does not own it the data team invents it by inference. They are guessing at your intent, kindly and quietly, in a language you never see. Inmon's argument about the normalized core is really an argument about this: who is allowed to change the meaning of a thing. Session a5 turns that into named owners and a contract.

The fix is not that you learn DDL. It is that you insist on being shown the first artifact, in the business's own words, before the third one exists. Two paragraphs and a whiteboard photo are enough. If nobody can produce them, that is the finding.

Take one real decision from Bazaar and watch it change hands. A cart is where a shopper puts things they might buy. Does the cart deserve to be a thing the company keeps, or is it screen state that gets thrown away at checkout?

• Engineering has no stake in the answer. Either version ships. Keeping carts costs a little storage; throwing them away costs nothing today.
• You have an enormous stake in it. Bazaar's carts convert at 44.19%. Keep the carts and you can tell the difference between "fewer people wanted to buy" and "checkout broke". Throw them away and both look identical in the revenue line, which means the next bad month sends you to argue with the wrong team.
• The decision looks technical when it is written down. "Do we persist cart state?" is a sprint-planning sentence. "Do we want to be able to tell demand collapse apart from checkout failure?" is a board sentence. They are the same decision.

Evans and Fowler make an argument that sounds like style advice and is not: the words in the model must be the words the business says out loud, and each concept gets exactly one of them. Bazaar's people say merchant. So nothing anywhere is allowed to say vendor, seller, supplier or partner.

The cost of breaking that rule is not aesthetic. Every synonym is a place where two teams can build two slightly different populations and both be sure they are right. "Active sellers" and "merchants with sales" sound like the same group in a meeting and are almost never the same group in a query. You cannot police this from a dashboard; it has to be a standard, with an owner, which is what session a5 builds.

Domain ownership is the other half of the same idea. Dehghani's Data Mesh argues that the team closest to a business domain should own its model and publish it as a product, precisely because meaning degrades every time it is translated by someone further away. You do not need to buy a mesh to take the point: the further your conceptual model travels from the people who live the process, the more of it arrives as guesswork.

A migration is judged on fidelity. The test everybody agrees on before it starts is "the new system returns the same numbers as the old one". That test is exactly the mechanism that preserves a bad model: if the old warehouse counted order lines and called them orders, then a migration that corrects the grain will fail its own acceptance criteria on day one.

• Fidelity beats correctness in every migration plan. Nobody wants to explain a 47% change in the June order count during a cutover, so the wrong definition gets faithfully reproduced and inherits fresh credibility from a new logo.
• The tools get better; the meaning does not. A semantic layer will happily serve a wrong definition to more people faster, with better caching. Session a4 covers what tooling genuinely buys you here, and what it cannot buy.
• The one decision with no natural review point is the one worth reviewing. Contracts get renewed, licences get re-tendered, frameworks get deprecated. Grain has no renewal date. If you do not put one in the calendar, there is not one.

When a proposal arrives, it is usually a mix of tool change and model change, presented as one thing. Two questions pull them apart:

• "If we did nothing about the tool, would this problem still exist?" If yes, you have a model problem, and buying the tool will move the cost rather than remove it.
• "If we replaced this platform next year, which of these decisions would we have to make again?" The ones you would have to make again are tool decisions. The ones that would just carry over are model decisions, and they deserve more of your attention than they are getting, not less.

This is not an argument against tooling. Bazaar's builder track ships real DDL and real transformations, and the platform matters. It is an argument about attention: the tool decision arrives with a vendor, a demo and a deadline, and the model decision arrives with nobody.

A dashboard lands in your inbox with a nice headline number. You have about ninety seconds of attention and no ability to inspect the query. Spend it on two questions, in this order.

• "What is one row of the table behind this?" This tests whether the number has a definition or a vibe. In Bazaar, if the answer to "how many orders in June" is 481, somebody counted order lines; the answer at order grain is 327. That is a 47% overstatement produced without a single mistake in the SQL, and it is invisible on the tile.
• "Who may change this table, and who finds out when they do?" This tests whether the number has an owner. A table anyone may change is a number nobody can promise. Note the second half of the question: an owner who cannot detect a change is not an owner, they are a name in a wiki.

Those two questions cover the two ways dashboards fail leaders: the number never meant what you thought, or the number quietly stopped meaning it last Tuesday. Neither is a BI problem. Both are modeling problems.

A good answer is one sentence, has no "and" in the middle, and mentions a single thing. "One row is one payment attempt." Done.

• "One row is one order and its payment" is two things wearing one row. In Bazaar, gluing the sales and payment facts together reports 121,003 SGD instead of the settled 111,906 SGD, because orders that needed a retry get counted twice. That is 9,097 SGD of revenue that does not exist, from a join that looks completely reasonable in a query.
• "It depends on the filter" means the grain is unstable, which means every comparison across time is suspect.
• "I would have to check" is a perfectly honest answer and a useful finding: the definition is not published anywhere a human can read it. That is the gap session a5 closes with a contract, and the gap session a6 shows is fatal for anything automated.

The prompt, word for word: "Before we discuss the number, I want to understand the row. One row of the table behind this figure is one what? And who is allowed to change that table?"

What a good answer sounds like: one sentence, one noun, no conjunction. "One row is one settled order." Then, without being pushed: "Finance owns the definition, the analytics engineering team owns the table, and it is in the metric doc." A good answer often comes with a caveat volunteered rather than extracted: "note that refunds are handled at the payment grain, not here". Volunteered caveats are the strongest signal you will get that someone has actually thought about the grain.

The failure mode to listen for: the confident restatement. You ask what one row is and you get the metric's name back in a longer sentence ("one row is one revenue record for the period"). That is not a grain, it is a synonym, and it is the single most common way this question gets deflected without anyone intending to deflect. The second failure mode is a room where two people answer differently and then both say "well, same thing really". It is not the same thing; in Bazaar the same "same thing really" is the difference between an average order value of 116.93 and 80.68, a 31% understatement, and both of those numbers came off the same dataset.

The prompt: "Take the last data project you personally approved. Which of the three artifacts did you actually see: the business's own model in business words, the logical model with grain and keys, or the physical schema? If you only saw the third, who wrote the first one down, and where is it?"

What a good answer sounds like: someone can point at an artifact - even a whiteboard photo, a one-page list of entities, a paragraph in a project brief - and name the business person who signed it off. The version of this answer that should reassure you most is unglamorous: "we spent the first two hours listing the things we have and arguing about what a merchant is, and here are those notes".

The failure mode to listen for: "the ERD is the model". An ERD is a picture of the second and third artifacts. It cannot tell you whether the business agreed that a cart is a thing worth keeping, because it only shows the tables that survived that conversation. Also listen for "the model is in the code" or "dbt is the source of truth". Those statements are true about implementation and irrelevant to the question of who decided what a sale means.