7.1 Locked vs Adaptive AI-Based Systems

Testers who treat every AI-based system as if it were a conventional deterministic program walk into CT-AI questions unprepared. The first split the syllabus asks you to make is not neural network versus decision tree. It is whether the system is locked or adaptive after it reaches production, because that choice changes what you can assert, when you retest, and how much of the oracle can be frozen in a suite.

Why the locked versus adaptive split sits at the start of AI testing

Conventional software changes when someone ships a new build. Until that build, the same input on the same environment produces the same output. Many AI-based systems follow that pattern. Others keep learning from live data, rewards, or a shifting environment, so the program you exercised at 09:00 is not the program you re-run at 11:00. Comparing testability of those two families is learning objective AI-4.1.1 (K2): you must explain why locked systems are far easier to test, and what extra work adaptive systems force onto the test team.

This is a strategy question, not a trivia label. If you mis-classify a live learner as locked, you will trust expected results that the system is quietly rewriting. If you mis-classify a frozen checkpoint as adaptive, you will waste effort on sandbox rituals that the release process does not need — and you may skip the retrain-as-new-system testing that a weight swap actually requires.

Locked AI-based systems: behavior frozen after deploy

A locked AI-based system does not change its behavior once it is deployed. The model that left the training pipeline is the model that serves production traffic. If the core is a deep neural network (DNN), that means the learned weights and biases stay fixed. They move only if the organization retrains the network and then deliberately replaces the deployed artifact.

That freeze is a product decision, not an accident of the algorithm. Teams lock models when they need replayable evidence, a certifiable configuration, or a safety case that would collapse if the decision surface drifted overnight. Medical imaging classifiers, industrial visual inspection, and many on-device speech models are locked for the same reason: auditors want to name the exact artifact that produced a decision.

Worked example: perception on a self-driving stack

Safety-related driving functions such as lane detection and traffic-sign recognition are typically fielded as locked models. Imagine a camera-based sign classifier sitting behind a fixed checkpoint sign-net-v3.2. On a closed track, testers replay a library of frames: a 50 km/h roundel in rain, a 30 km/h plate at dusk, a stop sign partly hidden by a branch. Because weights do not update from those frames, the tester can treat the expected class as a durable oracle for that version.

If operations later collect miles of new urban footage and the vendor retrains sign-net-v3.3, the locked system has not adapted in the field. Someone built a new locked system. CT-AI is explicit on the testing consequence: an updated locked AI-based system is typically treated as a new system, and a fresh round of testing is required. Replaying only the old happy-path frames is not enough. You re-establish functional performance, hunt for regressions the retrain introduced, and add cases that represent the new data that motivated the retrain.

Think of the locked model as firmware with a very large lookup surface. You do not re-certify a brake controller by waving at last year's report after a silicon respin. You do not re-certify a perception net by waving at last year's accuracy slide after a weight dump.

Adaptive AI-based systems: behavior can change after deploy

An adaptive AI-based system can change its behavior once it is deployed. The change might be driven by a reward function (classic reinforcement learning) or by the need to cope with a new operational environment. You cannot write down, in advance, the exact new behaviors the system will invent. That unpredictability is the testing problem, not a side note.

Worked example: an e-commerce recommender

An online retailer ranks products from a user's clicks, dwell time, and purchases. As preferences evolve — seasonal fashion, a new hobby, a household member sharing the account — the ranking policy updates. Monday's test user who was shown hiking boots may, after a cluster of kitchen-gadget clicks, receive a different top-N on Tuesday without a formal model release. That is adaptive behavior: the live system is the learner.

For testers, the practical nightmare is contamination. A test account that clicks aggressively to explore edge rankings is training data. The act of testing can move the policy. Two testers sharing an environment can invalidate each other's expected results. Isolation, snapshots, cloned user graphs, and explicit learning-off switches become test-environment requirements, not niceties.

Adaptive does not mean untestable. It means your oracle, your environment, and your notion of a build all have to include time and feedback. A test report that omits which policy version produced which output is incomplete.

A continuum, not a binary switch

In practice, AI-based systems span a continuum:

• At one end: fully deterministic, locked-down systems that produce the same output for a given input.
• At the other: deliberately non-deterministic, self-learning systems that keep evolving.
• In the middle: many generative AI (GenAI) and large language model (LLM) chatbots. They are often locked at runtime — the serving checkpoint does not train on your prompt — yet vendors update them periodically. Each update sits between fully locked forever and learning from every session.

Treat a checkpoint swap as you would treat a new locked release: new tests, new evaluation sets, new safety probes. Sampling settings such as temperature or top-k can make even a locked checkpoint look noisy. Do not confuse decoding randomness with online learning. The first is a locked model with a stochastic decoder; the second is adaptation. Exam distractors love mixing those two stories.

Why locked systems are far easier to test

Locked systems are largely deterministic, so expected results do not change from run to run of the same version. You can freeze a golden input set and expected labels or numeric tolerances, automate regression, and attribute a failure to the current artifact rather than to the model that learned something overnight. That is the exam contrast. Adaptive systems deny you a stable oracle because the definition of correct behavior is a moving target.

Easier is not the same as easy. A locked driving stack still has sensors, timing, and an operational design domain. The claim is comparative: given the same task, locking the learner removes a whole class of test pollution that adaptive systems inject.

Caveat: locked does not mean perfectly repeatable

The syllabus warns you not to oversell determinism. Large neural networks can still behave non-deterministically even when weights are frozen, because of:

• Floating-point precision limits — accumulations differ slightly depending on the order of operations.
• Hardware execution differences — especially parallel computation and GPUs, where reductions and kernels are not always bit-stable across devices or library versions.

So locked is easier is about policy stability (the model is not rewriting itself), not about bitwise identical logits on every GPU in the lab. Testers still use tolerances, seeds where the framework allows them, and statistical checks when a single forward pass is jittery. If two lab machines disagree on a borderline traffic-sign crop, do not assume the model unlocked itself. Check numeric stability before you open an adaptation incident.

How far you can test an adaptive system before it goes live

You can still test adaptive systems before deployment, but the design is heavier than a locked golden set:

1. Simulate environmental change. Shift the live-like data: a new product catalog, a new user cohort, lighting or sensor noise, latency spikes. Watch whether the learner updates in a controlled sandbox rather than in shared production memory.
2. Test the learning mechanism itself. Confirm that rewards, update frequency, and constraint layers do what the design says. If a negative reward is supposed to suppress unsafe recommendations, show that those items actually fall in rank after the update step.
3. Test the ability to adapt appropriately. Give the system a planned distribution shift and check that it recovers useful behavior rather than collapsing into a trivial policy (always recommend the same bestseller; always steer to the lane center regardless of an obstacle).

This is more complex than locked testing because the system may change its behavior during the test, or as a result of the test. You need reset procedures, cloned environments, and logs that record which policy version produced each output. A failing case you cannot replay is not evidence you can take to a release meeting.

What you cannot pre-test — and what you do instead

Unpredictable new behaviors cannot be fully tested in advance, and you cannot prepare a complete set of cases for behaviors that do not yet exist. That is not a license to skip testing. Two durable tactics remain:

• Keep an automated suite aimed at core functionality. Whenever the system undergoes significant change, run it to check that adaptation has not broken invariants: checkout still completes, the vehicle still stops, the assistant still refuses a disallowed class of request.
• Watch degradation against thresholds. After significant change, and as ongoing monitoring, test whether performance has slipped past a pre-agreed limit (ranking quality, crash-rate proxies, toxicity rate, calibration error). Crossing the threshold is a test failure even if no individual output looks wrong in isolation.

Exam traps for AI-4.1.1

• Trap: locked means no testing after go-live. Locked systems still need regression when the artifact changes, plus operational monitoring for sensors and data that were never part of the frozen weights.
• Trap: adaptive means wait and see in production. Pre-deploy testing is still required; it is just designed around simulated change, the learning mechanism, and controlled adaptation.
• Trap: a periodic LLM upgrade is adaptive learning. If the serving weights do not update from user traffic, the runtime is locked. The upgrade is a new locked system.
• Trap: one GPU disagreement proves the model is adaptive. Floating-point and parallel execution can explain jitter without any learning step.

Locked versus adaptive is therefore a test-strategy question: freeze-and-retest-the-version versus sandbox-the-learner-and-monitor-the-live-system. Get the category right, and the rest of Chapter 4's techniques have a place to hang.