Boundaries change with versions; the statement must update with them

What it is

A model that could not read tables last quarter can this quarter; a “verify on the web” tool that worked last quarter is off. Capability copy that still describes the old version is an expired map. Version-synced boundary copy means: when the model, the tools, or the permissions move, the sentences about can and cannot move in the same release, not in the next brand pass.

Drift has two directions. New ability unwritten, and people will not use it. Old ability still written, and people will act on a path that is dead. The second hurts more.

Why it happens

Generative ability is not a function table compiled into the client. It is a server-side bundle of model, retrieval, and tool switches. Client copy, the help centre, and empty-state examples often ride a slower train. Once the trains split, the interface is testimony about the previous version.

People who once learned “it can read a PDF” keep that card for a long time. A version bump is rarely felt as “the capability set changed.” It is felt as “why not today” or “did you turn it off on purpose.” Stale negative copy is also harmful: “cannot analyse tables” blocks work the system can now do, and it discounts the rest of the cannots — once one sentence is found false, the others are not believed.

Studying it

Two versions of the product statement, same task set, handover judgements; then a diary around a real version cut: which tasks move from will to will-not, how long before people change what they say. Independent variables: whether the statement carries a version or a date, whether the cut is announced as a capability change, whether the change is a gain or a loss. Dependent variables: attempts on expired paths, lag to discovery, trust in the whole statement.

A lab that hard-binds copy and model to one build number will understate the split in the field. The field measurement is the gap between the two trains.

Where it stops holding

A static model with no tools barely changes its boundary on a minor version, so sync is cheap. An on-prem deploy that forbids automatic updates should lock the statement to that build, not point at public help. Backward-compatible “now it can more” can wait to be advertised; “now it cannot” must arrive before the first failure. This entry does not treat how to disclose a boundary the first time, only the time-alignment between disclosure and actual ability.

Applying it

• Give capability copy and model/tool config one version identifier. When web access is switched off, “can look up pages” must vanish from help in the same release.
• On a capability loss, interrupt and name the task class that is no longer supported, with a substitute path. Gains can use a lighter entry.
• Generate empty-state examples from the current tool list. Do not hand-write a “try these” that never ages.
• Check: in staging, turn one tool off and walk empty state, help, input hint, and failure copy. None of the four channels may still promise that tool. Then give three long-time users a task and watch whether they still plan steps around the old ability.

Related

• Same group: L1.02.1 What the system cannot do needs stating as much as what it can · L1.02.2 Boundaries should be told before the attempt, not after the failure
• Nearby: L1.06 Graceful degradation of AI failure · L1.11 Reproducibility of non-deterministic output · L2.09 Discoverability of what I can say
• Search terms: version-synced boundary copy · stale capability copy · capability drift