2. Configuration items and baselines

Configuration management for simulation models begins with a deceptively simple question: what exactly are we controlling? A simulation model is rarely a single file. It is an assembly of model source, compiled artifacts, parameter sets, input decks, solver settings, post-processing scripts, and the toolchain that turns all of these into a runnable experiment. If any one of these elements changes without being tracked, a result that appears reproducible may in fact be irreproducible. This chapter addresses the three foundational activities that make simulation evidence trustworthy: identifying configuration items, establishing baselines, and defining a configuration identification scheme that remains stable across the model lifecycle.

From Model to Configuration Item

A configuration item (CI) is any entity that is placed under configuration control because it can affect the behavior, validity, or interpretation of the simulation. The critical word is affect. Not every file in a project directory deserves CI status; treating everything as a CI produces administrative noise and dilutes attention. The practical test is impact-based: if this artifact changed, could a reviewer reasonably question whether a prior result still holds? If yes, it is a candidate CI.

For simulation models, configuration items typically fall into five families. Model definition items include the source model (block diagrams, equations, state machines), the model library versions referenced, and any generated code. Parameter and calibration items include parameter sets, lookup tables, calibration datasets, and the provenance of each calibrated value. Experiment definition items include input decks, stimulus profiles, solver configuration (step size, tolerance, integrator type), and stop-time settings. Toolchain items include the simulation tool version, compiler, operating system, and any plugins or co-simulation interfaces. Evidence items include the scripts that generate results, the reference outputs used for regression, and the analysis notebooks that transform raw signals into reported metrics.

A common failure mode is to control only the model source and neglect the experiment definition. Two engineers can run the "same model" and obtain different results because one used a fixed-step solver at 1 ms and the other used a variable-step solver with a 1e-6 relative tolerance. Neither is wrong, but the results are not comparable. If solver settings are not configuration items, the organization has no mechanism to detect this divergence.

Establishing Baselines

A baseline is a frozen, identified, and approved set of configuration items at a specific point in time. The essential property is immutability: a baseline is a snapshot that does not move. Changes after the baseline are recorded as deltas against it, not as silent edits to it. This is what allows a reviewer in month nine to reconstruct exactly what was run in month two.

Baselines are not all equivalent. In simulation practice, three baseline types recur. A functional baseline captures the model at the point its requirements and intended behavior are agreed — typically the model definition plus its verification cases, before calibration. A developmental baseline captures an intermediate state during calibration or model refinement, and is used to compare candidate improvements against a known reference. An allocated or release baseline captures the complete, approved configuration used to produce evidence for a specific decision — the model, parameters, experiment definitions, toolchain, and analysis scripts together.

The release baseline is the one that matters most for evidence provenance, because it is the object that a simulation result is ultimately attributed to. A release baseline should be complete enough that an independent engineer, given only the baseline contents and the toolchain, can reproduce the reported result. If reproduction requires undocumented knowledge — "oh, you also need to set the environment variable to point at the license server" — the baseline is incomplete.

Defining the Configuration Identification Scheme

Identification is the mechanism that makes baselines referenceable. Without a scheme, a baseline is just a folder with a date in its name, and two people will refer to it differently. A workable identification scheme for simulation models has four properties: uniqueness, stability, traceability, and human readability.

Uniqueness means no two distinct configurations share an identifier. Stability means an identifier, once assigned, is never reused for different content. Traceability means the identifier resolves to the exact item versions it contains. Human readability means an engineer can tell, from the identifier alone, roughly what it refers to and when it was created.

A practical scheme combines a project prefix, a baseline type code, a sequence number, and a content hash or revision tag. For example:

PRJ-VEH-BRAKE-FBL-0003
PRJ-VEH-BRAKE-DBL-0011
PRJ-VEH-BRAKE-RBL-0007@sha256:9f2c...a41d

Here FBL, DBL, and RBL denote functional, developmental, and release baselines respectively. The sequence number is monotonic and never reused. The release baseline additionally carries a content hash computed over the manifest of item versions, which provides a cryptographic guarantee that the baseline contents have not been altered. The hash is not a substitute for the human-readable identifier; it is a verification anchor.

Each configuration item within a baseline also needs its own identifier and version. A common and effective pattern is to version items independently and record the exact version in the baseline manifest, rather than versioning the whole project as one monolith. This allows a parameter set to advance through several revisions while the model source remains at a stable version, and the baseline manifest records the specific combination.

Worked Example: A Brake Controller Model

Consider a simplified brake controller model used to evaluate stopping distance under varying road friction. The team is preparing to submit simulation evidence for a design review. The following manifest represents a release baseline; the values are illustrative and chosen for teaching purposes, not measured results.

The release baseline identifier for this manifest might be PRJ-BRK-RBL-0004@sha256:.... When the design review asks "what produced Figure 7?", the answer is a baseline identifier, and the manifest resolves every input. If a reviewer later suspects the friction table was updated after the review, the hash over the manifest detects any post-hoc change to the recorded versions.

What the Scheme Must Capture That a File Tree Does Not

A version control repository captures file content, but it does not automatically capture the relationships that matter for simulation evidence. The identification scheme must additionally record: which parameter values were calibrated and from what source data; which solver settings were used and why; which tool build was used, including patches; and which analysis scripts transformed raw outputs into reported metrics. These are the elements most often lost when a result is handed off, and they are precisely the elements a reviewer needs.

The figure below shows how the five CI families converge into a release baseline, and how the baseline identifier anchors the provenance chain from model definition through to reported evidence.

Common Pitfalls and How to Avoid Them

Over-scoping. Placing every intermediate file under control slows the team and obscures the items that matter. Scope by impact on results, and revisit the scope when a new class of artifact begins to influence reported evidence.

Under-scoping the experiment. Solver settings, stop time, and input decks are frequently omitted. Treat them as first-class CIs, because they change results as surely as the model does.

Mutable baselines. A baseline that is edited after approval is not a baseline. Corrections must be issued as a new baseline with a new identifier, and the superseded baseline retained for traceability.

Identifier reuse. Reusing a sequence number after a deletion destroys traceability. Sequence numbers are monotonic and never recycled, even for withdrawn baselines.

Hash without manifest. A content hash is only meaningful if the manifest it covers is itself well-defined and complete. Compute the hash over an explicit, ordered manifest of item identifiers and versions, not over an arbitrary directory listing.

With configuration items identified, baselines frozen, and an identification scheme in place, the organization has the structural foundation for provenance. The next concern is how changes to these controlled items are proposed, evaluated, and recorded — the subject of change control, which builds directly on the baseline structure established here.