Metric Definition

A metric definition is the precise specification of how a business number is computed: which tables, which join keys, which filters, which time grain, which currency conversion. Without a written definition, “MRR” or “conversion rate” or “churn” devolves into whatever SQL was last shipped to the dashboard the executive happens to look at.

What a good definition looks like

A good metric definition is boring on purpose. It states:

• The name and a one-line plain-English description.
• The SQL recipe (or a reference to it in the semantic layer).
• The grain (per-customer monthly, per-event daily, etc.).
• The edge cases — what counts as a refund, how to handle currency, which test accounts to exclude.
• The owner and the last review date.

Companies that ship definitions like this don’t have weekly arguments about whose number is right. Companies that don’t, do.

Why AI data tools need them

A frontier model can write SQL that looks correct without knowing what “active customer” means at your company. If your definition is “logged in in the last 7 days excluding internal users,” the model needs to know — otherwise it will join naively against the users table and produce a number that’s directionally close but quietly wrong.

BIRD-Interact is built around exactly this failure mode. The questions are deliberately ambiguous; the metric definitions are loaded as documents the system has to retrieve. Claude Opus 4.6 used directly (no retrieval, no grounding) scores 33%. Datost — same model with the retrieval + grounding system on top — scores 75.2%.

How Datost handles metric definitions

Upload your definitions — Notion pages, Markdown files, a docs site — and Datost retrieves the relevant one for each question, cites it in the answer, and uses it in the generated SQL. If two definitions conflict (the “MRR per finance” and “MRR per growth” problem), Datost asks which one to use rather than picking silently. The team’s source of truth lives in your docs; Datost is the interface to it.