What did 'customer' mean last year?

It is budget season. The leadership team sharpens the definition of an active customer to fit the new strategy. A week later an AI assistant shows the number of active customers going up. The dashboard looks great. Nobody can say whether the company is performing better or whether only the definition changed.

Every sharpening makes comparing harder

Organisations keep changing what they measure and why. That is healthy. It only becomes a problem when the history does not move with them.

Changing a metric or KPI. A new definition of customer or discount can make this year's number incomparable with last year's. A meaningful comparison requires clarity about which definition applies to each period.

Sharpening a budget. Assessing a revised budget requires the earlier budget and actual results, under the agreements of the time. Overwriting the earlier budget removes that basis for comparison.

Taking on a new strategy. A change of direction raises a question about what it delivers. Changes in performance must be distinguishable from changes in measurement rules. A rising line does not provide that distinction by itself.

Two timelines, two different questions

Keeping historical records is necessary, but it does not automatically preserve the meaning of a KPI. That requires distinguishing two timelines.

A definition's valid time describes when the organisation considers it applicable. A new customer definition might apply from January, even though the decision is recorded in February. System time, or recorded time, describes when that information was held in the system. These timelines answer different questions: what applies to January, and what was known in January?

SQL Server provides a concrete storage mechanism: system-versioned temporal tables retain earlier row versions and support querying data as it was stored at an earlier system time.¹ That system history does not establish when a business definition should apply in business terms.

The architectural recommendation is therefore to record definition validity explicitly, alongside its recording history. A retrospective correction can then be distinguished from a rule change. Without that distinction, a reconstructed report may answer a different question from the original report.

Preserve the original definition and label each change before comparing figures.

What a foundation remembers

A useful foundation keeps not only the data but the context needed to interpret it later:

1. The definition and version, including its validity period and scope.
2. Who changed the definition, when and why.
3. The source data as it was known then, alongside subsequent corrections.
4. The calculation rules and the link to the report or decision that used the number.

This is an architectural recommendation, not something a historical table supplies automatically. Permissions also matter: historical data must not become accessible simply because a question concerns the past.

An AI that knows no history can only answer for the present.

Why an AI needs this

If an AI receives only today's definition, it lacks the basis for explaining a historical definition change. A fluent answer does not make that missing context visible.

A better approach starts by retrieving the applicable definitions and source records. Approved deterministic calculations then produce the figures; the model verbalises the result. That wording must be evaluated: does it identify the correct period, definition version and limitations?

A semantic layer of shared definitions can organise this work, but it does not guarantee equal numbers or safe access. Definitions, versions, scope, sources and permissions must be applied consistently.

A comparison may need two views: each period under its original definition, and both periods recalculated under one selected definition. Where the required data exists, that recalculation can help separate the effect of the definition change from changes in the underlying activity. Missing data must be stated explicitly rather than filled in by the model.

Valid time describes when a rule applies. Recorded time describes when it was known.

Frequently asked questions

Five questions to ask today

1. Can you see which definition of customer, discount or financial period applied in which year?
2. Is it recorded who changed a definition, when and why?
3. Can you still reproduce last year's report today, under the definition of the time?
4. When you sharpen a KPI, does the history stay comparable, or do you start over?
5. Does your AI receive that context, or only today's definition?

List the uncertainties and test one repeatable question against an old report. Check which definition, data version and calculation are needed to reproduce the answer.

Whoever does not keep their history cannot judge their course.