Validation Is a Starting Line, Not a Guarantee
For a deployed clinical AI system, the crucial question is not whether it once performed well on a validation dataset. It is whether the relationship measured during validation survives the transition into routine care. This chapter follows that transition—from internal, temporal, or external validation to early integration and mature operation—so the reader can distinguish a recurring pattern of post-deployment divergence from a universal claim that every system fails in the same way.
What each kind of validation actually measures
Validation is often discussed as if it were a single event with a single meaning. In practice, it is a family of comparisons that use different distances from the data on which a model was developed.
Internal validation usually holds out part of a dataset drawn from a similar data-generating process. It asks whether the model can perform on cases that were not used to fit it, while keeping the institution, documentation habits, data definitions, and broad workflow relatively familiar. This is useful for detecting overfitting and estimating performance under conditions close to development. It is also the form most exposed to hidden similarity: a held-out record may be new to the model but still be produced by the same local practices.
Temporal validation moves the evaluation window forward within the same health system. It tests whether performance survives a period of time that was not used for development. That is a meaningful improvement when practice is changing, but it remains a sample of the institution's history. A later clinical protocol, EHR upgrade, staffing pattern, or documentation convention can still create a new operating context after the temporal window ends.
External validation evaluates the model in another institution or setting. It can reveal transportability problems caused by different patient populations, equipment, coding, workflows, or outcome definitions. But a model that transports well to another site is not thereby guaranteed to remain stable at either site over future years. External validation changes the location of the test; it does not abolish time.
The common assumption across these designs is reasonable but limited: the conditions in the evaluation data are sufficiently similar to the conditions in which the system will be used. Validation estimates performance under that similarity. It does not establish that the relationship between an input, a prediction, and an outcome will remain unchanged after the system becomes part of a living organization.
A helpful way to state the boundary is to treat validation as a baseline operating envelope. The envelope includes more than the variables listed in a model card. It includes how quickly laboratory results appear, which note fields clinicians complete, which patients receive a test, how outcomes are recorded, and how a prediction reaches the person expected to act on it. A validation score is a property of the model under that arrangement. If the arrangement changes, the score is evidence about the past arrangement, not a binding promise about the next one.
This is why a strong validation result can be both genuine and insufficient. It may accurately describe what the model did under the tested conditions. The problem begins when that conditional result is treated as if it were independent of time, workflow, and data production. In clinical care, those dependencies are not peripheral. They are part of the mechanism through which the model receives information and through which its output acquires meaning.
What changes across the deployment states
A deployment lifecycle makes the validation gap visible because the system passes through different states, and something important is gained or lost at each transition.
The validation baseline is the reference state. The model, feature definitions, decision threshold, outcome definition, and evaluation window are treated as known. The organization can compare discrimination, calibration, or other measures against that reference. What the baseline cannot contain is evidence about future workflow changes that have not happened yet.
The early deployment state begins when the model is integrated into routine clinical operation. This is not merely the moment a prediction is switched on. Data must arrive through the expected interfaces, the model must execute at the appropriate time, and the output must appear where users can see and interpret it. During this period, the organization learns whether assumptions made during validation survive contact with actual work. A feature that existed reliably in retrospective data may be late at inference time. A field that looked like a stable indicator may depend on a documentation step that is inconsistently completed. A score may be produced correctly but arrive after the decision it was intended to inform.
The mature deployment state is sustained routine operation after the initial integration period. It is tempting to think that once the first weeks or months are uneventful, the system has passed its final test. In reality, mature operation exposes slower changes: clinical practice evolves, case mix changes, order sets are revised, interfaces are upgraded, and users adapt their behavior. Some changes are visible as abrupt technical failures. Others accumulate until a model's estimates no longer align with current outcomes or workflow decisions.
The longitudinal study examined four deployed systems across these kinds of conditions. They covered high-frequency EHR prediction in acute care, sepsis risk stratification, laboratory and structured-EHR diagnostic support in specialty outpatient care, and imaging-derived risk prediction in radiology. The systems were not identical, which is important: a failure pattern that appears across different domains is more informative than a result from one narrow task. Their observation periods ranged from 18 to 24 months, with inference volumes ranging from 68,000 to 1,240,000 events.
Across all four systems, validation-era performance did not remain a stable operational property after deployment. The models' parameters, feature definitions, decision thresholds, and intended uses were not intentionally changed during the observation period. That makes the comparison especially instructive. The evidence does not point to retraining as the only route to a new behavior. It shows that an unchanged configuration can behave differently when the conditions supplying and interpreting its inputs change.
The unchanged configuration is not a perfect experiment: time, patient mix, workflow, and data availability can change together, and an observational study cannot assign one of them as the sole cause. It is nevertheless an important contrast. If a model is retrained, a later performance change could be attributed to the new parameters, the new data, or the environment. When the configuration is held constant, attention turns to the operating conditions that a static validation report tends to hide. The question becomes not “which version caused the decline?” but “which assumptions about the environment stopped holding?”
A single validation score also compresses time. It may average together many encounters across a window in which performance looked acceptable overall, even though a gradual trajectory was already forming near the end. Post-deployment analysis can instead compare phases and follow monthly or rolling estimates. That difference in resolution matters. A phase comparison can show that mature operation is worse than the validation reference, while a longitudinal trajectory can show whether the change was abrupt, gradual, transient, or sustained. The PLOS study used both kinds of comparison, which is why its conclusion is about a pattern over time rather than a single before-and-after number.
The four systems also clarify why “deployment” is not one uniform exposure. High-frequency EHR-based predictors in acute care repeatedly encounter time-sensitive vital signs, laboratory values, medication activity, and nursing documentation. A specialty diagnostic system may run less often, depend on a panel being available, and receive its confirming label weeks later. An imaging-derived risk system depends on image processing and modality-specific workflow, with different opportunities for feature delay or extraction failure. These systems share the problem of changing operating conditions, but the signals that reveal change and the clinical meaning of a misestimate are not identical.
For the same reason, the boundary between early and mature deployment is a useful analytical convention rather than a natural law of clinical operations. An initial integration period can be long enough to reveal data-pipeline instability in one setting and too short to expose slower changes in another. Repeating the analysis with shorter and longer boundaries asks whether the conclusion depends on that choice. In this study, alternative three-, six-, and nine-month definitions preserved the direction of the main finding, as did alternative time-aggregation windows. That does not tell every organization how long its own integration period should be. It does show why a monitoring design should test its assumptions instead of treating a calendar boundary as self-evident.
The common pattern was progressive rather than a single dramatic break. Calibration changed earlier and more consistently than discrimination, although the exact trajectory depended on the task and data modality. A model used frequently in acute care can encounter input timing and documentation changes at a different pace from a lower-frequency imaging system. The fact that the systems differed does not weaken the common finding; it explains why lifecycle monitoring must preserve a common conceptual model while allowing system-specific measures and thresholds.
The deployment states and their transitions can be represented as a loop rather than a one-way pipeline:
The loop makes two transitions explicit. First, deployment converts a static evaluation into an operating process that must be observed. Second, reassessment is not an optional postscript; it determines whether the system returns to monitored operation, requires a correction, or should no longer be used. The source framework describes similar decisions in practical terms: repair a pipeline, retrain or reconfigure a system, change a workflow, replace a tool, or retire it when continued use is no longer justified.
What the cross-system pattern does—and does not—prove
The study's evidence is strongest at the level of structure. It shows that systems that passed validation can diverge after deployment, that the divergence can develop while the model configuration remains unchanged, and that calibration can be an earlier signal than discrimination. Sensitivity analyses repeated the phase comparison with different definitions of the early-deployment period, including three-, six-, and nine-month boundaries, and repeated longitudinal analyses with different aggregation windows. The direction of the main findings remained: calibration changed more consistently and earlier than discrimination, while workflow-associated telemetry tended to precede or co-evolve with the change.
That robustness matters because a result tied to one arbitrary boundary would be easy to dismiss. It does not, however, turn the study into a universal forecast. The design was retrospective and observational, the systems were anonymized, and they came from a finite set of clinical contexts within one organization. The study did not prospectively test a monitoring intervention, establish a universal tolerance for calibration drift, or measure the exact effect of degradation on patient outcomes. It also did not show that population change is irrelevant; rather, workflow-related indicators were more strongly and consistently associated with degradation in this dataset.
The right conclusion is therefore neither “validation works forever” nor “validation is meaningless.” A more defensible conclusion is that validation establishes a reference against which later behavior can be compared, while deployment tests whether the reference remains relevant. Independent longitudinal studies across institutions could weaken the broad interpretation if they repeatedly found stable performance despite major workflow change. They could strengthen it by showing the same ordering of operational, calibration, and discrimination signals in other tasks and care settings. Prospective studies that intervene on detected drift would add a further kind of evidence: not just that divergence occurs, but which responses restore safe and useful operation.
This distinction also clarifies why the next issue is mechanism rather than blame. Once a timeline shows divergence without a model update, “the model changed” is no longer an adequate explanation. The more precise question is which parts of the clinical workflow and data-generating process moved between the validation window and routine operation—and how those changes altered what the deployed system could see, when it could see it, and what its output meant.