4. Model inventory and change impact assessment
When a design change or solver upgrade lands, the first question is rarely "how do we requalify everything?" It is "what actually moved?" A model inventory is the controlled record that answers this question. Without it, requalification becomes either an over-scoped campaign that burns weeks revalidating untouched models, or an under-scoped one that ships a regression because a downstream dependency was never traced. This section covers how to build and maintain that inventory, how to trace dependencies across models, and how to score criticality so requalification effort lands where risk actually lives.
What the inventory must capture
A useful inventory is not a file listing. Each entry should carry enough metadata to support impact queries. At minimum, record the model identifier, owning team, the tool and solver version it was last qualified against, the design baseline (drawing revision, CAD release, or parameter set), the qualification status and date, and the interfaces it consumes or exposes. Interfaces are the critical field: a model that reads a boundary condition file, a lookup table, or a co-simulation input from another model is a dependency edge, and that edge is what turns a local change into a cascade.
Keep the inventory machine-readable. A YAML or JSON registry checked into version control alongside the models gives you diffable history and lets you query impact programmatically. A minimal entry might look like this:
model_id: thermal-hx-014
owner: thermal-systems
solver: fluent-2024r2
design_baseline: cad-rel-7.3
qualified_on: 2025-11-04
status: qualified
consumes:
- fluid-props/water-iapws-v2.table
- boundary/inlet-profile-rel7.csv
exposes:
- outlet-temp-map
- pressure-drop-curve
criticality: high
The consumes and exposes lists are the dependency graph in disguise. When a change touches water-iapws-v2.table, a simple query over consumes returns every model that must be re-examined — no tribal knowledge required.
Tracing dependencies in both directions
Impact assessment runs in two directions, and conflating them is a common source of gaps. Upstream tracing asks: given a changed artifact, which models consume it? This is the forward query and it is usually straightforward if the inventory is complete. Downstream tracing asks the harder question: if this model's outputs shift, which models or decisions rely on them? A model can be perfectly requalified in isolation yet still invalidate a system-level result because its exposed output moved by 2%.
Build the graph as directed edges from producer to consumer, then run a breadth-first traversal from the changed node. The traversal depth matters: a solver upgrade typically affects every model using that solver (depth 1), plus every model consuming their outputs (depth 2), and so on. In practice, cap the traversal at the depth where output sensitivity falls below your tolerance — but document that cap, because it is a judgment call, not a fact.
In the graph above, the solver upgrade directly touches three models at depth 1. Only two of them expose outputs that feed further models, so the depth-2 set is system-loop-003 and load-case-011. Note that flow-duct-007 is low criticality and exposes nothing consumed downstream — it can be requalified last, or with a lighter smoke test, without holding up the campaign.
Scoring criticality for prioritization
Criticality is what converts a flat dependency list into a ranked work queue. Score it on dimensions that reflect actual consequence, not model size or team seniority. A workable scheme uses three factors, each rated 1–3:
| Factor | 1 (low) | 2 (medium) | 3 (high) |
|---|---|---|---|
| Safety / regulatory consequence | No safety function | Indirect influence | Direct safety or certification basis |
| Downstream fan-out | No consumers | 1–2 consumers | 3+ consumers or a system-level model |
| Output sensitivity to the change | <1% shift expected | 1–5% shift | >5% shift or sign/trend change |
Multiply the three ratings for a composite score from 1 to 27. In the example, thermal-hx-014 scores 3 × 2 × 3 = 18 (high), struct-frame-022 scores 2 × 1 × 2 = 4 (medium), and flow-duct-007 scores 1 × 1 × 1 = 1 (low). The composite is a prioritization aid, not a verdict: a model scoring 18 gets full requalification first, a 4 gets a targeted regression check, and a 1 gets a smoke test. Document the thresholds so the ranking is reproducible across reviewers.
Keeping the inventory honest
An inventory decays the moment it is created unless it is tied to the change process. Two practices keep it current. First, make inventory updates a gate: a design change or solver upgrade is not closed until the affected entries are updated and the impact query has been run and recorded. Second, run a periodic reconciliation that diffs the registry against the actual model repository and solver version files, flagging entries whose recorded solver version no longer matches what is installed. Stale solver versions in the inventory are the most common cause of a missed requalification.
From inventory to a requalification plan
The output of this section is a ranked, traceable work list: every affected model, its dependency depth, its composite criticality score, and the requalification depth that score justifies. That list is the input to scheduling and resource allocation in the next stage. The discipline that makes it trustworthy is simple — every edge in the graph is recorded, every score is reproducible from stated factors, and every query result is archived with the change record so that a later audit can reconstruct exactly why a given model was or was not requalified.