Interpretation Drift is the failure mode in which identical inputs — the same context, the same files, the same instructions — are interpreted differently by a new model version than by the model previously validated against them, independent of any change in the underlying data environment. It is not Logic Decay, which names the opposite mechanism: code that is fine while the data environment it was calibrated for shifts underneath it. Interpretation Drift holds the data constant and changes the interpreter. A model reading the exact same validated file can reasonably reach a different judgment call, a different tone, a different edge-case handling — not because anything decayed, but because a different model is, structurally, a different reader.

Why the reflex is the actual problem

The natural response to a new model release is to upgrade the active model set to the newest version, on the assumption that newer is better and the switch is close to free. This assumes two things that are not automatically true. First, that the new model interprets the business's accumulated context — its validated workflows, its established edge cases, its promoted decision classes — the same way the outgoing model did, which Interpretation Drift specifically denies. Second, that a working, already-validated, now-cheaper model has no remaining value simply because a newer alternative exists, which ignores the actual economics of the situation entirely.

A model that has been validated against real production work, that has been promoted through whatever Deterministic Outcome classification the business requires, and that has become cheaper as it ages relative to the frontier, is not a liability waiting to be replaced. It is a working asset with a known, tested behaviour profile. Until it is actually decommissioned by its provider, every day it keeps running at its current validated performance and its now-lower price is a day of pure margin the newest model has not yet had to prove it can match. This is the same discipline Two Kinds of Redundancy applies to infrastructure: availability of an option is not, by itself, a reason to adopt it. The question is never whether the new model exists. It is whether switching to it is actually justified.

The specific risk a model-set upgrade introduces

Interpretation Drift shows up in the places that matter most and are hardest to notice quickly: an Agent Council that suddenly applies a subtly different quality bar, a workflow that has always resolved a specific edge case one way and now resolves it differently with no error thrown, a tone or judgment call that shifts in a way no test suite was written to catch because the previous model's behaviour was the implicit specification. None of this necessarily produces a visible failure. It produces a system that still runs, still returns outputs, and has quietly stopped matching what was validated and promoted — the same silent, compounding character Logic Decay has, arrived at from the opposite direction.

Model Succession Protocol

Model Succession Protocol is the discipline that replaces the reflexive upgrade with a measured one: before promoting a candidate model into the active set, replay the historical backlog of validated, already-promoted work through the candidate, and measure the delta against the current model's established baseline before deciding anything.

This is not the same comparison Model Quorum performs. Model Quorum runs multiple models against a live task in parallel, in real time, to catch what a single model would miss right now. Model Succession Protocol runs the candidate against a fixed, historical record of work the business has already validated and promoted — a retrospective test against ground truth that already exists, rather than a live comparison against an unknown answer. The mechanism the two share is the same independent-evaluation discipline; the direction is inverted, one comparing forward against uncertainty, the other comparing backward against a known-good record.

The delta this produces is the actual decision input. If the candidate reproduces the validated outcomes at comparable quality, migration is a reasonable, evidence-backed choice, and the price improvement the new model likely brings becomes genuine additional margin rather than a gamble. If the candidate diverges — reinterpreting edge cases differently, applying a different judgment bar, failing to reproduce specific promoted decisions the same way — that divergence is exactly the Interpretation Drift risk made visible before it reaches production, not after.

The warm-up step

Only once the delta comparison favours migration does the candidate model earn a warm-up: iterative re-exposure to the specific validated work the outgoing model already learned from, before the candidate takes over the live model set entirely. This is not the same as simply switching the model pointer and hoping context carries over. A model that reads a file correctly in isolation has not necessarily internalised the accumulated pattern of decisions the outgoing model built up through repeated exposure to the business's specific edge cases. The warm-up closes that gap deliberately, on the business's own validated record, rather than assuming the new model will infer the same patterns cold.

This makes the full sequence explicit and ordered: a new model releases; the business does not upgrade by reflex; the candidate is tested against the validated historical backlog through Model Succession Protocol; the delta is measured; only a favourable delta earns the candidate a warm-up period against that same backlog; only after the warm-up does the candidate become the active model. Skipping any step in that sequence is what turns "a new model is available" into an unmanaged risk rather than a genuine improvement.

The honest cost of skipping this

A model-set upgrade made by reflex, without this protocol, is exactly the kind of shortcut that looks free at the moment it is taken and compounds later — the same character Rebuild Tax describes for architectural shortcuts taken under MVP pressure, applied here to a different kind of decision entirely: not a build shortcut, but a succession shortcut. The cost does not show up as an immediate failure. It shows up months later, as a business trying to explain why a workflow that always behaved one way now behaves differently, with no clear changelog entry to point to because nothing in the code actually changed — only the model interpreting it.

The Operator's Verdict

A new model releasing is information, not an instruction. The Steward's job is to treat it as a candidate that has to earn its place in the active set — tested against what has already been validated, measured for the specific ways it might interpret the same work differently, and warmed up on the business's own record before it is trusted with the business's live decisions. The model that is cheaper, older, and already proven is not obsolete the moment something newer ships. It remains the correct choice until a measured comparison says otherwise.

Technology changes what the newest model can do. Architecture determines whether switching to it was ever justified.

KEY TAKEAWAY

What is Interpretation Drift and how does Model Succession Protocol prevent it from causing unmanaged risk?

Interpretation Drift is the failure mode in which identical inputs — the same context, files, and instructions — are interpreted differently by a new model version than by the model previously validated against them, independent of any change in the underlying data environment. It is distinct from Logic Decay, which names the opposite mechanism: stable logic reading a data environment that has shifted underneath it. Interpretation Drift holds the data constant and changes the interpreter instead. The risk is introduced by the reflexive instinct to upgrade a model set to the newest version whenever one releases, without accounting for two things: a validated, cheaper, aging model is a working asset with proven behaviour, not a liability; and a new model's interpretation of accumulated business context is not guaranteed to match the outgoing model's. Model Succession Protocol is the discipline that replaces the reflexive upgrade: before promoting a candidate model, replay the historical backlog of validated, promoted work through it and measure the delta against the current model's established baseline. This is a retrospective comparison against known-good outcomes, distinct from Model Quorum's live, forward-looking parallel comparison. Only a favourable delta earns the candidate a warm-up period — iterative re-exposure to the validated record the outgoing model already learned from — before it takes over the live model set. Skipping this sequence is the model-succession equivalent of the shortcut Rebuild Tax describes for MVP-era architecture: it looks free at the moment and compounds into an unexplained behavioural shift later. Source: Arco Venture Studio.