3. Intended use statement fundamentals

An intended use statement is the anchor document of a virtual test model (VTM) claim. It answers a deceptively simple question: what decision is this model allowed to support, for which system variant, under which operating conditions, and with what evidence? Everything downstream — verification strategy, validation datasets, credibility metrics, and the wording of the final claim — is derived from this statement. When the intended use is vague, the claim becomes unfalsifiable; when it is over-specified, the model becomes expensive to qualify and brittle to change. This chapter establishes the four structural elements of a defensible intended use statement and draws the critical line between what a model is capable of computing and what it is intended and qualified to be used for.

Purpose: the decision the model must support

The purpose element names the engineering decision and the decision-maker, not the physics the model simulates. "Predict brake disc temperature" is a capability description; "support the thermal fade margin decision for the front brake corner during a 10-stop downhill descent, owned by the chassis integration team" is a purpose. A well-formed purpose has three properties:

• Decision-linked. It identifies a concrete choice — pass/fail against a requirement, selection between design candidates, sizing of a component, or prioritization of a test campaign.
• Consequence-aware. It states what happens if the model is wrong, which sets the credibility rigor. A model informing a comfort tuning trade-off tolerates far more error than one gating a safety release.
• Bounded in time. It references the program phase (concept, detailed design, verification, certification support) because acceptable fidelity changes across phases.

A useful test for the purpose statement: could a reviewer, given only this sentence, decide whether a proposed validation experiment is relevant? If not, the purpose is still too abstract.

Scope: the system, variants, and boundaries covered

Scope defines the envelope of the model's applicability in system terms. It should enumerate the system under test, the variants explicitly covered, the interfaces treated as boundary conditions, and the items deliberately excluded. Consider a battery pack thermal model intended to support cooling-plate sizing:

Exclusions are as important as inclusions. Every excluded item is a place where the model may be silently misapplied, so exclusions should be written as explicit prohibitions ("not valid for…") rather than omissions. When a variant is added later, the scope table is the change-control trigger: the model may be technically capable of running the new variant, but it is not intended for it until the scope is revised and the supporting evidence extended.

Context of use: how the model sits in the workflow

Context of use (CoU) describes the operational setting: who runs the model, with what inputs, at what point in the process, and how the output is consumed. Two models with identical physics can have entirely different CoUs — one used offline by a simulation specialist to rank five cooling-plate concepts, another embedded in an automated regression suite that flags thermal violations nightly. The CoU determines:

• Input provenance. Are inputs measured, derived from a higher-fidelity model, or assumed? A model fed by CAE-derived heat loads inherits the uncertainty of that upstream model.
• Output consumption. Is the output a number compared to a threshold, a trend, or a distribution feeding a reliability calculation? Threshold comparison demands tight bias control; trend use tolerates offset.
• User competence. A specialist can recognize implausible results; an automated pipeline cannot, so the model must carry its own guardrails (input range checks, validity flags).
• Turnaround and repeatability. Interactive use permits minutes-to-hours runtimes; regression use demands deterministic, minutes-scale execution.

Capability is not intended use

The most common failure in VTM claims is conflating what the model can do with what it is qualified to do. A multibody vehicle model may be capable of simulating a 90 km/h moose test, a 30 % slope start, and a tire blowout — the solver will happily produce numbers for all three. But capability is a property of the equations; intended use is a property of the evidence. The model is intended for a maneuver only when validation data exist for that maneuver, the operating envelope has been exercised, and the uncertainty has been shown acceptable for the decision at hand.

This distinction has a practical consequence: the intended use statement should be written before validation, as a hypothesis about the evidence needed, and then confirmed or narrowed after validation. If validation reveals that the model predicts peak cell temperature within ±2 °C for steady 1C discharge but diverges by 8 °C during 3C fast-charge pulses, the intended use is not "invalidated" — it is narrowed to exclude fast-charge decisions, and the scope table is updated accordingly. Capability claims that outrun evidence are the root of most credibility disputes in model-based engineering.

From statement to working artifact

The four elements are best captured in a single controlled record that travels with the model. A minimal, fillable form for the battery thermal example looks like this:

VTM INTENDED USE RECORD — VTM-BT-014 (rev 2)
Purpose:      Support cooling-plate sizing decision for front pack;
              pass/fail on peak cell temperature ≤ 55 °C.
Decision owner: Battery thermal integration lead.
Scope:        Standard & long-range packs; 96S configuration;
              coolant 15–40 °C, 20–40 L/min; ambient −10 to +45 °C.
              NOT valid for: performance pack, sub-zero cold soak,
              fast-charge above 2C, cell-level internal gradients.
Context of use: Offline concept-phase study; inputs from CAE heat
              load map v3; output = peak cell temperature per module;
              user = thermal engineer; runtime target < 30 min.
Capability note: Solver supports 3C pulses and −20 °C, but no
              validation data exist → excluded from intended use.
Evidence ref: VAL-BT-014-A (steady 1C), VAL-BT-014-B (WLTC profile).
Status:       Approved for concept phase only; re-review at DV gate.

Note the "capability note" line: it records the known-but-unqualified region explicitly, so that a future user who needs fast-charge analysis knows the model is a candidate but requires an evidence extension, not a silent reuse. This single field prevents the most expensive category of model misuse — running a capable model outside its qualified envelope and treating the output as decision-grade.

Common pitfalls and how to detect them

• Purpose written as physics. "Simulates thermal propagation" describes the model, not the decision. Detection: ask "what would the engineer do differently based on the output?" If there is no answer, rewrite.
• Scope by omission. Exclusions left implicit. Detection: for each interface and variant in the program, state explicitly whether it is in or out.
• CoU assumed rather than stated. The model is reused in an automated pipeline without input-range checks. Detection: trace every consumer of the model output and confirm the CoU matches.
• Capability inflation. The statement claims envelope coverage that validation never exercised. Detection: overlay the validation test matrix on the scope table; any uncovered cell is an evidence gap, not a covered use.

With the four elements defined and the capability boundary drawn, the next step in the claim workflow is to translate this statement into measurable credibility requirements — the subject of the following chapter. For now, the discipline to carry forward is simple: every sentence in the intended use statement should be traceable either to a decision, a scope boundary, a workflow fact, or a piece of evidence. Sentences that trace to none of these are decoration, and decoration in a claim document is a liability.