Staged and shadow evaluation

A model should not move directly from a favourable retrospective result to a live decision-making role. The environment changes when real orders, images, queues, interfaces, readers, and escalation paths are involved. A staged evaluation makes those changes observable and gives each stage a defined question. It can reduce the chance that an integration or human-factors failure is discovered only after the output has begun to influence care, although no stage makes a deployment risk-free.

Close the gap in stages, not a leap

External testing asks whether a frozen model transports to an independent population or acquisition setting. It can reveal domain shift that was invisible in the original development cohort. It does not exercise the receiving site’s interfaces, queues, data routing, or readers.

Shadow operation asks a different question. The service runs on real incoming studies, but its output is withheld from the readers whose decisions would otherwise be affected. The hidden output can be compared with an appropriate reference or with subsequent clinical information where the study design permits. The team can observe whether the correct study is selected, whether the result returns in time, whether it can be stored and retrieved, what the local score distribution looks like, and how many alerts the chosen threshold would generate. Because readers do not see the output, the phase does not measure the reader-plus-AI effect, but it can expose workflow and operating-point problems before that interaction is introduced.

A reader or workflow study then exposes the intervention to the people and tasks for which it is intended, using an endpoint that matches the role. A prospective phase can observe live operation with the oversight, escalation, and safeguards required by the local setting. Post-deployment monitoring continues the evidence process rather than declaring it finished. These stages address different failure classes: transport and domain shift, local integration and workload, human interaction, live workflow, and durability.

A context-dependent path

One useful mental model is a progression from retrospective development to independent external testing, then to hidden or shadow operation, a reader or clinical-workflow study, prospective use with oversight, and post-deployment monitoring. The progression is not a mandatory sequence for every system. The appropriate stages and stopping criteria depend on the intended role, the severity and reversibility of errors, the availability of reference outcomes, local governance, and what has already been demonstrated. A triage aid, a report suggestion, and an autonomous decision support system do not create the same exposure or require the same endpoint.

The frozen-model boundary should remain visible in external testing. If a threshold, calibration map, preprocessing step, or model parameter is fitted using the new population, the activity is adaptation rather than a pure frozen test and must be reported and validated accordingly. A shadow phase can still use an adapted system, but the question it answers is then the behaviour of that adapted version, not the transportability of the original model.

The transition between stages should also be explicit. Define what counts as a missing result, a wrong association, an unacceptable delay, an excessive alert load, or a reader override that requires investigation. The exact limits belong to the role and the local governance decision; the durable requirement is that the team names them before interpreting a convenient success signal.

Why shadow operation matters

An exported test set cannot show whether a result is attached to the intended study, rendered in the reader’s context, returned within the useful time window, or visible to the person expected to act. It also cannot show how the deployment’s case mix changes the false-positive load or whether a selected operating point overwhelms the queue. Shadow operation brings those questions into the real technical environment while keeping the model output out of the reader’s decision path.

That protection has boundaries. The service still handles real data, so privacy, security, availability, and data-custody controls remain relevant. Hidden output also cannot reveal automation bias, alert fatigue caused by visible alerts, or any benefit that depends on a reader seeing the result. Those questions belong to later or parallel human-in-the-loop evaluation. Shadow operation is valuable precisely because it is a limited experiment with a limited claim, not because it is a risk-free simulation.

The deployment decision should record which stage produced each piece of evidence and which questions remain unanswered. A good external test is not a substitute for integration evidence, and a successful shadow run is not a substitute for the reader or prospective evidence required by the intended role. Once a system is live, the same discipline must account for changes in the world and in the system itself.

This staged-evaluation framing is consistent with the early live-evaluation guidance in DECIDE-AI and the broader recommendations of FUTURE-AI. Neither source makes this sequence a universal regulatory requirement.