Long co-evolution needs periodic review, not unchecked drift

What it is

The process of users and systems adapting to each other does not automatically halt at "just right" — it keeps drifting to some stable point, and stable is not the same as correct: it may be the user long accommodating the system's defects, the system long fitting the user's mistaken usage, or both locked into a mediocre middle. A long co-evolving system needs periodic review of that drift: is the current adaptation equilibrium what both parties actually want?

The object of review is the adaptation relationship itself — which of the user's habits grew from accommodating the system, which of the system's assumptions grew from fitting the user, and whether those adaptations should exist — not a rule-by-rule check for staleness. The latter, checking rules after life has changed, is the maintenance topic; its object is the rules, while the object here is the sediment of mutual accommodation between human and machine.

Why it happens

Why won't drift arrive at the optimum on its own? Neither adaptor holds a global objective: the user locally optimises "convenient right now"; the system locally optimises "fit to observations". Two local optimisers chasing each other stop wherever initial conditions and noise happen to land them — nothing guarantees the equilibrium is the global optimum, and there is no reason it should be by luck.

The sediment layers: every adaptation is a small edit to the previous state; the habit the user grew today to detour around defect A becomes tomorrow's input to the system's learning of "user habits" — the products of adaptation are consumed as its evidence, early small errors buried under later adaptations rather than removed.

And it is largely irreversible: once user-side adaptation has hardened into body memory, fixing defect A does not dissolve the detour — people keep routing around a corner that no longer exists. Drift happens automatically; correcting it takes deliberate action, an order of magnitude apart in speed. Leaving it alone does not "maintain the status quo" — it is continuous one-way degradation.

Studying it

• Long-residence studies: smart-home demonstration homes and multi-month follow-ups have recorded routines reorganising over time — "adjusting life around the technology" gradually normalising, and residents' awareness of their own accommodations declining with time.
• Method: drift audits — at fixed intervals, re-measure the same battery of baseline tasks (steps to accomplish X, detour count, workaround count) and self-reported effort, compare against the installation baseline to get the drift's direction and magnitude; pair with adaptation interviews (have users demonstrate "how I do X now", compared with installation time) to surface unconscious accommodations.

Where it stops holding

• Review has a cost floor. Reviewing pushes the technology back into attention, against the disappearance grain — frequency must sit between drift speed and disturbance: learning systems drift fast and need dense review; fixed-rule systems drift slowly and need sparse review. There is no universal frequency, only one matched to drift speed.
• Some drift is healthy. User skill growth, and the system genuinely learning true preferences — review must be able to tell direction, not treat every change as an error; rolling back healthy adaptation is its own injury.
• The reviewing party is usually not "all users". In households, the installer/manager member typically carries the review (whoever set it up maintains it), with everyone else adapted-to. Review design must face that division: give the manager review tooling, and give the adapted-to a veto channel.

Applying it

• Build an "adaptation check-up" into the product's cycle: quarterly (or after major updates), generate a summary — what the system learned this half-year, which settings you changed, which slots you repeatedly intervened in manually — for a human to judge whether to wind anything back.
• Give drift an explicit way back to the starting point: every learning module with reset/roll-back-to-timepoint capability; learning without roll-back has no error-correction mechanism, which makes drift irreversible by design.
• Watch for "user detour" signals: repeated manual-intervention patterns (always manually disabling a particular automation at a particular time) are the earliest sign of an adaptation imbalance — the product should proactively prompt a review rather than wait to be asked.
• How to check: for systems deployed over a year, audit the difference list between "the user's action chain for routine tasks" and the installation-time chain, labelling each item: learned by the system / accommodated by the user / degraded on both sides — a non-zero count in the third column triggers review.

Related

• Same group: Z3.07.1 Users adjust their behaviour to fit how automation judges them · Z3.07.2 Automation keeps adjusting its strategy from observed behaviour · Z3.07.3 Mutual adaptation can entrench a wrong initial assumption
• Nearby: Z7.04 Long-term evolution · Z3.05.4 Behavioural drift in learning automation keeps eroding predictability
• Search terms: adaptation review · co-evolution · long-term deployment · roll-back