1. CAE Numerical Quality Assurance and Model Release Auditing

Computer-aided engineering has become the primary evidence base for many engineering decisions that were once validated by physical testing. A crashworthiness sign-off, a fatigue life estimate for a welded bracket, a thermal margin on a battery pack, or a pressure-drop prediction for a coolant manifold may now reach a design review as a contour plot and a number, with no test coupon behind it. That shift is economically rational, but it transfers a burden: the credibility of the decision now depends on the credibility of the numerical model. CAE numerical quality assurance (NQA) is the discipline that makes that credibility explicit, traceable, and repeatable. Model release auditing is the gate through which a model, and the results derived from it, are formally accepted for use.

This chapter establishes the scope of both activities, identifies the regulatory and commercial drivers that make them non-optional in regulated industries, and quantifies why unverified simulation is expensive — not merely in the abstract sense of "bad decisions," but in the specific currencies of rework, recall, certification delay, and lost engineering trust.

Defining the scope: verification, validation, and release

The vocabulary matters because the three activities answer different questions and are often conflated in practice.

• Verification asks: are we solving the equations correctly? It covers code verification (does the solver reproduce known analytical or manufactured solutions?), discretization verification (is the mesh fine enough, is the time step stable, is the solution converged?), and procedural verification (was the correct material card, unit system, and boundary condition applied?).
• Validation asks: are we solving the right equations for this physical situation? It is the comparison of simulation output against experimental data with quantified uncertainty, over the range of conditions for which the model will be used.
• Release auditing asks: is this specific model, at this specific revision, fit for this specific decision? It is a documented, independent review that confirms the verification and validation evidence, the assumptions register, the intended use envelope, and the sign-off authority.

A common failure mode is to treat these as a single checkbox. A model can be fully verified and still invalid for the intended use — for example, a linear-elastic model verified to machine precision but applied to a joint that yields. Conversely, a model validated for one load case can be released for that case and silently misapplied to another. NQA keeps the three activities distinct and links them through an explicit intended use statement.

Regulatory and standards drivers

In safety-critical sectors, the expectation that simulation be controlled is written into regulation and consensus standards. The exact clauses vary, but the pattern is consistent: the applicant must demonstrate that the computational method is appropriate, that it has been verified, and that its limitations are understood and documented.

Two standards deserve specific mention because they define the vocabulary used throughout this course. ASME V&V-10 addresses verification and validation in computational solid mechanics; ASME V&V-20 addresses computational fluid dynamics and heat transfer. Both introduce the concept of credibility as a graded quantity built from verification evidence, validation evidence, uncertainty quantification, and sensitivity analysis — not a binary pass/fail. The FDA's guidance on reporting computational modeling studies follows a similar logic, scaling the required evidence to the risk of the decision the model informs.

The practical consequence is that a release audit is not an internal nicety. In a regulated programme, the audit trail is the evidence. If a reviewer cannot reconstruct which solver version, which mesh, which material revision, and which boundary conditions produced a reported margin, the margin is not defensible — regardless of whether the number happens to be correct.

The cost of unverified simulation

Unverified simulation is expensive in ways that are easy to underestimate because the costs are distributed and delayed. Four categories dominate.

Rework and late discovery. A modelling error found during design iteration costs hours. The same error found after tooling release costs weeks and capital. The multiplier is not linear; it is driven by how many downstream commitments were made on the strength of the number. A misapplied unit system (a classic: Young's modulus entered in MPa while geometry is in metres, producing a stiffness three orders of magnitude wrong) is trivial to catch with a units check and catastrophic to catch after a mould is cut.

Certification and homologation delay. Regulators increasingly ask for the simulation basis behind a declaration. If the basis is undocumented, the applicant must either reconstruct it under time pressure or revert to physical test — the very cost the simulation was meant to avoid. A single unsubstantiated model can hold an entire submission.

Recall, warranty, and liability. When a field failure traces back to a design decision justified by simulation, the quality of that simulation becomes a legal question. Was the model validated for the failure mode? Were the limitations documented? Was the release audited? An unverified model provides no defensible answer, and the exposure extends beyond the direct recall cost.

Erosion of engineering trust. This is the quietest and most damaging cost. When analysts and decision-makers learn that simulation numbers are sometimes wrong and there is no way to tell which ones, they stop relying on simulation and revert to test-heavy, schedule-heavy conservatism. The organisation pays for CAE software and analysts but does not receive the decision-speed benefit. Rebuilding that trust requires a visible, consistent quality record.

How the pieces connect

The diagram below shows the relationship between the model lifecycle, the verification and validation evidence that accumulates alongside it, and the release gate that converts that evidence into an authorised decision. Note that the audit is not a final inspection bolted onto the end; it consumes evidence generated at every stage, and a missing item at any stage blocks release.

What a release audit actually examines

An audit is a structured interrogation of the model package against the intended use. In practice, a competent audit covers the following, and each item must be traceable to a document, a file, or a recorded decision:

1. Intended use and risk class. What decision does this model inform, and what is the consequence of being wrong? This sets the required depth of evidence.
2. Configuration identity. Geometry revision, material card revision, solver name and version, meshing tool version, and the exact input deck or project file. A result without a configuration identity is not a result; it is an anecdote.
3. Verification record. Code verification evidence for the element types and solvers used, mesh convergence data (typically a plot of a quantity of interest versus element count or characteristic size, showing asymptotic behaviour), and time-step or iteration convergence for transient and nonlinear analyses.
4. Validation record. The experimental dataset, the test conditions, the correlation metric, and the quantified discrepancy. Where no test exists, the basis for engineering judgement must be stated explicitly.
5. Assumptions and limitations. A register of what the model does not represent — idealised welds, omitted contact nonlinearity, isotropic material where the real part is anisotropic — and the sensitivity of the conclusion to each.
6. Result interpretation. Are the extracted quantities the right ones, taken at the right locations, with the right sign convention and coordinate system? Peak stress at a singularity, for example, is mesh-dependent and should not be reported as a design margin without a defined extraction method.
7. Independence and authority. Who performed the work, who checked it, and who is authorised to release it. The checker should not be the originator for high-risk models.

Why this matters before the first model is built

The scope, drivers, and cost arguments converge on a single design principle for the rest of this course: quality must be engineered into the CAE workflow, not inspected in at the end. The intended use statement, the units and coordinate-system convention, the convergence study plan, and the validation case selection are all decisions made early and cheaply. The release audit is where they are confirmed, not where they are created. Organisations that treat NQA as a gate at the end of the pipeline pay for it in rework; organisations that treat it as a thread running through the pipeline get faster releases, because the evidence is generated as a by-product of doing the work properly.

The chapters that follow build out each element of this framework: how to write and use an intended use statement, how to plan and document mesh and time-step convergence, how to design a validation campaign with quantified uncertainty, how to structure the assumptions register, and how to run a release audit that is fast, repeatable, and defensible under regulatory scrutiny.