Golden Data

Issue #24 · October 4, 2026

Every Metric Has Two Copies Now. Systems Is Knowing The Morning They Stopped Matching

Two copies of one metric drift apart. The only question is who notices first.

Paul BrownWrites Golden Data from Ogden, Utah5 min read

The Four Skills, part 4 of 4 | Systems

A series on the four skills that matter most for analysts now that frontier models and open-source tooling do the tool-native half of the job. Part 1 showed the warehouses ingesting every measure with equal weight. Part 2 was the morning the copy and the original disagreed, and whose job it was to say which one was right. Part 3 was vision: modeling for the reader who hasn’t shown up yet. This one is systems: thinking in pipelines and drift instead of visuals and refresh. Attention, decisions, vision, systems.

“How would you know if they stopped matching?”

Someone in finance will ask that about the second copy of net new ARR, the one in the warehouse next to the one in your BI tool. Not on the day you build it. Eight weeks later, in the meeting where the two copies disagree and each one is correct in its own language. Part 2 ended on a parity table that “will be green most weeks.” This issue is about what you do with the green.

A dashboard is a picture of a number at one moment. A contract is a promise about the number that can be checked on any morning. Per metric it is a handful of facts: grain, the filter logic in one sentence, an owner, a hash of the code behind each surface, and the last date someone checked. Not a dashboard. A table with a tolerance.

Nothing you already own is that object. dbt’s model contracts are the closest thing in the stack, and the docs are plain about their reach: a contract “defines the shape of the returned dataset,” meaning every column’s name and data type, plus constraints like not_null. Content is the job of tests, after the build. A contract can tell you net_new_arr is still a numeric column. It cannot tell you someone changed a filter from new logos to new logos plus expansions. The meaning lives in a sentence. Nothing compiles a sentence.

What’s actually moving in the market

dbt Labs, September 15 to 18. dbt State is now a metered product of its own, priced at $0.094 per daily active target table: a distinct table or test on which State performs a skip, clone, or test reuse that day. New organizations get 30 days free. The vendor now meters the work it declines to do. For your checks the lesson is narrow. A skipped check is a green that did not run. “Last verified” cannot mean the date of the last build. It means the last day someone compared the two values. I have not run State, so that is the docs’ definition and my inference, not my testimony. The dbt Summit announcement post lists dbt Charts, YAML dashboards in the repo, in public beta, and no new semantic layer feature.

Apache Ossie, September 21. Per a write-up of th the project’s dev list, Chris Eubank of Databricks summarized the community converging on four layers: expression language, relational interface, dimensional interface, ontology. His reason for the care is the contract problem in one sentence: “Given the same model shape, two vendors can return different answers to the same question, and that weakens Ossie as a standard.” The people writing the standard are writing the drift risk down. The query interface has no vote and no released spec. The neutral referee is still drafting its rulebook.

The counter-read: if one governed definition feeds both surfaces, as Part 3 argued, the second copy never exists and the table has nothing to compare. True for every metric you finish migrating. The hashes still earn their place, because they catch the filter someone adds in a surface-level calculation, the one that never passes through your repo. Most shops will run both for a year. In my shop that year looks like a LookML measure and a dbt metric with the same name. The contract is for that year.

What I’d do this week

One build, finishable between meetings, and then four Mondays of discipline.

User moment: Monday morning before the forecast call, when the number in the BI tool and the same number in the warehouse have to match and nobody has compared them since the build.

Shape: One page, ten rows: the ten from Signal #16 that Part 2 gave owners and Part 3 gave future readers. Columns: metric, grain, filter logic in one sentence, owner (a name, per Part 2), reader and future question (per Part 3), hash A, hash B, last verified, surface A value, surface B value, delta, tolerance. Hash A covers the SQL behind the warehouse copy. Hash B covers the LookML or DAX behind the BI copy. A filter added in either moves its hash, even on a week the two values happen to match. The sentence is written for people. The hashes are for the code. Tolerance is zero for counts and a stated amount or percentage for sums and ratios, with both queries run against the same as-of date. Fill it by hand: run both queries, paste both numbers, subtract, recompute both hashes.

Time budget: Two hours to build. Fifteen minutes each Monday for four weeks.

Artifact: The table, committed next to the model with the date, and one log line per Monday.

Success: After four Mondays you can say, for each of the ten, when it last matched, whether either copy’s code moved, and who answers for it when it doesn’t. Run it by hand for four weeks before you automate anything.

Credible failure: Four green weeks, ten rows. Then the useful result is the tolerance column. If you could not name a tolerance for six of the ten, you learned nobody agreed what “matching” means. That is a finding. It cost you an hour a month.

The weeks it is green teach you nothing. The first red is the whole product.

Sources

Crafting runs weekly. The job is to be useful, not to sell. If a line in here is close to a move you're working on, the email reaches a person.

Hiring rather than hunting? Signal is the column for your side of the desk.

Email meRead more Crafting

← All Crafting issues · Drafted with Claude · Edited by Paul Brown