2. MLOps foundations for crash analytics

Crash analytics is not a single model but a continuously operating decision system. It ingests collision telemetry, vehicle sensor streams, and scene annotations; it produces severity classifications, injury-risk scores, and design-selection recommendations that feed back into vehicle safety engineering. Because these outputs influence real design decisions, the supporting MLOps foundation must guarantee that every prediction can be traced to a specific dataset version, a specific model artifact, and a specific configuration. This section establishes the lifecycle stages, the reproducibility mechanisms, and the governance requirements that make crash analytics trustworthy at scale.

Lifecycle Stages Specific to Crash Analytics

A generic MLOps lifecycle (data → train → deploy → monitor) is too coarse for crash analytics. The domain introduces stages that generic pipelines do not model: crash-scene curation, sensor synchronization, label harmonization across investigation sources, and regulatory validation. A practical lifecycle for this domain has six stages:

• Scene ingestion and curation. Raw event data recorders (EDR), accelerometer traces, camera frames, and crash-test dummies' sensor channels arrive at different rates and clocks. Ingestion must align them to a common time base and reject incomplete events.
• Label harmonization. Injury severity labels may come from police reports (KABCO scale), hospital records (AIS), or reconstructed simulations. These scales are not interchangeable; harmonization maps them to a canonical target such as MAIS or a binned severity class, and records the mapping version.
• Feature and dataset versioning. Derived features (delta-v, principal direction of force, occupant compartment intrusion) are computed by versioned transformation code, not ad-hoc notebooks.
• Training and evaluation. Model selection uses stratified splits by crash type and severity to avoid optimistic bias from over-represented frontal collisions.
• Release and deployment. Models are packaged with their preprocessing graph and served behind a versioned endpoint.
• Monitoring and feedback. Production predictions are compared against post-hoc investigation outcomes, and drift in sensor distributions or label mix triggers retraining.

The critical insight is that stages 1–3 consume more engineering effort than training. In crash analytics, a model is only as reproducible as the label harmonization and sensor alignment that precede it.

Reproducibility: Three Layers That Must Be Pinned

Reproducibility means that re-running a pipeline at a later date yields the same artifact hash, or at minimum the same evaluation metrics within a stated tolerance. Three layers must be pinned independently:

Data layer. Datasets are content-addressed. A dataset version is identified by a manifest hash over file checksums, not by a mutable path like s3://crash-data/latest/. Splits are stored as explicit index files so that a retrain cannot silently reshuffle which crashes are in the test set.

Code and environment layer. Transformation code, training code, and the container image are versioned together. The image digest, not a tag like :latest, is recorded. Random seeds for split generation, weight initialization, and augmentation are captured in the run manifest.

Configuration layer. Hyperparameters, feature flags, and label-mapping versions are externalized into a config file that is hashed and stored alongside the model artifact.

A minimal run manifest that satisfies all three layers looks like this:

run_id: crash-sev-2024-11-07-a3f9
dataset_manifest: sha256:9c1e...  # content hash of curated events
split_index: sha256:4b77...       # explicit train/val/test membership
label_map_version: kabco-to-mais-v3
code_commit: 7d2a1c0
image_digest: sha256:be31...
config_hash: sha256:0f8d...
seed: 1337
metrics:
  test_mais_mae: 0.41
  test_severity_f1_macro: 0.78

With this manifest, an auditor can reconstruct the exact experiment. Without the split index, for example, a retrain may appear to improve F1 simply because different crashes landed in the test set — a failure mode that is common and hard to detect after the fact.

Model Governance Requirements

Governance answers who approved a model, what it is allowed to do, and how it is retired. For crash analytics, three governance controls are non-negotiable:

Model cards with domain-specific fields. Beyond standard fields (intended use, training data, metrics), crash model cards must state the crash types and severity ranges covered, known blind spots (e.g., under-representation of side impacts for certain vehicle classes), and the label scale used. A model trained on KABCO-derived labels must not be presented as predicting AIS without an explicit mapping caveat.

Approval gates tied to evaluation thresholds. Promotion from staging to production requires passing gates on a held-out, temporally separated test set — for example, crashes from a later model year than training data. A representative gate configuration:

Lineage and retirement. Every production prediction must be attributable to a model version and its manifest. When a model is retired, its endpoint is frozen, its manifest archived, and downstream consumers notified with a deprecation window. This matters because design-selection decisions may reference model outputs months after they were produced.

How the Pieces Connect

The diagram below shows the lifecycle as a governed loop: curated and versioned data flows into reproducible training, gated release, monitored serving, and feedback that re-enters curation. The governance layer spans every stage rather than sitting at the end.

Practical Failure Modes and Their Symptoms

Reproducibility and governance failures rarely announce themselves. Three recurring symptoms are worth recognizing:

• Metric drift on identical code. A retrain with the same commit produces different F1. The usual cause is an unpinned split or a mutable dataset path. Check the run manifest for a split index hash; if it is absent, the split was regenerated.
• Optimistic holdout performance. Test F1 is high but production feedback is poor. This typically indicates temporal leakage — crashes from the same period appear in both train and test. Fix by splitting on event date, not randomly.
• Silent label-scale mismatch. Severity predictions look plausible but are systematically shifted. Verify that the label map version in the manifest matches the one used at training time; a KABCO-to-MAIS mapping change between runs will shift the target distribution.

The foundation described here — six domain-specific lifecycle stages, three pinned reproducibility layers, and governance controls that span every stage — is what allows later chapters on model selection and design trade-offs to rest on evidence rather than assertion. When a design team asks why a particular safety recommendation was made, the answer should be a manifest, a model card, and a gate record, not a recollection.