4. Model governance framework

Crash simulation quality does not fail because LS-DYNA is unstable or because a mesh is too coarse. It fails because nobody agreed, in advance, who owns the model, who is allowed to change it, and who has the authority to declare it fit for a given decision. A governance framework exists to make those answers explicit, so that a CAE result carries a known and defensible level of credibility when it reaches a program milestone.

The framework rests on four interlocking elements: roles (who performs the work), responsibilities (what each role is accountable for), policies (the rules that constrain how work is done), and decision rights (who may approve, reject, or escalate). These must be defined across three organizational communities — CAE, Test, and Program — because crash simulation credibility is a shared product, not a CAE deliverable.

Roles and Their Boundaries

A practical role model for crash CAE governance typically includes the following positions. Note that one person may hold several roles in a small team, but the accountabilities must remain separable.

The critical separation is between the person who produces a result and the person who approves it. A simulation engineer may run a frontal ODB case, but the Model Owner signs the model release, and the Program Chief Engineer owns the design decision that the result supports. Collapsing these into one person removes the check that governance is meant to provide.

Responsibilities as Concrete Deliverables

Responsibilities should be written as artifacts, not intentions. "The Model Owner is responsible for model quality" is unenforceable. "The Model Owner maintains the model release note containing solver version, deck hash, mass, and open issues" is auditable. A workable responsibility set for a crash CAE group includes:

• Maintaining a single authoritative baseline deck per vehicle program, with a documented change history.
• Recording solver version, precision (single/double), and termination status for every released run.
• Producing a correlation report for each test-CAE pair, including channel-level metrics and known discrepancies.
• Flagging any model change that alters mass by more than an agreed threshold (for example, 0.5%) or changes a primary structural load path.
• Escalating unresolved correlation gaps above a defined tolerance to the CAE Manager before the result is used for a program decision.

Policies That Constrain the Work

Policies are the standing rules that prevent ad hoc decisions from eroding credibility. Three policy families matter most in crash simulation governance.

Model change control. Any modification to the baseline deck must be traceable. A minimal policy: changes are committed with a unique ID, a description, the reason, and the affected subsystems; the Model Owner reviews and merges; the release note is regenerated. Untracked local edits are prohibited for any run that will inform a program decision.

Correlation acceptance. Define, before correlation begins, which channels are primary (for example, B-pillar acceleration, intrusion, occupant injury criteria) and what tolerance is acceptable. A common approach uses a combination of peak value error, time-of-peak shift, and a curve-matching metric. The policy states that a result may be used for a program decision only if primary channels are within tolerance or the deviation is explicitly documented and accepted.

Data provenance. Test data used for correlation must carry metadata: test ID, date, vehicle build level, sensor calibration status, and filtering applied. CAE results must carry the deck hash and solver version. Without this, a correlation claim cannot be reproduced or defended.

Decision Rights Across CAE, Test, and Program

Decision rights answer the question "who decides?" for each class of decision. The most useful structure is a RACI-style matrix, but the essential content is the boundary between recommendation and authority.

The Program Chief Engineer holds the final decision right for design freeze and residual risk, because those are program-level commitments. CAE and Test provide evidence and recommendations; they do not unilaterally commit the program. Conversely, the Program team does not override a correlation rejection — it can accept residual risk, but the technical rejection stands on record.

Making the Framework Operable

A governance framework that lives only in a document will be ignored under schedule pressure. Three mechanisms make it operational. First, embed the gates in the existing CAE workflow: a run cannot be promoted to "release" status in the simulation data management system without a model release note and a correlation status field. Second, hold a short weekly correlation review where open discrepancies are triaged and assigned. Third, maintain a decision log that records each program-level decision, the CAE evidence cited, and the residual risk accepted — this becomes the audit trail when a later issue is traced back.

The following diagram shows how a simulation result flows through the governance gates and where each role exercises authority.

The framework is not a bureaucratic overlay; it is the mechanism that lets a CAE result be trusted at a program milestone. When roles are clear, responsibilities are artifacts, policies are enforced at the tool level, and decision rights are explicit, a simulation result arrives with its credibility already established — and the program can act on it without re-litigating the model.