Category: Validation & Testing

Model Verification

Also known as: Verification

Simply put

Model verification is the process of checking that a model has been built correctly and that its computer implementation faithfully reflects its intended design and specifications. In simple terms, it asks whether the model was built right, rather than whether it is the right model for the problem. It is typically an iterative activity carried out throughout a model's development.

Formal definition

Model verification is commonly defined as the process of ensuring that the computer program of a computerized model, and its implementation, are correct relative to the underlying conceptual model and specifications (Sargent 2010). In many treatments it is one of two paired processes for building credibility in numerical or computational models, distinct from validation, which addresses whether the model adequately represents the intended real-world phenomenon. Verification is characterized as an iterative process performed throughout model development rather than a one-time gate. Note that the definitions in the evidence originate from simulation and computational modeling literature; verification should not be conflated with validation, and its specific meaning may differ in regulatory model risk contexts (for example, banking supervisory guidance), which are out of scope for this entry.

Why it matters

Verification addresses a foundational question in model development: whether the model has been built correctly, meaning that its computer program and implementation faithfully reflect the intended design and specifications. In much of the simulation and computational modeling literature, verification and validation are described as the primary paired processes for quantifying and building credibility in numerical models (Thacker 2004). Without verification, errors introduced during implementation—such as coding mistakes or discrepancies between the conceptual model and the executable program—can undermine confidence in a model's outputs even when the underlying design is sound.

Because verification asks whether the model was built right rather than whether it is the right model for the problem, it is a distinct concept from validation and should not be conflated with it. Professionals frequently blur the two, but they answer different questions and address different sources of error. Treating verification as a substitute for validation, or vice versa, can leave a gap in the overall case for a model's credibility.

The definitions used here originate from simulation and computational modeling literature. Verification as understood in regulatory model risk contexts—for example, banking supervisory guidance—may carry a different or narrower meaning, and that usage is out of scope for this entry. Readers working in those settings should confirm how the term is defined within their applicable framework rather than assuming the simulation-literature definition transfers directly.

Who it's relevant to

Data scientists and model developers

Those building computational or numerical models rely on verification to confirm that their implementation correctly reflects the intended design and specifications. Because verification is typically iterative and performed throughout development, it is embedded in day-to-day model-building rather than deferred to a final checkpoint.

Model risk managers and validators

Professionals responsible for assessing model credibility need to distinguish verification (was the model built right) from validation (is it the right model for the problem). Note that the definitions here come from simulation and computational modeling literature; the meaning of verification in regulatory model risk contexts, such as banking supervisory guidance, may differ and is out of scope for this entry.

Auditors and reviewers

Those reviewing model development processes may examine whether verification has been carried out as part of the broader case for a model's credibility. Understanding that verification and validation are distinct, paired processes helps reviewers avoid treating one as a substitute for the other.

Inside Model Verification

Conceptual soundness checks

Verification typically includes confirming that the model was built correctly relative to its design specifications, methodology, and intended logic, rather than assessing whether the design is fit for purpose (which is more the domain of validation).

Implementation testing

A core element is confirming that the model as coded or deployed faithfully reflects the documented design, including checks that equations, code, and configuration match the specified requirements.

Reproducibility and traceability

Verification commonly involves establishing that outputs can be reproduced from documented inputs and that each transformation step can be traced, supporting auditability.

Documentation review

Reviewing design documents, technical specifications, and code comments to confirm alignment between what was intended and what was built.

Relationship to validation

Verification asks 'did we build the model right?' (conformance to specification), which is distinct from validation's question of 'did we build the right model?' (fitness for intended use). In many model risk frameworks these are complementary but separate activities.

Common questions

Answers to the questions practitioners most commonly ask about Model Verification.

Is model verification the same as model validation?

No. Although the terms are often used interchangeably in practice, many frameworks treat them as distinct. Verification typically asks whether the model was built correctly—whether the implementation, code, and computations faithfully reflect the intended design and specifications. Validation typically asks whether the right model was built—whether the model is conceptually sound and fit for its intended purpose. Conflating the two is a frequent error; an organization can verify that a model is implemented as designed while still failing to validate that the design is appropriate for the use case.

Does verifying a model confirm that it performs well or produces accurate outputs?

Not necessarily. Verification generally focuses on whether the model correctly implements its intended design, logic, and calculations—not on whether that design yields good real-world performance or accurate predictions. A model can pass verification and still perform poorly, because performance and fitness-for-purpose are more commonly addressed through validation and ongoing performance monitoring. Treating verification as evidence of accuracy is a common misconception.

What activities are typically involved in model verification?

Verification commonly includes checks that code and computations match the documented specification, reproduction of results, review of implementation logic, testing of calculations against expected outputs, and confirmation that data flows and parameters are correctly implemented. The specific activities vary by organization, model type, and applicable framework, so this list is illustrative rather than exhaustive.

Who is generally responsible for carrying out model verification?

Responsibilities vary by organizational structure and governance framework. Verification activities may involve model developers or owners within the first line, with independent review sometimes performed by a second-line function. Where independence and challenge are emphasized, some organizations separate those who build the model from those who verify or validate it. Exact assignment depends on an organization's operating model and any applicable regulatory expectations.

How does verification fit into a broader model risk management process?

Verification is typically one component within a wider set of activities that can include validation, performance monitoring, documentation, and ongoing review. In many frameworks it supports confidence that a model has been implemented as intended, which in turn supports—but does not replace—validation and monitoring. Its scope and placement in the lifecycle depend on the framework an organization adopts.

When is model verification typically performed?

Verification is often performed before a model is put into use and may be repeated when the model, its code, or its implementation environment changes. Some organizations also incorporate verification checks into ongoing review cycles. The timing and frequency depend on the organization's policies, the model's risk profile, and any applicable governance or regulatory expectations, so there is no single universal schedule.

Common misconceptions

Verification and validation are the same activity and can be used interchangeably.

As commonly defined, verification checks that a model conforms to its specification and was implemented correctly, while validation assesses whether the model is appropriate for its intended purpose and performs acceptably. Blurring the two can leave gaps in a model risk program.

Successful verification means the model is low risk or fit for use.

Verification confirms correct implementation against specification; it does not by itself establish that the underlying design is sound or that the model performs well in its intended context. Verification measures reduce certain risks but do not eliminate model risk.

Verification is a one-time step completed before deployment.

In many frameworks, verification is revisited when models are changed, recalibrated, or re-implemented, since code changes and environment shifts can break conformance to the original specification.

Best practices

Maintain clear, versioned design specifications so verification has an authoritative reference point against which implementation can be checked.

Keep verification distinct from validation in your documentation and workflow, and record which activity addressed which question to avoid coverage gaps.

Establish reproducibility by documenting inputs, environment, and transformation steps so that model outputs can be independently regenerated.

Re-perform relevant verification whenever code, configuration, or the deployment environment changes, rather than treating it as a single pre-deployment gate.

Assign verification responsibilities in a way consistent with your organization's lines-of-defense structure, avoiding reliance solely on the developers who built the model.

Document verification findings, limitations, and any unresolved discrepancies so downstream validation and oversight functions can act on them.