2. Foundational concepts

Simulation-based evidence is only as trustworthy as the process that produced it. Regulators, certification bodies, and safety assessors do not accept a simulation model because it looks plausible or because it runs without errors; they accept it because its credibility has been established through a documented, auditable process. That process is VV&A — verification, validation, and accreditation. These three terms are frequently conflated in everyday engineering speech, but in a regulatory context they carry distinct, non-interchangeable meanings. Getting the terminology wrong is not a semantic quibble: it can invalidate an evidence package, because each term maps to a different activity, a different responsible party, and a different class of objective evidence.

Verification: "Did we build the model right?"

Verification is the process of determining whether a computational model, as implemented, correctly represents the conceptual model and its governing equations. It is an inward-facing, developer-oriented activity. Verification asks whether the software solves the equations it claims to solve, whether the numerical scheme is implemented correctly, whether units are consistent, and whether discretization error is controlled. It says nothing about whether the underlying physics is appropriate for the real system.

Verification splits into two recognized sub-activities. Code verification establishes that the source code is free of programming errors, typically through comparison against analytical solutions or the method of manufactured solutions. Calculation verification (also called numerical verification) quantifies the numerical error in a specific simulation run — mesh convergence studies, time-step sensitivity, iterative convergence tolerance checks. In a regulatory submission, calculation verification is usually the more visible of the two, because it produces the discretization-error estimate that must accompany any quantitative result.

A practical calculation-verification step for a thermal-hydraulic model might proceed as follows. Run the same transient on three systematically refined meshes (e.g., nominal cell size 50 mm, 25 mm, 12.5 mm) with a fixed refinement ratio of 2. Extract the peak cladding temperature from each run — say 612.4 K, 618.9 K, and 621.7 K. Apply Richardson extrapolation to estimate the continuum value and the observed order of accuracy. If the observed order collapses relative to the formal order of the scheme, that is a red flag: it usually indicates that the refinement is entering an asymptotic range too slowly, that boundary conditions are mesh-dependent, or that a limiter is active in the region of interest. The deliverable is a documented grid-convergence index (GCI) or equivalent error band, not merely a statement that "a mesh study was performed."

Validation: "Did we build the right model?"

Validation is the process of determining the degree to which a model is an accurate representation of the real world from the perspective of the intended use. It is outward-facing and evidence-driven: it compares simulation output against experimental or plant data that were not used to calibrate the model. The phrase "from the perspective of the intended use" is the regulatory hinge. A model can be valid for one figure of merit and invalid for another; validation is always scoped to specific quantities of interest (QOIs), a specific operating envelope, and a stated acceptance criterion.

Validation evidence is graded by its independence and relevance. A common hierarchy runs from unit-level experiments, through separate-effects tests, to integral-effects tests and finally to plant or field data. Regulators generally weight integral-effects and independent data most heavily, because they exercise the coupled phenomena that dominate safety-relevant transients. A validation matrix should record, for each QOI, the data source, the operating conditions covered, the comparison metric (bias, relative error, or a statistical acceptance test), and the outcome.

Accreditation: the regulatory decision

Accreditation is the formal determination by an authoritative body that a model is acceptable for a specific intended use within a defined regulatory context. It is not an activity performed by the model developer; it is a judgment issued by the reviewer or regulator, based on the verification and validation evidence plus considerations of consequence, uncertainty, and application scope. Accreditation is therefore always conditional and bounded: it applies to a stated use, a stated envelope, and often a stated set of limitations.

This is where the terminology matters most in practice. A developer verifies and validates; the regulator accredits. A submission that claims its own model is "accredited" without an external determination has misused the term. Equally, an accreditation granted for steady-state normal operation does not extend to a design-basis accident transient unless that extension was explicitly evaluated.

How the three fit together

The relationship is best understood as a chain of evidence with a decision gate at the end. Verification establishes numerical credibility; validation establishes physical credibility against data; accreditation converts both into a bounded regulatory permission. The figure below shows this structure, including the feedback paths that make VV&A iterative rather than linear.

Regulatory definitions and why wording matters

Different regulatory frameworks phrase these definitions slightly differently, but the substantive content converges. The table below summarizes the working definitions that a submission should adopt, together with the responsible party and the typical objective evidence for each.

Applying the terminology in a submission

In practice, the discipline that separates a defensible package from a vulnerable one is traceability. Every QOI in the safety case should trace back to a validation case, which in turn should trace back to a verification record for the numerical settings used. A compact traceability entry might read: QOI = peak cladding temperature during a large-break LOCA; validation case = integral-effects test IET-07, independent of calibration; acceptance criterion = absolute bias ≤ 15 K over the covered pressure range; verification = mesh convergence study with GCI = 3.1% at the nominal mesh; accreditation scope = 5–15 MPa, hot-leg break spectrum only.

Two failure modes recur in review. The first is scope creep: an accreditation granted for one envelope is cited in a later submission for a different envelope without re-evaluation. The second is evidence laundering: calibration data presented as validation data, or a code-verification exercise presented as if it demonstrated physical accuracy. Both are detectable through a well-maintained traceability matrix, and both are far cheaper to prevent at the drafting stage than to remediate after a formal review comment.

The terminology is therefore not administrative overhead. It encodes a division of labor and a chain of custody for evidence. Verification produces numerical credibility, validation produces physical credibility, and accreditation converts both into a bounded permission to rely on the simulation in a safety decision. Keeping the three distinct — in the report structure, in the traceability matrix, and in the language of every claim — is the foundation on which the rest of a simulation-based evidence package is built.