Model Cards are the QA contract for every AI model in the AV stack. They define what the model is, how it behaves, where it fails, and how it must be tested, monitored, and governed. For the following examples, we will look at what the model cards do in a QA strategy for Autonomous vehicles
Model Cards in an AI & Autonomous Vehicle QA Strategy
Model Cards act as the single source of truth for how an AI model behaves, what it was trained on, what risks it carries, and how it should be validated. In an autonomous‑vehicle environment, they become a compliance, safety, and QA artifact that ties engineering, testing, and regulatory oversight together.
Below is a structured breakdown tailored to AV systems.
1. Define the Model’s Purpose and Operational Boundaries
Model Cards document:
• What the model is designed to do (e.g., lane detection, pedestrian intent prediction, sensor fusion).
• The operational design domain (ODD) it supports.
• Environmental constraints (lighting, weather, road types).
• Known limitations.
Why QA cares:
This becomes the baseline for test coverage, scenario generation, and risk‑based validation.
2. Capture Training Data Characteristics
They describe:
• Data sources (camera, lidar, radar, simulation).
• Geographic diversity.
• Edge-case representation.
• Synthetic vs. real-world ratios.
• Annotation quality and known biases.
Why QA cares:
This drives data sufficiency analysis, bias detection, and coverage gaps that must be tested or mitigated.
3. Document Performance Metrics Across Conditions
Model Cards include:
• Accuracy, precision, recall, F1.
• Latency and throughput.
• Performance under degraded conditions (rain, glare, occlusion).
• Failure modes and false-positive/false-negative patterns.
Why QA cares:
QA uses this to build acceptance criteria, regression thresholds, and safety KPIs.
4. Risk, Bias, and Safety Disclosures
Model Cards explicitly call out:
• Known failure scenarios.
• Populations or objects the model struggles with.
• Environmental conditions that degrade performance.
• Safety-critical misclassification risks.
Why QA cares:
This feeds directly into hazard analysis, FMEA, SOTIF (ISO 21448), and safety case documentation.
5. Explainability and Interpretability Notes
They outline:
• What explainability tools apply (SHAP, saliency maps, counterfactuals).
• How to interpret model decisions.
• What cannot be explained.
Why QA cares:
This informs debugging workflows, incident investigation, and regulatory transparency.
6. Versioning, Change Logs, and Lifecycle Controls
Model Cards track:
• Model version history.
• Training pipeline changes.
• Hyperparameter adjustments.
• Dataset updates.
• Deployment history.
Why QA cares:
This is essential for traceability, regression testing, and audit readiness.
7. Deployment Constraints and Integration Requirements
They specify:
• Required compute resources.
• Expected sensor inputs.
• Latency budgets.
• Safety monitors or fallback logic.
Why QA cares:
QA uses this to validate system integration, real-time performance, and fail-safe behavior.
8. Compliance and Regulatory Alignment
Model Cards support:
• ISO 26262 (functional safety)
• ISO 21448 (SOTIF)
• UL 4600 (autonomous safety)
• NHTSA ADS safety reporting
Why QA cares:
They become part of the safety case and regulatory submission package.