How do I handle multiple definitions of the same metric?

Pick a primary canonical definition for each metric and document the others as named variants: 'MRR (committed)' vs. 'MRR (recognized)'. AI should default to the canonical one and only use variants when the user explicitly asks. Documenting both is cheap; pretending one doesn't exist always backfires.

Should the metric definition include filters?

Yes. Filters are part of the definition, not separate. 'MRR' that includes test accounts isn't the same metric as 'MRR' that excludes them. Capture the filters explicitly: 'is_test = false', 'status IN (active, paused)', etc. Otherwise AI infers filters by guessing, and the boardroom argument starts again.

How often do metric definitions need updating?

Whenever a real business decision changes them: a pricing tier added, a new product launched, an acquisition, currency expansion. Most teams settle into one update every quarter or two. Track the changes (an activity feed helps) so anyone reading historical reports knows which definition was active when.

What if our team can't agree on a definition?

Force the conversation by writing both definitions side by side and computing them against the same period. The numbers usually settle the debate, or at least surface that 'MRR' is doing two different jobs and should become two metrics. The cost of disagreement isn't the discussion. It's the silent disagreement where finance and sales report different numbers and nobody flags it.

Why does AI keep using its own definition instead of mine?

Because your definition isn't reaching it reliably. Pasting 'MRR is X' into one conversation doesn't carry to the next. The fix is structured definitions served over MCP, so every prompt sees the same canonical definitions automatically. Without that infrastructure, AI fills in gaps from training data, which is to say, with a generic definition that has nothing to do with your business.

How to Define Metrics So AI Uses Them Consistently

Why metrics drift across teams

Every team uses the same word to mean different things. Marketing's "qualified lead" is the one that filled out a demo form. Sales' "qualified" is the one with budget and timeline. Finance's "qualified pipeline" excludes anything beyond two quarters out. None of them are wrong; they're answering different questions.

AI walks into this without context and picks one. Whichever definition it pattern-matches from its training data, usually a generic SaaS-textbook definition that doesn't match any of your actual teams. The result: a fourth number that lines up with nobody.

The cost compounds. The boardroom argument is no longer about which team is right. It's about which AI is right. The data-team backlog fills up with "reconcile these numbers" tickets. Trust in AI degrades. Eventually someone says "let's just go back to dashboards."

Anatomy of a metric definition that AI can use

A metric definition AI can use isn't a sentence. It's a structured record. Five required parts:

1. The name and a short description

"Monthly Recurring Revenue (MRR)": committed monthly subscription revenue from active accounts, normalized for annual contracts.

2. The formula (SQL or pseudo-SQL)

The actual computation, in code that runs against your warehouse:

SELECT SUM(amount_cents / 100.0 / contract_months)
FROM subscriptions
WHERE status = 'active'
  AND is_test = false

3. The filters (called out explicitly)

Exclude test accounts. Exclude trials. Exclude paused subscriptions. Exclude internal-domain users. Whatever the rules are, they're part of the definition, not assumed knowledge.

4. The edge cases

Annual contracts divided by 12. Mid-cycle plan upgrades pro-rated to month-end. Free-trial-to-paid conversions counted from first payment, not signup. Each rule documented once, with the rationale.

5. The gotchas

"Amounts stored in cents. Divide by 100." "contract_months is null for monthly subscriptions; treat as 1." The kind of thing the senior analyst who built the table remembers and nobody else does.

The five metrics to define first

You don't need to define everything at once. Start with the metrics that show up in every weekly review and every board deck. For most B2B SaaS:

MRR / ARR

Committed recurring revenue from active subscriptions. The most-asked metric and the one that drifts the most.

Churn rate

Logo or revenue churn? Trailing 12 months or month-over-month? Cancellations or also paused? Pin it down.

Net revenue retention (NRR)

Current revenue from a cohort vs. starting revenue from the same cohort 12 months ago. Watch the cohort definition. It's where most teams disagree.

Qualified pipeline

What stage counts? What close-date window? What probability threshold? The biggest gap between sales' definition and finance's definition.

Active users (or active accounts)

Last 7 days? 28? Daily-active or weekly-active? Counting unique accounts or unique users? Specify it once.

Keeping definitions in sync (this is where it usually fails)

Most teams write metric definitions once. Two months later, the company expands into a new currency and "MRR" needs a currency-conversion rule. Whoever knew the old definition updates a Google Doc, sends a Slack message, and the AI tools never hear about it.

The way to prevent that is making the definition a single source of truth that AI reads every time, not a document that gets pasted into prompts. When you update MRR's formula in Contextary, every Claude conversation, every Cursor query, every dashboard built tomorrow uses the new version automatically. There's no second place to update.

Pair that with an activity feed (who changed what, when) and you have a metric system that scales beyond one analyst's memory. See how to document your warehouse for Claude for the broader playbook.

Keep reading

Annotation

How to define metrics so AI uses them consistently

The short answer