The one-truth problem

Metric drift has exactly three parents, and once you can name them you can diagnose any two-numbers meeting in minutes instead of forty:

• Filters: refunds in or out, test orders in or out, gift subscriptions in or out. Each team picks the filter that matches its job - marketing measures demand, finance measures money kept. Both defensible, never identical.
• Joins: which side tables the query pulls in. Joining orders to campaigns silently drops orders with no campaign; joining to invoices drops orders not yet invoiced. The number changes and nobody typed a wrong digit.
• Refresh times: a 6am dashboard and a midnight dashboard describe different Junes for a day or two every month-end. The gap closes itself later, after the argument already happened.

Uncomfortable but important: Daybreak's two Junes were both computed from the warehouse. The warehouse guarantees both teams read the same clean, typed, historical data - that is real progress, in a1's world this argument would have been about data quality too. But the warehouse cannot stop two analysts from writing two different queries on top of it.

• The warehouse solves "same data": one governed copy, one history, one set of checked inputs.
• It does not solve "same definition": that lives in the queries, and queries are written by people with different jobs.
• So the fix has two halves: a technical half (Part 2) that gives definitions one home, and a human half (Part 3) that gives each definition one owner.

The refresh-time parent deserves its own note because it strikes on a schedule: the first two days of every month, when late-arriving orders, processing refunds, and different pipeline schedules make every dashboard slightly different - then quietly agree again by the 3rd.

• Know your data's "settle time": ask your team how long after month-end the numbers stop moving. Most companies: 2-5 days.
• Timestamp the number, not just the month: "June revenue as of July 2" is a different fact from "June revenue as of July 10". Mature teams label dashboards with refresh time for exactly this reason.
• Cheap policy win: agree that board-pack numbers are cut on a fixed day. Half the drift disappears by calendar alone.

Recall a2: dimensions are the nouns - customer, product, date. A conformed dimension is a noun built once and shared by every fact table in the warehouse. One customer dimension, joined by revenue facts, subscription facts, and support facts alike.

• Why it kills drift: half of metric arguments are secretly noun arguments - two teams with two customer lists, two region groupings, two fiscal calendars. Conform the noun and that class of argument goes extinct.
• What it costs: agreeing on the shared noun takes real meetings - whose region grouping wins, whose customer status names. Pay once, or pay monthly in disputes.
• What to ask your team: "Is there one customer dimension, or does each mart have its own?" One is health; several is a1's frozen checkout waiting to happen, but for trust.

Conformed dimensions share the nouns; the metric layer (your team may say "semantic layer") shares the verbs-with-numbers. "Revenue" gets defined exactly once - refunds out, test orders out, cut at midnight UTC - in one governed place, and every dashboard reuses that definition instead of re-deriving it.

• The shift that matters: analysts stop writing "their version of revenue" and start requesting "the revenue metric". Divergence stops being possible by accident - it now requires deliberately going around the layer.
• Tested definitions: good teams attach automated checks - revenue is never negative, June's total matches finance's ledger within tolerance. Definitions with tests age well; definitions in a wiki page do not.
• What to ask your team: "If I change what counts as revenue, how many places must be edited?" The dream answer is one. Every number above one is a future two-Junes meeting.

The full trust stack, bottom to top - each layer assumes the one below:

• Warehouse (a1-a2): everyone reads the same clean, historical data.
• Conformed dimensions: everyone slices by the same nouns.
• Metric layer: everyone computes the same verbs, from one tested definition.
• Governance handshake (Part 3): a human owns each definition, so the stack survives reorgs, new hires, and strong opinions.

For each board-level metric:

• An owner - a name, not a team. The person who decides what "revenue" means when marketing and finance want different things. Usually a business leader, advised by data. "The data team owns it" means nobody does.
• A written definition - filters, joins, timing included. "Revenue = completed orders minus refunds, excluding test accounts, cut at midnight UTC." One paragraph, versioned, findable. If it changed, you can see when and why.
• A test - a check that runs without a human. The definition is encoded once in the metric layer and monitored: totals reconcile to the ledger, the number never goes negative, yesterday loaded. Trust that renews itself nightly.

What Daybreak actually did after the two-Junes meeting - one 60-minute session, reusable as a template:

• Minute 0-10: listed every metric that had appeared in a leadership deck that quarter. Eleven metrics. Nobody expected it to be that few.
• Minute 10-40: for each, asked Part 1's diagnostic - "what does each version count?" - and made the business call on the spot. Revenue: refunds out, gross demand became its own separately named metric so marketing lost nothing.
• Minute 40-60: assigned one owner per metric and gave the data team a fortnight to encode each definition once, with tests.

Run Daybreak's meeting solo, as a diagnostic on your own company:

• List the metrics in your last board pack. Expect 8-15.
• Score each 0-3: one point each for named owner, written definition, automated test.
• Read the scores: 3 = sleep well. 2 = fine until a reorg. 0-1 on a metric you present = you are one filter choice away from your own two-Junes meeting.
• The follow-up that costs nothing: forward the lowest scorer to your data lead with one line - "who owns this?"