Ajith Vallath Prabhakar

Version Drift Framework

Use the source that applies to this decision

Version drift occurs when a system uses information that may be accurate in itself but no longer applies to the current decision. A policy can be superseded, a delegation can expire, or a fact can be valid only within a particular scope. This is different from inventing a fact: the source may be real while its timing or applicability is wrong.

Two policy versions are reviewed against an earlier event date, effective date, scope and authority. The older v1 applies in this illustrative case; unclear applicability leads to a hold for review.
Illustrative policy example. The newest version is not necessarily the version applicable to an earlier event. Open the full-size illustration.

Use the illustrated worked example to examine one decision with your team, then record your own evidence and next test in the printable worksheet.

Download the framework worksheet (PDF)

2 pages · Illustrated example and printable worksheet · No signup required

Version Drift · Follow one decision

What changed after approval?

A policy can be the right version while an earlier approval no longer covers the action. Follow the dates, scope and permission separately.

Fictitious internal-policy example. Entity B, Location B, PO-B, policy terms, roles and dates are invented; they describe no actual policy or legal requirement.

  1. 1 · 10 July 2026

    The older rule applies to this case

    PO-B opened on 20 June for Entity B in Location B. Policy v2 takes effect on 1 July, but its transition clause T1 keeps earlier orders under v1. The Policy Lead confirms that scope.

    An authorized reviewer approves the specified PO action on 10 July, conditional on the recorded scope and state remaining unchanged.

    Record: v1 applies; approval covers the original action and conditions.

  2. 2 · 11 July, before action

    The action now has a different scope

    The requested PO scope changes before execution. The old approval required unchanged scope and state, so it cannot be reused for this changed action.

    Keep the original approval and source references in the record. Flag the changed condition and send it to the accountable reviewer.

    Hold: a stored approval is not permission for every later action.

  3. 3 · Recheck before proceeding

    Resolve applicability, then renew authority

    The Policy Lead checks clause T1 against the changed entity, location, activity and controlling event date. v1 may still apply; simply choosing the newest version does not resolve the question.

    If scope or evidence is unclear, hold for review. Once resolved, obtain any required new approval; application and destination controls must enforce the permitted action and current conditions.

    Proceed only when: applicable policy, evidence and action authority have been revalidated.

The check that matters: which rule applies to this case, and is this action still authorized now? A model's agreement supplies neither answer by itself.

A practical review sequence

  1. Choose a decision and source set. Identify the kinds of rules and facts that shape an answer, and who maintains each source.
  2. Record applicability. For each item, capture its owner, status, scope, effective date, expiry or review date, and relationship to superseded material.
  3. Filter before retrieval. Resolve which items apply to the user, decision, jurisdiction, and time before semantic relevance determines what the model sees. Keep missing or conflicting authority visible.
  4. Verify the result. Require answers to carry source identity and version context. If applicability cannot be established, defer, ask for review, or return a clear limitation.

What needs testing

Build cases for current, expired, future-dated, withdrawn, overlapping, and missing sources. Check that a relevant but obsolete item is excluded, a valid item is included, and ambiguous applicability produces the intended review path. Also test updates, stale indexes, source outages, and whether the recorded answer points to the version actually used. Filtering rules require their own maintenance and review.

Connection to CTRS

Version Drift Prevention is one pillar of the Control Tower Reasoning System. It connects to decision flow and agent action because source status matters only in relation to a user, a decision, and a point in time. The Enterprise Digital Twin guide discusses authority, policy, operational state, memory, and constraints.

Resolve the rule that applies to this case

Illustrative enterprise example: assessing a travel expense across a policy change. A company changes its hotel reimbursement policy on 1 October. Version 1 governs travel before that date; version 2 governs travel from that date, with a separate rule for bookings approved earlier. An employee submits an expense in October for a September stay. Searching for the newest policy alone would return the wrong starting point.

The decision needs the travel dates, booking-approval date, employee scope, and the policy owner’s stated transition rule. Submission date is another fact, not an automatic answer to which version applies. The assistant should establish those relationships before recommending reimbursement. If the transition wording is missing, the case belongs with the policy owner rather than being resolved through whichever passage has the strongest semantic match.

An applicability record makes this review concrete. Capture the source identifier and version, policy owner, effective period, covered employees or entities, transition conditions, withdrawal or supersession relationship, and the reason the source applies to the expense. Keep the actual version used with the decision. A later reviewer needs to see the rule evaluated at the time, even after the policy library has changed again.

Test the boundary around the effective date

Build paired cases that differ in one fact: a September stay versus an October stay, an earlier approved booking versus a new booking, or an employee inside versus outside the policy’s scope. Include two conflicting documents that both appear current, plus a case where the policy service cannot be reached.

Success means each case reaches the version and transition rule specified by the policy owner, with the reason visible in the answer. Ambiguous authority should produce a review request that identifies the missing fact or conflicting source. Failure includes automatically choosing the latest document, silently falling back to an older cached rule, or citing version 2 while the recommendation was derived from version 1. A citation is useful only when it identifies the source that actually governed the reasoning.

Further reading

Read the full analysis.

Share a source-governance constraint or counterexample in a working conversation.