1. Course overview

Model requalification is the controlled process of re-establishing documented evidence that a computational model remains fit for its intended use after a change to its design, its numerical solver, or the environment in which it executes. In regulated engineering environments—pharmaceutical process modeling, medical device simulation, aerospace structural analysis, automotive control-model development, and financial risk models—a model is not a one-time deliverable. It is a living asset whose credibility is tied to a specific configuration. When that configuration changes, the prior qualification evidence does not automatically transfer. Requalification is the discipline that closes that gap deliberately rather than assuming equivalence.

This course addresses models that have already passed an initial qualification or validation and are now subject to change. The scope deliberately excludes first-time model qualification, which is covered by separate validation methodology. Here we focus on the harder question: given an existing qualified model, what exactly must be re-demonstrated, at what depth, and with what evidence, when design or solver changes occur?

Why Design and Solver Changes Are Distinct Risk Classes

Not all changes carry the same risk, and conflating them is the most common source of both over-work and under-verification. A design change alters the model's structure or intent: geometry, governing equations, boundary conditions, material property definitions, parameterization, or the input/output specification. A solver change alters the numerical machinery that computes the answer: the integration scheme, mesh or discretization strategy, convergence criteria, tolerance settings, linear algebra backend, compiler, or library version. A third category—environmental change—covers operating system, hardware, dependency versions, and execution platform.

The distinction matters because the two classes fail differently. A design change can invalidate the model's conceptual soundness; a solver change typically preserves the conceptual model but can shift numerical results, convergence behavior, or stability margins. Requalification strategy must therefore be risk-proportionate: a solver patch that changes only floating-point library versions may warrant a regression comparison, while a change to the discretization order demands re-examination of convergence and possibly re-validation against reference data.

The Requalification Lifecycle

The lifecycle below is the backbone of the remaining chapters. It is a closed loop, not a linear checklist, because assessment findings can send a change back for redesign or escalate the required evidence depth.

Each stage produces a specific artifact. Change intake yields a change request with a precise description of what changed and why. Impact assessment yields a risk classification and a list of potentially affected model outputs. Evidence gap analysis maps those outputs to the existing qualification evidence and identifies what is now stale or missing. Execution produces new test results, comparison reports, or analytical justifications. Review and approval produces a signed disposition. Configuration control updates the model baseline so the new qualified state is unambiguous.

Regulatory Context

Requalification obligations are not invented by this course; they are embedded in established regulatory frameworks. In the pharmaceutical and life-sciences sector, computerized system validation expectations under GAMP 5 and 21 CFR Part 11 require that changes to validated systems be assessed, controlled, and re-verified in proportion to risk. In medical device development, ISO 13485 and FDA design-control requirements treat simulation models used as design evidence as subject to change control and re-verification. In aerospace and automotive, DO-178C and ISO 26262 impose configuration management and verification-of-changes obligations on models embedded in safety-related functions. Financial regulators similarly require model risk management frameworks (for example, SR 11-7 in the United States) that mandate ongoing validation and revalidation after material model changes.

Across all of these, three regulatory principles recur and should guide every decision in this course:

• Risk-based proportionality. The depth of requalification must match the risk the change introduces to the model's intended use. Over-verification wastes resources; under-verification is a compliance finding.
• Traceability. Every requalification activity must be linkable to the change that triggered it and to the qualification evidence it refreshes. An auditor must be able to reconstruct why a given test was or was not performed.
• Documented justification. Where requalification is deemed unnecessary, the rationale must be recorded and approved—not merely assumed. "No impact" is a conclusion requiring evidence, not a default.

What "Fit for Intended Use" Means in Practice

A model is fit for intended use when its accuracy, precision, and domain of applicability are demonstrated for the specific decisions it supports. Requalification therefore cannot be reduced to "the numbers still look close." It must confirm that the model still answers the same question, within the same validity domain, with the same demonstrated confidence. A solver change that shifts results by 0.5% may be acceptable for a screening model and unacceptable for a safety-margin calculation. The acceptability threshold is defined by intended use, not by the magnitude of the change alone.

How This Course Is Organized

The chapters that follow move through the lifecycle in order. Early chapters establish change classification and impact assessment methods, including how to build a model dependency map that shows which outputs depend on which design and solver elements. Middle chapters cover evidence gap analysis, the design of regression and re-validation test suites, and the statistical and numerical criteria used to judge whether results are equivalent. Later chapters address documentation, approval workflows, configuration control, and audit readiness, closing with worked case studies that trace a design change and a solver change end to end.

By the end of the course, you should be able to take a change request for a qualified model, classify its risk, identify the affected evidence, design a proportionate requalification plan, execute and judge the results, and produce a defensible, traceable record of the requalified state. The lifecycle diagram above is the map; the remaining chapters supply the methods for each stage.