📚 Course ContentsChapter 4 Model configuration management planning

4. Model configuration management planning

Configuration management (CM) for simulation models fails most often not because the tools are weak, but because nobody decided in advance who may change what, under which conditions, and with what evidence. A model configuration management plan (CMP) converts that ambiguity into an auditable operating agreement. This chapter explains how to define roles, constitute a change control board (CCB), and write a CMP whose controls track the simulation lifecycle rather than an abstract document lifecycle.

Why planning precedes tooling

In a simulation evidence context, a model version is only meaningful when it is bound to a defined configuration: source model files, parameter sets, solver settings, input decks, post-processing scripts, and the toolchain versions that produced the results. If any of these can drift without a recorded decision, a result that was valid last month becomes unreproducible this month. The CMP exists to make that binding explicit and to define the decision rights around changing it. Tooling (Git, artifact repositories, requirement management systems) implements the plan; it cannot substitute for it.

A practical CMP answers four questions for every configuration item (CI): what is it, who owns it, how is it changed, and how is its state proven. The answers must be specific enough that two engineers independently reach the same conclusion when inspecting a baseline.

Roles and responsibilities

Role definitions should be tied to decisions, not job titles. A single person may hold several roles in a small team, but the separation of duties that matters — proposing versus approving a change — must be preserved. The following allocation is typical for a simulation programme supporting certification or design verification.

Role	Core responsibility	Key outputs
Configuration Manager (CM)	Maintains the CI register, baselines, and status accounting; administers the CCB agenda and records	CI register, baseline manifests, change log, configuration status reports
Model Owner	Accountable for model fidelity, intended use, and validity evidence; proposes and justifies changes	Change requests, validation evidence, model documentation
Simulation Engineer	Implements changes on controlled branches; runs regression and verification cases	Updated model files, test logs, verification reports
Verification & Validation (V&V) Lead	Independently confirms that changes preserve or improve validity for the declared use	V&V assessment, acceptance recommendation
CCB Chair	Convenes the board, arbitrates disposition, ensures decisions are recorded and executed	CCB minutes, disposition decisions
Tool/Environment Administrator	Controls solver, compiler, and library versions; maintains the reproducible execution environment	Environment manifest, toolchain baseline records

Two boundaries deserve emphasis. First, the Model Owner is accountable for fitness for intended use, not merely for code correctness; a numerically correct change that invalidates a previously accepted operating envelope is still a configuration change requiring assessment. Second, the CM role is administrative and custodial — the CM should not be the sole approver of technical changes, or the separation between proposal and approval collapses.

The change control board

The CCB is a decision forum, not a status meeting. Its membership should be the minimum set that can dispose of the changes on the agenda: the chair, the CM, the affected Model Owner, the V&V Lead, and — where the change touches interfaces or shared plant models — a representative of the consuming system. The Tool/Environment Administrator attends when toolchain changes are in scope.

Changes should be classified so that the board spends its time where risk is concentrated. A workable three-tier scheme:

Class 1 — baseline-affecting. Changes to model equations, solver configuration, parameter values outside a pre-approved tolerance band, or the toolchain. Require full CCB review, impact analysis, and re-validation before the baseline is updated.
Class 2 — bounded. Changes within an approved parameter envelope, documentation corrections, or test-case additions that do not alter model behaviour. May be approved by the Model Owner and V&V Lead under delegated authority, with retrospective CCB notification.
Class 3 — editorial. Comments, formatting, and non-executable metadata. Recorded in the change log; no board action.

The classification thresholds must be written down numerically. "Parameter changes within tolerance" is not a control; "parameter changes within ±2% of the baselined value, with the affected validation cases re-run and passing" is. The CCB should also define its quorum and the tie-breaking authority of the chair, because disputed dispositions are exactly the situations in which an undefined process stalls a programme.

A useful discipline: every CCB decision records the evidence reviewed, not just the outcome. "Approved" without a reference to the impact analysis and regression results is not a defensible record when the model is later challenged.

Aligning the CMP with the simulation lifecycle

Simulation models pass through distinguishable phases, and the intensity of configuration control should change with them. A CMP that applies the same rigour to a concept-screening model as to a certification baseline wastes effort; one that applies the same looseness to both creates evidence risk. The figure below shows the control posture across the lifecycle.

The lifecycle alignment has three practical consequences. First, the CI set grows as the model matures: a concept model may control only source files, while a certification baseline must control the toolchain manifest and the validation evidence itself. Second, gates convert informal work into controlled baselines; after a gate, any change to the frozen configuration is by definition Class 1 and must pass through the CCB. Third, the CMP must name the gate criteria so that "ready for validation" is a checkable state rather than a judgement call.

Writing the plan: content that earns its place

A CMP that runs to forty pages of boilerplate is usually ignored. The sections that carry real weight are:

CI identification scheme. A naming and versioning convention that encodes model, variant, and baseline, e.g. PLANT-HYDRO-v2.3.1-BL04, with the rule that a baseline tag is immutable once issued.
Baseline definition. What exactly constitutes a baseline — the manifest listing model files, parameter files, solver version, input decks, and post-processing scripts, with content hashes.
Change workflow. The states a change request passes through (raised → analysed → dispositioned → implemented → verified → closed), who moves it between states, and the maximum dwell time in each.
Classification thresholds. The numeric criteria separating Class 1, 2, and 3, as discussed above.
Status accounting and audit. The reports produced, their frequency, and the audit trail that lets an assessor reconstruct why a given result was produced by a given configuration.

A minimal but complete change record, suitable as a template, might look like this:

CR-2024-017
Title:        Update hydraulic actuator damping coefficient
Raised by:    J. Okafor (Model Owner)           Date: 2024-06-11
Affected CI:  PLANT-HYDRO-v2.3.1-BL04
Class:        1  (parameter change 4.8% > 2% tolerance band)
Rationale:    Bench test data (report TR-118) shows baseline damping
              over-predicts settling time by 11%.
Impact:       Affects transient response cases TC-04, TC-07, TC-12.
              Re-run regression suite; re-validate against TR-118.
Disposition:  Approved by CCB 2024-06-14. Evidence: impact analysis
              IA-017, regression log RL-221 (all cases pass).
Implemented:  Branch cfg/CR-2024-017, merged to baseline BL05.
Verified by:  V&V Lead, 2024-06-19.

Note what the record does not contain: free-text justification without a reference, or an approval without cited evidence. Those omissions are what make the record defensible.

Common planning failures and their symptoms

Three failure patterns recur. Role collapse — the same engineer proposes, implements, and approves — produces baselines that pass internal review but fail independent assessment, because no one has independently examined the validity impact. Threshold vagueness — "minor changes may be fast-tracked" — leads to inconsistent classification and, eventually, to an unreproducible result that nobody can trace to a decision. Lifecycle mismatch — applying certification-grade control to exploratory models — slows early work to the point that engineers work around the process, which is worse than having no process at all.

If engineers routinely keep uncontrolled copies of model files "just to try something", the CMP has already failed regardless of what it says. The plan must provide a sanctioned sandbox — an explicitly uncontrolled working area whose outputs cannot enter a baseline without passing through the change workflow — or the informal workaround will win.

The test of a completed CMP is simple: hand it to a new team member and ask them to determine, for a specific result, which configuration produced it, who approved that configuration, and what evidence supported the approval. If the plan lets them answer all three without asking anyone, the planning has done its job.