Model Citizen
Adam YoungJul 6, 2026
Data Engineering6 min read · Blog · Updated Jul 17, 2026

Your Metric Definition Has Already Forked

Copy-pasted SQL is how one metric quietly becomes three. Point an AI agent at raw tables instead of a governed definition and you've automated the copy-paste problem at the speed of autocomplete.

Ask five analysts to calculate "active customers" and, if the definition lives only as a formula copy-pasted into five different reports, you'll get five slightly different numbers within two quarters. Nobody changed the logic on purpose — someone just adjusted a filter for their one report and the edit never made it back to the other four. This is the oldest failure mode in analytics, and it's the exact one that gets worse, not better, once an AI agent is the one writing the query.

Why copy-pasted logic was always fragile

A formula duplicated across reports has no single place to fix. Every copy is a fork, and every fork is a future discrepancy waiting for someone to notice in a meeting. The fix analytics engineering has been reaching for is the semantic layer: define "active customer" once, centrally, and have every report reference that single definition instead of re-deriving it. Newer modeling layers push this further, letting you define reusable metric functions — named, parameterized, and versioned — inside the model itself, so renaming a table or adjusting a filter updates every dependent metric instead of silently orphaning four copies of the old logic.

Why this suddenly matters more

A human analyst re-typing a formula might introduce drift once a quarter. An AI agent generating queries against your warehouse will re-derive "active customer" every single time it's asked, from scratch, unless there's a governed definition it's actually pointed at. Point an agent at raw tables and you haven't automated your metrics — you've industrialized the copy-paste problem at the speed of autocomplete. The agent isn't the risk. The absence of a single, callable definition for the agent to use instead of guessing is the risk.

What "metric as a function" actually means

Treat a metric the way you'd treat a function in a codebase, not a value in a spreadsheet:

  • Named once. "Active customer" is defined in exactly one place, not reasoned about fresh by every consumer.
  • Parameterized, not forked. Need it by region or by cohort? Pass an argument to the same definition — don't copy the formula and hand-edit the filter.
  • Dependency-aware. Rename the underlying table or column and every metric built on it updates or fails loudly — it doesn't quietly point at a column that no longer exists.

The payoff is bigger than consistency

Once metrics are callable, governed functions instead of scattered formulas, they become the thing you can safely hand to an agent, a dashboard, and a data scientist at the same time and get the same number back from all three.

Pick the metric your teams have reimplemented the most times — "active customer" is usually a good bet — and run it through the three tests above. Any "no" is a fork already in progress — fix that one before you point an agent at it and find out the hard way.

Governing a metric once is the hard part. The standards world is now betting you can then make that definition travel between tools without re-forking it — but that portability only pays out for teams who did this modeling first.

Keep going

More on Data Engineering

Have data that should be doing more?

Tell me about the pipeline that breaks, the metric nobody trusts, or the analysis stuck in a notebook. Let's operationalize it.