Why this is the most useful 45 minutes in the track
You will never write the SQL. You will, several times a quarter, sit in a room where two competent teams present two different numbers for the same word, and you will be expected to decide which one is right. Almost every time, neither team is wrong and neither is lying. They are counting different rows. This session hands you the vocabulary to say that out loud, and the two questions that resolve it while everyone is still in the room.
The examples all come from this course's own Bazaar dataset: a multi-merchant marketplace with 12 merchants and 90 days of trading, 2026-04-01 to 2026-06-29, in SGD. Every number quoted here was produced by running the code the builder track ships, so you can check any of them. The point is not the marketplace. The point is that the numbers disagree in exactly the way your own numbers disagree.
"One row is one ___" 12 min live
Grain is the answer to one question: what does a single row of this table represent? Not what the table is called. Not what it is used for. What one row is. A table whose grain is "one product line on one order" and a table whose grain is "one order" look almost identical in a screenshot and answer completely different questions. Kimball put grain first in the design sequence for a reason: choose it wrong and every measure built on top inherits the error.
The leader's use of this is narrower and more powerful than the designer's. You do not need to know how the table was built. You only need to be able to ask the question, and to notice what happens when nobody in the room can finish the sentence in one clause. If the answer needs the word "and", you are looking at two tables that got merged, and every total drawn from it is suspect.
LiveThe one question that audits a data team4 min▶
Point at any table, dashboard tile or extract and ask: "one row is one what?" You are not testing knowledge. You are testing whether the sentence exists at all. Four responses, four different diagnoses:
- An immediate one-clause answer. "One row is one product line on one order." Healthy. The grain was a decision, it was written down, and the person in front of you knows it. Move on.
- A confident answer that needs "and". "One row is one order and its payment." That is two grains in one table, which means every sum of money in it is at risk of double counting. This is the single most common shape of a broken revenue number.
- A pause, then a look at the columns. The grain is being reverse-engineered in front of you. It is inferable but undocumented, which means it will be inferred differently by the next person. Cheap to fix: ask for it in writing.
- "It depends what you filter on." The grain changes with usage. Nothing built on this table can be trusted without reading the query, and no two consumers will read it the same way.
You do not need a follow-up question. The quality of the first answer tells you more about the maturity of the data function than any tooling review will, and it takes eight seconds.
LiveWhy grain outranks every other data decision3 min▶
Grain is chosen once and inherited forever. A tool migration does not change it. A dashboard rebuild does not change it. Rewriting the pipeline in a fashionable framework does not change it. It is the lowest-level statement in the stack, so every number above it carries whatever it says.
- It fixes what is countable. If the grain is one order, you can never report per-line discounting without going back to the source. Whole categories of question are decided by the grain, before anyone has asked them.
- It fixes what is addable. Money at line grain adds up cleanly. A rate or an average never does, at any grain. Session a2 priced the rework; this is where the rework comes from.
- It fixes who can join to whom. Two tables at different grains cannot be joined without inflating one of them, which is the third collision in Part 2 and the most expensive.
Inmon and Kimball spent a career disagreeing about warehouse architecture, and agreed completely about this. The argument between the normalized core and the dimensional mart is really an argument about who owns change. Neither school tolerates an undeclared grain, because neither can function with one.
Self-studyGrain sentences for four tables you probably have3 min read▶
Read these as templates and try them on your own equivalents. The pattern is always a single noun phrase with no conjunction.
- Sales lines: "one row is one product line on one order." Not "one sale". A sale is ambiguous between the order and the line, which is why the word should not appear in a table name.
- Payments: "one row is one payment attempt." Not "one payment". Bazaar has 1,060 attempts behind 985 orders, so the difference is 75 rows of retries and refunds that a leader usually wants to see, not hide.
- Carts: "one row is one cart." Not "one shopper" and not "one session". Bazaar has 2,229 carts, and one shopper with three carts appears three times, which is correct and needs saying.
- Merchant reporting: "one row is one merchant on one day." A daily table's grain has two parts and that is fine, because the parts are the keys, not two different things being counted.
The naming discipline that keeps these sentences stable across a team, and the question of who is allowed to change one, belongs to session a5 on naming standards and ownership. Here you only need to be able to demand the sentence.
The three classic collisions 7 min live
Grain errors do not announce themselves as grain errors. They arrive as a disagreement about a business number, and the debate that follows is usually about the business rather than the data. There are three shapes, they cover the large majority of what you will see, and each has a sound you can learn to recognise from the chair.
| Collision | What it sounds like in the meeting | What it does to the number | The fix you ask for |
|---|---|---|---|
| 1 · Counting lines as orders | "Volume is up strongly but revenue per order is flat, and nobody can explain it." | Bazaar June: 481 reported against 327 real orders, a 47% overstatement. It moves with basket size, so it looks like a trend. | Count distinct orders, not rows. State the grain on the tile. |
| 2 · Averaging an average | "Finance has one basket size and marketing has another, and both come from the same warehouse." | Bazaar AOV is 116.93 from the two totals, or 80.68 if line values are averaged instead: a 31% understatement. | Recompute the ratio from the two sums at the grain you need. Never average a ratio. |
| 3 · Adding across two grains | "The reconciliation is off by about eight percent and we have been chasing it for three weeks." | Joining Bazaar's sales table to its payments table lifts revenue from 111,906 to 121,003. Every retried card duplicates its own order lines. | Aggregate each side to a common grain first, then compare. Do not join two transaction tables. |
LiveHow to spot each one from the chair4 min▶
You are not going to audit the query. You are going to listen for a pattern and then ask a specific question.
- Counting lines as orders. The tell is a volume metric rising while a per-unit metric stays flat, with no product or pricing change to explain it. Ask: "is that count of orders or count of rows?" If the answer takes more than a sentence, it is rows.
- Averaging an average. The tell is two teams with the same word and different numbers, both sourced from the same warehouse, differing by tens of percent rather than a rounding error. Ask: "is that computed from the two totals, or is it an average of the per-row values?" Bazaar's 116.93 against 80.68 is what a 31% version of this looks like.
- Adding across two grains. The tell is a persistent small reconciliation gap that resists explanation and moves month to month. Ask: "which two tables were joined to produce this, and what is the grain of each?" Two tables of events joined directly is always wrong, and the inflation is the shape of the retry behaviour, not of the business.
Self-studyWhy the fix is cheap and the discovery is expensive3 min read▶
Every one of these three is a one-line correction in the query that produces the number. That is the uncomfortable part. The cost is never in the fix; it is in the months of decisions taken on the wrong number, and in the credibility the data team spends proving the correction is not itself the error.
Which is why the leadership intervention is not "find the bugs". It is "make the grain a declared, visible property of every number we quote". A grain that is written next to the number cannot silently disagree with another number. A grain that lives in somebody's head will.
The mechanism for that declaration is the metric definition in Part 3, and the ownership rules that keep it honest are session a5. What to buy so the declaration is enforced rather than requested is session a4, immediately after this one.
A metric definition is a governed object 6 min live
"One number, one meaning" is a slogan until the meaning is written down in a form that cannot drift. A metric definition needs five fields, and most organisations have two of them. The two they have are the name and something resembling an expression. The three they skip are the grain, the owner and the caveat, and the caveat is the one that prevents the most damage.
This course's own semantic layer carries 13 metric definitions, and every one of them has an expression, a grain and a caveat. That is not thoroughness for its own sake. It is what took an AI analyst from 0 of 20 standard business questions answered correctly to 20 of 20 on the same data. Nothing about the tables changed. The definitions changed.
LiveThe caveat field, and why it is always the one missing4 min▶
The caveat is one sentence saying what the number is not for. It is omitted for a reason that is worth naming out loud: writing it feels like admitting a weakness in your own work, especially when the audience is the executive who funded it. So the field goes blank, and the weakness gets discovered later by somebody with less context and more urgency.
Here are four real caveats from this course's own definitions. Read them as a genre. None of them is an apology, and every one of them prevents a specific, predictable error:
- On order count: counting all rows counts lines, not orders. This is the most common error a text-to-SQL agent makes, so it is written where the agent will read it.
- On average order value: never average an AOV. Recompute it from the two sums at whatever grain the question needs.
- On decline rate: report the attempt count beside it. Below roughly 30 attempts it is noise, which is why the 18.2% slice built on 11 attempts is not an incident.
- On abandoned cart value: it is list value, not lost revenue. Most of it would never have converted, and treating it as recoverable has funded more bad projects than almost any other number.
Notice that the last one is not a technical caveat at all. It is a caveat against a business inference, and it belongs to the metric because the metric is what invites the inference. That is the leadership contribution to a definition: engineers write the expression and the grain, and the person who has watched the number be misused writes the caveat.
LivePublish definitions as data, not as a page3 min▶
Most organisations publish metric definitions as documentation: a wiki space, a glossary deck, a spreadsheet somebody maintains. Every one of those has the same defect. There is no mechanical connection between the prose and the query that runs, so the two drift apart the first time the query is edited, and nothing detects it. Documentation that can be wrong without failing is not governance, it is reassurance.
The alternative is to hold the definitions in the warehouse itself, as a table beside the data they describe. That single change buys you four things:
- One source for every consumer. The BI tool and any AI analyst read the same row. They cannot disagree, because there is only one place to read.
- Testability. A definition that exists as data can be checked in the same run that builds the warehouse. A metric with no caveat, or a metric whose grain does not match its source, becomes a build failure rather than a discovery.
- Discoverability at the moment of need. Nobody opens the wiki while building a slide. A definition that sits next to the number gets read.
- Machine readability. This is the whole reason the same agent went from 0 of 20 to 20 of 20 on this dataset. The category of tool that does this properly is the semantic layer, which is a purchase decision, and that is session a4. What to fund specifically for agent accuracy is session a6.
Dehghani's framing is useful here even if you never adopt data mesh: treat the definition as part of the product, not as commentary about it. A product ships with its interface. Commentary is optional, which is precisely the problem.
Self-studySynonyms: the cheapest accuracy win available2 min read▶
Your business does not say "net_revenue". It says revenue, sales, topline, GMV, take rate, basket size, order count, failure rate, checkout conversion, lost revenue. Each of those maps to exactly one governed metric, or it maps to nothing and needs a definition of its own.
Writing that mapping down takes an afternoon and it removes a guess from every consumer, human or machine. It is also a genuinely political document, because a few of the mappings will be contested. "Lost revenue" mapping to abandoned cart list value is the kind of entry that a marketing team and a finance team will read very differently, and having that argument once, in writing, is enormously cheaper than having it every quarter in a review.
Where synonyms become a standard rather than a helpful list, and who is allowed to add one, is session a5.
The blank-caveat workshop ★ 12 min · run this with your own team
This is designed to be run in your own next team meeting, with your own metrics, in about 20 minutes. It needs a whiteboard and no tooling. The finding is never "our team is careless". The finding is always which two or three metrics are being quoted daily by people who cannot state what they mean.
Name the three most-argued metrics. Not the three most important. The three that have caused a disagreement in the last quarter. Ask the room and take the first three that get nodded at.
Give each one a single line with five fields. Name, expression in plain words, grain, owner, caveat. One line each, out loud, filled in by whoever quotes the metric most often rather than whoever built it.
Watch which lines cannot be completed. Do not help. Silence on a field is the entire result of the exercise, and the field that goes blank is nearly always the caveat, with grain a close second.
Assign each blank field to one named person with one date. Not a workstream. A person and a date, for one sentence. If a blank cannot be assigned, that metric has no owner, which is a larger finding than the blank.
LiveThe prompt, a good answer, and the failure mode to listen for6 min▶
The prompt, read aloud: "Pick our three most-argued numbers. For each one, I want a single line: the name, what it means in plain words, one row is one what, who owns it, and one sentence on what it must not be used for. Whoever quotes it most does the talking, not whoever built it."
What a good answer sounds like: "Average order value. Settled revenue divided by settled orders. Grain is the order line, so it has to be recomputed from the two sums rather than averaged. Owned by the analytics team. And it must not be averaged across weeks or merchants to get a bigger AOV, which is the mistake we made in the March pack." That is roughly 25 seconds, it contains all five fields, and the caveat cites an actual incident rather than a hypothetical.
The failure modes to listen for:
- The tool answer. "It is whatever the dashboard shows." That is not a definition, it is a location. The follow-up is "and if two dashboards show different values, which is right?"
- The conjunction. Any grain sentence containing "and" is two grains. Write both halves on the board and ask which one the number is summed over.
- The confident caveat-free answer. The most dangerous response in the room. Someone states the metric fluently and says there is nothing to warn about. Push once: "so if I put this in a board pack next to last year, nothing breaks?" The pause after that question is the caveat.
- The deferral. "The data team would have to check." Fine for the expression, never fine for the caveat. The caveat is written by whoever has seen the number misused, and that is usually the person in the room, not the person who built the table.
The 31% argument that was never about revenue. On Bazaar's own data, average order value is 116.93 SGD computed from the two totals across 957 settled orders, and 80.68 SGD if the per-line values are averaged instead. Two teams presenting those numbers will spend an hour arguing about pricing, discounting and merchant mix, because both numbers are defensible and both are drawn from the same warehouse. Nobody is wrong. There was never a disagreement about revenue at all: there was one undeclared grain and one missing caveat, worth 31% of the headline number.
Self-studyHow to score the workshop without embarrassing anyone2 min read▶
Count filled fields out of fifteen, three metrics by five fields, and put the number on the board. Nothing else. A score of nine or ten is normal and healthy for a team that has never done this. A score of fifteen on the first attempt usually means the definitions were read off an existing governed table, which is the best possible outcome and worth saying so.
Re-run it in a quarter with the same three metrics. The score is a genuine maturity measure and it costs twenty minutes, which makes it one of the very few data-governance metrics that does not itself need a caveat about its denominator.
The meeting that ends a revenue disagreement ★ 5 min · the script
Two teams, two revenue numbers, and a calendar invite that says "align on revenue". These meetings routinely run for an hour and end in an action item. Run this instead. It takes minutes, because the disagreement was never about revenue.
Get both numbers on the board first, to the cent. Before any explanation. People argue about causes long before establishing what the two figures actually are, and about a third of these meetings end here, when the two numbers turn out to be for different date ranges.
Ask each side for its grain. One row is one what. Not which table, not which tool. If the two grains differ, you have found it, and the rest of the meeting is deciding which grain answers the question that was asked.
Ask each side for its filter. What was excluded, and what date field was used. Settled versus attempted, order date versus payment date, refunds in or out. On Bazaar, 985 orders against 957 settled is a 28-order gap that shows up as a revenue difference and has nothing to do with revenue.
Write the winning definition down before anyone leaves. Name, expression, grain, owner, caveat, in the room. If it is not written while the argument is fresh, you will hold this meeting again next quarter with the same two teams.
LiveThe two questions, and what each answer tells you4 min▶
The prompt: "Before either of you explains anything, I want two things from each side. One: one row is one what. Two: what did you filter out and which date field did you use. Then we will see whether we have a disagreement."
What a good answer sounds like: "One row is one order line. I filtered to settled payments only, using the order date, refunds excluded." The other side: "One row is one payment attempt. I included refunds, using the settlement date." Both are correct work. They answer different questions, and now the room can pick which question was asked, which takes a minute rather than an hour.
The failure modes to listen for:
- "It comes from the certified dashboard." A provenance claim standing in for a definition. Certification tells you a number was blessed, not what it means. Ask the grain question again, unchanged.
- An explanation of the business instead of the data. "Their number is lower because they do not account for the merchant mix." Possible, but you asked for a grain. Return to the question until you have both grains, then let the business explanation be tested against them.
- Both sides quoting the same grain and the same filter, with different numbers. Now you have a genuine defect, and it is worth escalating properly. This is rare, and this script is what makes it identifiable as rare.
- Agreement to "take it offline and reconcile". The default outcome, and the wrong one. Two grains and two filters can be stated in ninety seconds by people who know their own work. If they genuinely cannot, that is the finding to act on.
Six questions to ask your data team 4 min live
Each of these is short, neutral and hard to deflect. The value is not in the answer being right. It is in how long the answer takes, and whether it is read from something or reconstructed on the spot.
| Ask this | Why it works |
|---|---|
| "For our top revenue tile: one row is one what?" | It is the fastest audit available and it cannot be answered with a process description. A fluent one-clause answer means the grain was a decision. A pause means it is being inferred, and it will be inferred differently next time. |
| "Where does a person go to find out what a metric means, and is that the same place the query reads?" | Separates documentation from governance in one question. If the answer is a wiki, the definition and the query can drift apart with nothing detecting it. If it is a table in the warehouse, drift becomes a build failure. |
| "Show me a metric definition that has a caveat written in it." | Asking whether caveats exist gets you yes. Asking to see one gets you the truth. This is also the question that reveals whether the caveat field exists at all, or is merely encouraged. |
| "Which two numbers in this business are known to disagree, and do we know why?" | Every organisation has a pair. A team that can name theirs and explain the grain difference is in control. A team that says none disagree either has not looked or is not being told. |
| "Do any of our reports join two event tables together?" | Goes straight at the most expensive collision. Sales joined to payments, orders joined to shipments, sessions joined to transactions: all inflate. This is the question that would have saved 9,097 SGD of invented revenue on Bazaar. |
| "Does every rate on our dashboards show its denominator?" | A yes/no question with a nearly free fix and a large payoff. It is what separates a real 18.2% decline incident from two failures out of 11 attempts, and it stops the whole class of alarms raised on tiny slices. |
Self-studyWhat good answers look like, and what to do with a bad one3 min read▶
A good answer to any of the six is short and cites an artifact: a table, a file, a column, a specific incident. A weak answer describes a process ("we review definitions in the governance forum") or a tool ("it is all in the BI layer"). Neither is a lie, and neither answers the question.
When you get a weak answer, resist the instinct to escalate. The useful move is to ask for the smallest possible artifact by a date: one metric, five fields, one line, next Friday. Grain and caveat discipline spreads by example rather than by mandate, because the first person who writes a good caveat gives everyone else a template, and templates travel faster than policies.
Try it yourself - this week ◐ 30-40 min total
- Open the dashboard you look at most and pick the top tile. Write its grain sentence yourself, in one clause, with no conjunction. If you cannot, send exactly that question to whoever owns it and see how long the reply takes.
- Write the caveat for the number you personally quote most often to your own board or leadership team. One sentence on what it must not be used for. You will find this harder than expected, and that difficulty is the point of the exercise.
- Find one rate on one of your dashboards that is displayed without its denominator. Ask for the count to be printed beside it. It is close to free and it retires a whole category of false alarm.
- List the words your business actually says for money: revenue, sales, topline, GMV, take rate. Map each to one governed metric. Note which two entries somebody will contest, and book that argument once, deliberately, rather than every quarter by accident.
- Run the blank-caveat workshop from this page at your next team meeting, and write down the score out of fifteen. Bring it to a4, because it is the strongest evidence you will have about which category of tool you actually need.
Sources covered
The leader track teaches the judgement half of the standard modeling literature: the arguments a leader has to referee, without the mechanics. The full source map, including what is deliberately out of scope, is in materials/official-course-map.md. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Sales reports 481 orders for June. Finance reports 327. Both used the same warehouse and the same date range. As the person in the chair, what is your first move?
A gap this large between two competent teams on identical data is almost never a defect. On Bazaar's June figures, 481 is the count of order lines and 327 is the count of orders. Asking for the grain resolves it in the meeting; asking for a reconciliation books another meeting and produces the same answer three weeks later.
2 · A metric definition arrives with a name, an expression, a grain and an owner. The caveat field is blank. What have you actually been handed?
Four fields is real progress and worth acknowledging. But the caveat is the only field addressed to a future reader who is about to misuse the number in good faith: do not average this AOV, read the denominator on this rate, this abandoned value is list price rather than recoverable revenue. Blank means each consumer works it out for themselves, or does not.
3 · Your team has spent three weeks on a reconciliation gap of about 8% that keeps moving month to month. Which question is most likely to end it?
A gap that persists, resists explanation and varies month to month has the signature of a fan-out from joining two event tables at different grains. On Bazaar, joining sales to payments moves revenue from 111,906 to 121,003, about 8%, and the size of the gap tracks the retry rate rather than anything in the business. One question about grain beats three more weeks of investigation.