4. Program initiation

A CAE simulation verification program rarely fails because the solver was wrong. It fails because nobody agreed, at the start, on what "verified" was supposed to mean. Program initiation is the phase where that ambiguity is removed. Before a single mesh is generated, the program team must convert a vague request — "we need to validate the crash model" or "the thermal results should be trustworthy" — into a set of explicit verification objectives, measurable success criteria, and a documented agreement among the stakeholders who will consume the evidence.

This chapter treats initiation as an engineering deliverable, not a kickoff meeting. The output is a Verification Program Charter: a short, controlled document that fixes scope, objectives, acceptance thresholds, evidence requirements, and ownership. Everything downstream — test plans, correlation runs, review gates — inherits its authority from this charter.

From Request to Verification Objective

A verification objective is a statement of what claim the simulation evidence must support, expressed in terms of the physical quantity, the operating condition, and the decision it informs. Compare these two formulations:

• Weak: "Verify the underhood thermal model."
• Usable: "Demonstrate that the underhood thermal CFD model predicts component surface temperatures within ±8 °C of measurement at the three thermocouple locations defined in TP-114, for the idle-soak and 60 km/h cruise conditions, to support the decision to release the harness routing for tooling."

The usable version names the quantity (surface temperature), the tolerance (±8 °C), the reference data (TP-114 thermocouples), the conditions (idle-soak, 60 km/h cruise), and the decision at stake (harness routing release). Each of these elements is negotiable — but only during initiation. Once the charter is signed, changing the tolerance means re-opening the program, not quietly relaxing a comparison plot.

A practical technique is to decompose each objective into a claim–evidence–criterion triple. The claim is the assertion the model must support. The evidence is the specific artifact that will be produced (correlation plot, energy balance table, modal assurance criterion matrix). The criterion is the numeric or logical test applied to that evidence. Writing these three columns side by side exposes objectives that sound reasonable but have no defined evidence path.

Choosing Success Criteria That Can Actually Be Evaluated

Success criteria fall into three families, and a mature program uses all three rather than relying on a single global error metric.

Two rules keep criteria honest. First, every criterion must be computable from data that the program has committed to acquiring — if the tolerance references a measurement that no test plan covers, the criterion is fiction. Second, criteria must be fixed before correlation results are seen. A useful governance device is to record the criteria in the charter with a version number and require a formal change note, reviewed by the same stakeholders, for any modification.

Stakeholder Alignment and the Decision Map

Stakeholders in a verification program are not a mailing list; they are the people whose decisions depend on the evidence. Alignment means each of them has agreed, in writing, to three things: the objective, the acceptance threshold, and the consequence of a failed criterion. The consequence is the element most often skipped, and it is the one that determines whether the program has real authority.

A decision map makes this explicit. For each objective, identify the decision owner, the evidence consumer, and the escalation path if the criterion is not met. Typical roles in a CAE verification program include the simulation lead (produces evidence), the test engineer (produces reference data), the design owner (consumes the conclusion), and the program manager (arbitrates schedule and scope). Where a single person holds two roles, that should be recorded — it is a risk, not a convenience.

Alignment is achieved through a structured initiation review rather than a broadcast. The review walks each objective through its claim–evidence–criterion triple and asks the decision owner to confirm the threshold is sufficient for their decision. Disagreement at this stage is cheap; disagreement after correlation is expensive. The output of the review is a signed charter with a stakeholder register and a RACI-style assignment of evidence ownership.

Worked Example: Underhood Thermal Verification Charter

Consider a program to release harness routing for a new engine bay. The request arrives as "confirm the thermal model is good enough." The initiation team converts this into the following charter content.

Verification Program Charter — UHT-2024-07 (v1.0)
Objective 1: Predict harness surface temperature at TC-1..TC-3
  Claim:    CFD model supports harness routing release
  Evidence: correlation plot vs TP-114 measurements
  Criterion: |ΔT| <= 8 degC at each probe, both conditions
  Decision: harness routing release for tooling (owner: D. Reyes)

Objective 2: Predict total underhood heat rejection
  Claim:    energy balance is representative of vehicle level
  Evidence: heat rejection table, CFD vs test
  Criterion: total within 4 % of measured, both conditions
  Decision: cooling pack sizing confirmation (owner: M. Okafor)

Conditions: idle-soak (30 min), 60 km/h cruise (steady)
Reference data: TP-114, 3 thermocouples, 2 flow meters
Change control: any criterion change requires charter revision

Note what the charter does not contain: mesh statistics, turbulence model selection, or solver settings. Those are implementation choices owned by the simulation lead. The charter fixes only what the decision owner needs to trust the conclusion. This separation is what keeps initiation fast and prevents the charter from becoming a modeling specification.

Failure Modes at Initiation

Three failure modes recur across programs and are worth naming explicitly.

• Retrofit criteria. The team runs the correlation first, observes 11 % deviation, and then writes a 12 % tolerance into the charter. The charter must be versioned and dated before correlation data is examined; otherwise it provides no protection.
• Proxy stakeholders. A manager signs on behalf of the design owner without that owner reviewing the thresholds. When the criterion later fails, the design owner disputes the evidence requirement. Every decision owner must sign their own objective.
• Unbounded scope. The objective references "all operating conditions" without enumerating them. This makes the evidence path infinite and the program unclosable. Enumerate conditions explicitly, even if the list is short.

Closing the Initiation Phase

Initiation is complete when four conditions hold: every objective has a claim–evidence–criterion triple; every criterion is computable from committed data; every decision owner has confirmed their threshold in the initiation review; and the charter is signed with a version number and an active change-control rule. At that point the program can move into test planning and model build with a stable definition of success — and any later dispute about whether the model is "good enough" is resolved by reading the charter, not by renegotiating the meaning of the results.