AI database answers need versioned metric definitions

Ask an AI assistant for monthly recurring revenue today and again next quarter. The SQL can be valid both times while the answers use different definitions.

Finance may have changed which plans count, how credits are handled, when a cancellation becomes effective, or which currency rate applies. If the assistant returns only a number and a query, the definition change disappears inside a plausible answer.

Production AI database access needs versioned metric definitions.

Make the business definition executable

A metric is more than a label. Define its population, grain, dimensions, filters, exclusions, time zone, cutoff, currency treatment, null behavior, and source systems. Store that contract outside the prompt and expose it through an approved operation.

“Active customer” might mean an organization with a paid subscription at the end of the reporting day. Another team may mean any organization with product activity in the previous 30 days. Both are reasonable. They are not interchangeable.

For questions that cannot be answered from the available scope, use the natural-language SQL answerability contract.

Version semantics separately from code

A SQL deployment version says which implementation ran. A metric version says what the result meant. Record both.

Each metric release should have an immutable identifier, effective-from date, optional retirement date, owner, review status, canonical definition, compatible dimensions, implementation digest, and migration notes. Editing a definition in place destroys the evidence needed to reproduce historical answers.

Choose the version by reporting time

Do not always apply the newest definition to old periods. A question about Q1 may need the definition that governed Q1, the current restated definition, or both. Make that choice explicit.

The operation can accept a version policy such as as_reported, current_definition, or a pinned metric version. If the user has not stated which interpretation matters, the tool should clarify instead of silently selecting one.

Return definition evidence with the answer

A reviewable result envelope should include:

• metric name and immutable version;
• population, grain, filters, exclusions, and dimensions;
• reporting interval, cutoff, and timezone;
• source snapshot or watermarks;
• implementation and policy versions;
• completeness, unknown, and reconciliation state;
• trace ID and result checksum.

This complements the AI database answer completeness contract. Completeness proves what data was covered; metric versioning proves what the calculation meant.

Roll out changes with dual calculation

Before replacing a metric, run the old and new definitions over the same source snapshot. Compare totals, affected cohorts, dimension-level deltas, null handling, and boundary dates.

Require an owner to explain material differences before the new version becomes the default. Keep the old version available for historical reproduction until its retention policy expires.

Concrete example: active customers

A product team changes “active customer” from any login in 30 days to at least one qualifying product event in 28 days. The new definition removes internal accounts and test workspaces.

Without versioning, the assistant reports a sudden decline and invents a business explanation. With versioning, the answer states that the definition changed, shows both calculations over the transition window, and separates the semantic delta from the underlying customer trend.

Keep caches and conversations version-aware

Metric version belongs in cache keys, continuation tokens, exports, scheduled reports, and follow-up questions. A cached answer created under an old definition must not be presented as current merely because the source rows are fresh.

When a definition changes during a conversation, invalidate dependent plans or require the next dispatch to rebind to the new version. See ChatGPT database cache invalidation.

Test semantic change

1. Change one inclusion rule and compare both versions on the same snapshot.
2. Ask for a period spanning the effective-date boundary.
3. Repeat through a cache, export, scheduled report, and follow-up chat.
4. Remove a dimension supported by the previous version.
5. Backfill late data and distinguish source changes from definition changes.
6. Verify historical answers remain reproducible after deployment.

Where Conexor fits

Conexor provides MCP infrastructure for connecting AI clients to databases and APIs through governed tools. Approved operations and structured result evidence let teams bind natural-language questions to explicit metric definitions instead of asking a model to invent business semantics.

Explore natural-language SQL infrastructure

For source timing, pair metric versions with the database answer freshness contract.