Ask most teams how machine learning works in a self-driving car and you will hear about the model: the architecture, the training set, the accuracy number on the road. That is the interesting engineering problem, but it is not the whole deliverable. In a regulated automotive program, a trained perception or planning model is a supplier of compliance evidence — and the evidence it produces has to stay auditable back to the data that shaped it. The moment that link breaks, the model becomes a liability an OEM safety reviewer cannot sign off. The common assumption is that the work ends at accuracy. Ship the weights, log the metrics, move on. That framing treats a model as a self-contained artifact. It is not. It is one document in a digital supply chain of compliance evidence, and it carries the same obligation as any supplier certificate: every claim in the final record must trace back to a verifiable source input. A model whose evidence flattens into a single “final” report hides the change history a reviewer will demand. One that preserves source-to-artifact traceability lets that chain be audited end to end. How does machine learning in self-driving cars actually work? At the level that matters here, a self-driving stack is a chain of learned functions. Cameras, radar, and lidar feed raw signals into a perception subsystem that detects and classifies objects, estimates their positions, and often produces a bird’s-eye-view scene representation. A prediction subsystem takes those tracked objects and forecasts where they are likely to go. A planning subsystem consumes both to choose a trajectory the vehicle can execute safely. Each stage is typically a deep neural network — convolutional or transformer-based detectors for perception, sequence models for prediction, and increasingly learned or hybrid planners at the end. The models are trained the way most production computer-vision systems are: large labelled datasets, a loss function chosen to match the task, iterative training in PyTorch or TensorFlow, then optimization for the target compute with TensorRT or ONNX Runtime. None of that is unusual. What is unusual — and what teams underestimate — is that in automotive, the training run is not just a step toward a deliverable. It is an event that must be recorded, because the deployed model’s behaviour will one day have to be explained by reference to it. We see this framing gap constantly. Engineers optimize the model and treat provenance as paperwork to be assembled at the end. By then the data lineage is partial, the calibration records live in someone’s notebook, and the validation runs cannot be tied back to a specific dataset revision. The model works; the evidence does not. What does each ML subsystem output, and why does the output shape the evidence? The three subsystems produce different artifacts, and each artifact has a different provenance obligation. Naming them precisely is the first step toward a defensible safety case. Subsystem Primary output Evidence a reviewer expects Perception Object detections, class labels, positions, BEV scene grid Training-data provenance, label-source records, calibration parameters used at inference, validation metrics per operational domain Prediction Trajectory forecasts and probabilities per tracked object Scenario coverage of training data, provenance of the perception inputs it was trained against, validation on rare-event sets Planning Selected trajectory / control targets Provenance of the prediction and map inputs, validation of the decision policy against a documented safety envelope The point of the table is not the outputs themselves — those are well understood. It is that provenance flows downstream. A planning model’s evidence is only as trustworthy as the perception evidence feeding it, which is only as trustworthy as the calibration and label provenance behind that. A gap anywhere upstream propagates. This is why we treat the whole chain as one traceable supply chain rather than three independent deliverables. For a deeper walk through the perception layer specifically, our companion piece on how the perception stack actually works in self-driving cars covers the detector and tracking mechanics in detail. How do you preserve source-to-artifact traceability from data to deployed model? Source-to-artifact traceability means that for any deployed model, you can reconstruct the chain: which dataset revision trained it, which labels came from which source, which calibration records were in force, which validation runs certified it, and which of those runs used which data. Every link is verifiable — a reviewer can follow it without taking your word for anything. Concretely, that requires four things to be version-controlled and cross-referenced, not just present: Training-data provenance. Every dataset revision has an identity, and every sample’s origin (fleet collection, simulation, third-party set such as an automotive-adapted OpenImages subset) is recorded. A model artifact points at the exact revision it consumed. Label lineage. Human-labelled, auto-labelled, and corrected labels are distinguishable, because a reviewer auditing a false-negative will ask where the label came from. Calibration records. Camera intrinsics and extrinsics used during both training and inference are pinned to the model, since a perception model’s outputs are meaningless without the calibration that produced its inputs. Our note on why camera intrinsic parameters demand traceability explains this dependency. Validation-run binding. Each validation run references the model artifact and the data revision it ran against, so a metric can never float free of the thing it measured. The versioning discipline underneath this is not exotic; it is model versioning done with the audit in mind rather than the release in mind. We cover the practical mechanics in machine learning model versioning for automotive perception. The difference between a version tag that helps you roll back and one that survives an audit is whether it links outward to data, labels, and calibration — not just inward to a checkpoint. Where does an ML model artifact fit in an automotive digital supply chain? Here is the reframe that changes how the work is scoped. An OEM already runs a digital supply chain of compliance evidence for physical parts: a bracket arrives with material certificates, a supplier declaration, and a traceable link back to the batch it came from. Nobody accepts the part on the strength of a single summary sheet — the chain is the point. A trained model is a supplier document in exactly that sense. It is delivered into the OEM’s compliance record, and it must arrive with the same trace: this model, from this data, validated by these runs, calibrated this way. Treating ML as a special case that gets to summarize its own history is what produces the flattened “final report” a reviewer distrusts. Treating it as one more supplier of evidence — held to the traceability standard every other supplier meets — is what shortens the review. That is also why the tooling overlaps. The same validation harness that audits supplier document traceability can audit a model artifact for source-to-artifact provenance across the perception pipeline. It is checking the same property: does every claim link back to a verifiable input? The production AI monitoring harness we build for automotive programs applies that check to model deliverables the way document-intelligence tooling applies it to supplier paperwork. Which provenance gaps does an OEM safety reviewer surface? When we sit in on audits — or reconstruct them after a finding — the gaps cluster into a recognizable set. This is an observed pattern across regulated engagements, not a benchmarked failure rate, but it is consistent enough to plan around: Orphaned validation metrics. A strong accuracy number with no binding to the data revision it was measured on. The reviewer cannot tell what it proves. (Our piece on what each model performance metric actually proves is the reference for why an unbound metric is close to worthless.) Missing label lineage. A false negative in a critical class with no way to trace whether the failure originated in labelling, sampling, or the model. Calibration drift with no record. Inference-time calibration that differs from training-time calibration, undocumented. Retraining that overwrites history. A model updated in place, with the previous artifact’s evidence discarded rather than superseded. The last one is the most expensive, because it turns a routine update into a re-audit of the entire subsystem. How does ML evidence stay audit-ready across the vehicle lifecycle? Models get retrained. New data arrives, edge cases surface, the fleet grows. The naive instinct is to treat each retrain as a fresh start — new weights, new metrics, done. In a traceable supply chain, a retrain is a new artifact that supersedes the old one, with its own complete trace and an explicit link to what it replaced. The previous evidence is retained, not overwritten. That is what lets a reviewer see the change history rather than a single opaque “current” state. Monitoring closes the loop. A deployed model whose live behaviour is tracked against its validation baseline produces continuous evidence that the deployed artifact still matches the one that was certified. When it drifts, the record shows when and how — which is the difference between a controlled update and a silent one. We cover this in machine learning monitoring for provenance-preserving compliance, which is the operational counterpart to everything above. Where does scoped AI automation help, and where should it stay out of the record? Assembling an evidence pack is tedious, and it is tempting to hand the whole thing to an automation layer. There is a real line here. Automation is genuinely useful for gathering and cross-referencing provenance — pulling the data revisions, labels, calibration records, and validation runs into an audit-ready pack, and flagging where a link is missing. That is mechanical work that scoped tooling does faster and more consistently than a human under deadline. Where automation must stay out is authoring the safety judgment. An automated layer that silently rewrites or summarizes the record — deciding on its own what to include and what to drop — reintroduces exactly the flattening problem this whole discipline exists to prevent. ML here is a supplier of compliance evidence, not a layer that silently edits the record. The automation assembles; it does not decide what the evidence means. FAQ How does machine learning in self driving cars work in practice? A self-driving stack is a chain of learned functions: perception detects and localizes objects, prediction forecasts their motion, and planning chooses a trajectory. In practice the models are trained and optimized much like other production computer-vision systems, but in a regulated program the training run is a recorded event whose outputs must trace back to their source inputs — the model is a supplier of compliance evidence, not a self-contained deliverable. What are the main ML subsystems in a self-driving car — perception, prediction, planning — and what does each one output? Perception outputs object detections, class labels, positions, and often a bird’s-eye-view scene grid. Prediction outputs trajectory forecasts and probabilities for tracked objects. Planning outputs the selected trajectory or control targets. Provenance flows downstream, so each subsystem’s evidence is only as trustworthy as the evidence feeding it from upstream. How do you preserve source-to-artifact traceability from training data through validation runs to a deployed model? You version-control and cross-reference four things with the audit in mind: training-data provenance (the exact dataset revision), label lineage (where each label came from), calibration records (intrinsics and extrinsics pinned to the model), and validation-run binding (each run referencing both the model artifact and the data it ran against). Every link must be verifiable so a reviewer can follow it without taking your word for anything. Where does an ML model artifact fit inside an automotive digital supply chain of compliance evidence? It fits exactly where a supplier certificate fits for a physical part: delivered into the OEM’s compliance record with a traceable link back to its source. Just as a bracket arrives with material certificates and batch traceability rather than a single summary sheet, a model must arrive as this-model-from-this-data-validated-by-these-runs — held to the same traceability standard as any other supplier of evidence. Which provenance gaps does an OEM safety reviewer surface when auditing a self-driving ML subsystem? The recurring gaps are orphaned validation metrics with no binding to the data revision measured, missing label lineage that blocks tracing a critical false negative, undocumented calibration drift between training and inference, and retraining that overwrites history instead of superseding it. The last is the most costly because it converts a routine update into a re-audit of the whole subsystem. How does ML evidence stay audit-ready as models are retrained and updated across the vehicle lifecycle? A retrain is treated as a new artifact that supersedes the old one, carrying its own complete trace and an explicit link to what it replaced, so previous evidence is retained rather than overwritten. Monitoring then tracks the deployed model’s live behaviour against its validation baseline, producing continuous evidence that the certified artifact still matches what is running — and a dated record when it drifts. Where does scoped AI automation help assemble model evidence, and where should it stay out of the safety record? Automation helps with gathering and cross-referencing provenance — pulling data revisions, labels, calibration records, and validation runs into an audit-ready pack and flagging missing links. It should stay out of authoring the safety judgment: a layer that silently rewrites or summarizes the record reintroduces the flattening problem the discipline exists to prevent. The automation assembles; it does not decide what the evidence means. The question worth carrying into the next audit The interesting engineering problem in a self-driving car will always be the model. But the deliverable an OEM actually accepts is the chain — the verifiable path from source data to the validated artifact running in the vehicle. So the useful question is not “how accurate is the model?” It is “if a reviewer picks any claim in this model’s evidence, can we walk them back to its source without a gap?” A perception subsystem that answers yes shortens the review cycle and survives the finding; one that answers with a single flattened report is where the remediation cost lives. That property — source-to-artifact traceability across the perception pipeline — is exactly what a validation pack is built to prove.
