4. Claim definition fundamentals
In a Virtual Test Model (VTM) program, the single most consequential artifact is not the model itself but the claim that the model is used to support. A claim is a declarative, falsifiable statement about a system, subsystem, or behavior that the VTM is intended to substantiate with evidence. Without a well-formed claim, simulation results become anecdotes: they may be interesting, but they cannot be audited, defended, or reused. This chapter establishes what makes a statement a legitimate claim, how claims are classified by type, and how claim strength governs the evidence burden placed on the model.
What Constitutes a Claim
A statement qualifies as a claim only when it satisfies four properties simultaneously. First, it must be declarative — it asserts something that can be true or false, not a goal ("improve braking performance") or a question. Second, it must be scoped: it names the system under test, the operating conditions, and the boundary of validity. Third, it must be falsifiable: there exists an observation, measurement, or logical argument that could refute it. Fourth, it must be traceable: every element of the claim maps to a requirement, a model element, and an evidence artifact.
Consider the difference between these two statements:
- "The electronic parking brake engages reliably." — not a claim. "Reliably" is undefined, no conditions are given, and no observation could refute it.
- "Under a 15% grade at −20 °C, the electronic parking brake reaches full clamping force within 400 ms of the apply command, for 10,000 consecutive cycles." — a valid claim. It names the condition (15% grade, −20 °C), the measurand (clamping force, time-to-clamp), the threshold (400 ms), and the repetition basis (10,000 cycles).
A practical discipline is to express every claim in a canonical form: [System] under [conditions] exhibits [behavior/measurand] within [tolerance] as evidenced by [method]. This template forces the author to commit to conditions and tolerances before any simulation is run, which prevents the common failure mode of retrofitting the claim to whatever the model happened to produce.
Claim Types: Predictive, Comparative, and Diagnostic
Claims differ in what they assert about the relationship between the model and the real system. The three canonical types carry different evidence requirements and different failure modes.
Predictive claims assert an absolute property of the system — a value, a threshold, or a behavior that the model is expected to reproduce with quantified accuracy. Example: "Peak junction temperature of the inverter power module stays below 150 °C during a 30-second 400 A pulse at 65 °C coolant." Predictive claims demand the strongest validation evidence because they stand alone: if the model is wrong, there is no reference to fall back on. They require calibration data, uncertainty quantification, and a documented validation domain.
Comparative claims assert a relative relationship — that design A outperforms design B, or that a modified controller reduces overshoot relative to a baseline. Example: "Controller variant C reduces settling time by at least 20% compared with the production baseline under the same step-input profile." Comparative claims are more robust to absolute model error because systematic biases tend to cancel between the two configurations. However, they are sensitive to differential error: if the model represents the two variants with unequal fidelity, the comparison is invalid even when each variant is individually plausible.
Diagnostic claims assert that the model can discriminate between system states — healthy versus faulty, nominal versus degraded. Example: "The model reproduces the 0.8 Hz torsional oscillation signature that distinguishes a worn damper from a nominal one." Diagnostic claims are judged not by value accuracy but by separability: the model must place the signatures of the compared states far enough apart, relative to noise and model uncertainty, that a classifier or human reviewer can distinguish them.
| Claim type | Asserts | Primary evidence | Dominant risk |
|---|---|---|---|
| Predictive | Absolute value or behavior within tolerance | Validation against physical test, uncertainty bounds | Absolute model bias outside validation domain |
| Comparative | Relative difference between configurations | Paired runs, differential error analysis | Asymmetric fidelity between variants |
| Diagnostic | Separability of system states | Signature margin, confusion matrix, noise floor | Insufficient margin under realistic noise |
Claim Strength Levels
Claim strength describes how much confidence the organization places in the claim and, correspondingly, how much evidence the VTM must supply. Strength is not the same as claim type: a predictive claim can be weak or strong depending on the evidence tier. A widely used four-level scheme is:
- Level 1 — Exploratory. The claim is used to guide design exploration. Evidence: model plausibility, sanity checks, expert review. No formal validation required, but the claim must be labeled as non-authoritative.
- Level 2 — Indicative. The claim informs trade studies and early decisions. Evidence: partial validation against a limited test set, documented validation domain, qualitative agreement on trends.
- Level 3 — Substantiated. The claim supports design release or requirement verification. Evidence: quantitative validation across the full operating envelope, uncertainty quantification, and a documented correlation study with residuals within stated tolerances.
- Level 4 — Certifying. The claim substitutes for physical test in a regulated or safety-critical decision. Evidence: Level 3 plus independent review, configuration-controlled model baseline, and a formal argument that the validation domain covers all claimed conditions.
Strength levels are assigned per claim, not per model. A single VTM may carry a Level 4 claim for steady-state thermal behavior and a Level 2 claim for transient electromagnetic behavior, provided each claim's evidence package is scoped accordingly. This granularity is essential: it prevents the common anti-pattern of declaring an entire model "validated" when only one behavior has been correlated.
From Claim to Evidence: A Worked Example
Suppose a team is evaluating a battery thermal management VTM for a 60 kWh pack. They draft the following claim: "Under a 1C continuous discharge at 35 °C ambient, the maximum cell temperature remains below 45 °C and the cell-to-cell spread remains below 3 K." This is a predictive claim. The team assigns Level 3 strength because it will be used to release the cooling plate design.
The evidence package must then include: (a) a validation test at 1C and 35 °C ambient with thermocouple instrumentation at the same cell locations the model reports; (b) a residual analysis showing predicted versus measured peak temperature and spread, with tolerances stated in advance (for example, ±1.5 K on peak and ±0.8 K on spread); (c) an uncertainty budget covering contact resistance, coolant flow rate, and sensor placement; and (d) a statement of the validation domain — if the physical test was run at 25 °C and 35 °C only, the claim cannot be extended to 45 °C ambient without additional evidence.
If the residual on peak temperature comes back at +2.4 K — outside the ±1.5 K tolerance — the claim is not substantiated at Level 3. The correct response is to investigate the model (likely the cell-to-coolant thermal resistance), recalibrate, and re-run the correlation, or to re-scope the claim to a narrower condition set where the residual is within tolerance. The claim is never adjusted to match the result after the fact.
Practical Guidance for Claim Authors
Three habits separate mature VTM programs from immature ones. First, write the claim before running the model. A claim authored after the simulation is a description of the result, not a test of the model. Second, state tolerances numerically and in advance. "Good agreement" is not a tolerance; "±1.5 K on peak temperature" is. Third, record the validation domain explicitly. Every claim carries an implicit "within the conditions where the model has been correlated" clause, and making that clause explicit is what allows reviewers to judge whether a claim can be extended to a new operating point.
When a claim fails its evidence check, resist the temptation to weaken the claim silently. Instead, classify the failure: is it a model deficiency (recalibrate), a test deficiency (instrumentation or boundary conditions), or a claim-scoping error (the claim asserted more than the validation domain supports)? Each has a different remedy, and only the third is resolved by editing the claim — with a recorded rationale. This discipline is what makes claim strength meaningful rather than decorative, and it is the foundation on which the remaining chapters on evidence packages and intended-use arguments are built.