A perception validation package goes back for a second review round more often because of a signature problem than an evidence problem. The coverage data is there. The hazard analysis is there. But one name sits at the bottom of every section — the perception lead’s — and the OEM reviewer stops on the hazard-linkage page to ask the question that stalls everything: “who actually attests to this mapping between detected failure modes and the vehicle-level hazards?” The perception lead can describe the linkage. They cannot sign for it. So the package waits. This is the failure mode worth naming up front. When a validation package mirrors the team’s internal test-tracking layout, it tends to become a single document that one author assembles and vouches for. That structure works inside the team, where everyone trusts the perception lead’s judgment across the whole thing. It breaks the moment the package crosses an accountability boundary — into QA review, into a safety case, into an OEM customer’s acceptance gate — because each of those reviewers needs to know not just that the evidence exists, but who is on the hook for it. What Does an Automotive Perception Validation Package Contain and Who Signs Each Part? The reframe is to stop treating the package as a document and start treating it as a set of sections, each defined by the question it answers and the reviewer role accountable for signing it. The contents don’t change much; the ownership map is what’s been missing. Section Question it answers Signing role What must be behind it before that role can sign Coverage & test evidence Did we exercise the model against the scenarios that matter, and what did it score? QA / validation engineer Scenario catalogue traced to requirements; pass/fail thresholds fixed before the run; results from the deployed model artifact, not a research checkpoint Hazard linkage Which perception failure modes map to which vehicle-level hazards, and are they all addressed? Safety lead / functional-safety engineer A failure-mode analysis (FMEA-style) tied to the system hazard analysis; each residual hazard either mitigated or accepted with rationale Operational design domain (ODD) statement Where is this perception function valid, and how do we detect leaving that envelope? Systems / perception architect An explicit ODD boundary and the runtime checks that flag out-of-domain conditions Data provenance & dataset evidence Where did training and test data come from, and is the test set independent? Data lead / ML engineer Dataset lineage, train/test isolation evidence, labelling-quality records Known limitations & residual risk What does this model still get wrong, and is that acceptable for release? Safety lead (co-signed by perception lead) A candid limitations register, not a marketing summary Release acceptance Does this package meet the acceptance criteria we agreed? OEM customer / release authority Everything above, plus the agreed acceptance criteria stated in the customer’s own terms The point of the table is the right-hand columns, not the left. Most teams already know roughly what sections a package needs. What they skip is the discipline of asking, for each section, whose signature makes this credible — and what has to be true before that person can put their name to it. Which Reviewer Role Is Accountable for Coverage Versus Hazard Linkage? These two sections get conflated more than any other, and the conflation is exactly what stalls review. Coverage evidence answers an empirical question: did the model meet its measured targets across the scenario set? That is the QA engineer’s domain. They attest that the test ran against the right scenarios, that the thresholds were set in advance, and that the numbers are the numbers. Hazard linkage answers a different kind of question entirely. It asks whether the failure modes the model can exhibit have been mapped to the hazards they could cause at the vehicle level, and whether each of those is mitigated or formally accepted. That is a safety-engineering judgment, and the safety lead owns it. A QA engineer can confirm a detection-rate figure; they are not the right person to attest that a 0.3% miss rate on pedestrians at dusk is or isn’t an acceptable residual hazard. That sentence requires the safety lead’s authority. When one author signs both sections, you’ve created a single point of accountability that no individual genuinely holds. The reviewer senses this, and the package returns. Separating the two doesn’t add bureaucracy — it routes each claim to the person who can actually defend it. We see this pattern hold across regulated-deployment reviews generally: the verification and validation work for production AI only becomes review-ready when the empirical evidence and the safety judgment are attributed separately. Why a Per-Section Signatory Compresses Sign-Off The economic argument is about review rounds, not document length. An undifferentiated package forces sequential review: the reviewer reads the whole thing, hits a section outside the author’s authority, and sends it back with a question that the author can’t resolve without pulling in someone else. That triggers a second round. Then a third, when the next ownership gap surfaces. A section-and-owner structure means each part arrives pre-routed to the role that can sign it. The coverage section goes to QA, the hazard section to the safety lead, the acceptance section to the OEM reviewer — and those reviews can proceed in parallel rather than bottlenecking on a single author. In practice this tends to collapse multiple back-and-forth rounds into a single review round (an observed pattern across our automotive validation engagements, not a benchmarked cycle-time figure). It also removes the specific rework loop where a package returns purely because an unauthorized author signed a section — a pure-overhead round that produces no new evidence. The same logic underwrites the broader production AI reliability discipline: reliability evidence is only worth what the named accountability behind it is worth. An unsigned or wrongly-signed claim is a liability, not an asset, no matter how good the underlying data is. And because the validation rests on measured behaviour rather than asserted behaviour, the coverage numbers carry weight only when they come from runs against real operating conditions — the same reasoning that makes benchmark results usable as procurement evidence applies here: a figure is decision-grade when its measurement conditions are documented and the result is reproducible. How Do Section Owners Stay Stable When the Model Is Updated? This is where the section-and-owner map earns its keep over the long run. A perception model is not validated once. It gets retrained, the dataset grows, a regression surfaces, and the evidence has to be refreshed. If accountability were renegotiated every time — who signs the coverage section for v2.3? — each model update would reopen an organizational question that has nothing to do with the model. The fix is to treat the ownership map as invariant across model versions. The QA role re-signs the refreshed coverage evidence; the safety lead re-signs the updated hazard linkage; the OEM reviewer re-attests acceptance against the same criteria. What changes between versions is the evidence inside each section, not who is accountable for it. This is the difference between a package structure and a package instance: the structure persists, the instances are versioned against it. That stability is also what lets a regression suite hook in cleanly. When regression testing catches model drift before release, the test output flows straight into the coverage section, which already has a standing owner ready to re-sign — no new accountability conversation required. How Does the Map Change Between an Internal QA Reviewer and an OEM Customer Reviewer? The internal QA reviewer and the OEM customer reviewer are answering different questions, and the package has to serve both without being rebuilt. The internal QA reviewer is checking that the evidence is sound on its own terms: are the thresholds defensible, is the test set independent, does the hazard analysis cover the known failure modes. Their sign-off is an engineering attestation — the evidence is correct and complete relative to the discipline. The OEM customer reviewer is checking something narrower and contractual: does this package meet the acceptance criteria we agreed, in our terms. They are not re-deriving the engineering; they are confirming the deliverable matches the contract. Their sign-off is a release acceptance, and it sits on top of — never replaces — the internal engineering sign-offs. The cleanest packages make this layering explicit: the coverage, hazard, and ODD sections carry internal signatures, and the acceptance section carries the OEM signature that references them. When an OEM governance review is in scope, those per-section signing roles map directly onto governance-grade attestation requirements for audit and regulated review. And the vertical-side detail of how this plays out in a named automotive engagement is worked through in our guide to building a perception validation evidence package reviewers trust. FAQ What does an automotive perception validation package contain and who signs each part? It contains coverage and test evidence, hazard linkage, an operational design domain statement, data provenance, a known-limitations register, and a release-acceptance section. Each section is defined by the question it answers and routes to a specific signing role — QA owns coverage, the safety lead owns hazard linkage, and the OEM customer owns release acceptance — rather than one author signing the whole package. Which reviewer role is accountable for the coverage/test-evidence section versus the hazard-linkage section? The QA or validation engineer signs coverage and test evidence, attesting that the model was exercised against the right scenarios with thresholds fixed in advance. The safety lead signs hazard linkage, attesting that perception failure modes are mapped to vehicle-level hazards and each is mitigated or formally accepted. These are different kinds of judgment — empirical versus safety — and conflating them under one signature is what stalls review. Why does assigning a signatory per section compress sign-off compared with a single-author package? A single-author package triggers sequential review rounds: the reviewer hits a section outside the author’s authority, sends it back, and the author can’t resolve it alone. A per-section map lets reviews proceed in parallel because each part arrives pre-routed to the role that can sign it, collapsing multiple back-and-forth rounds into a single round and removing the rework loop caused by an unauthorized signature. How do the section owners stay stable when the perception model is updated and evidence is refreshed? The ownership map is treated as invariant across model versions. When the model is retrained and evidence refreshed, the same roles re-sign their respective sections — QA re-signs coverage, the safety lead re-signs hazard linkage — so what changes is the evidence inside each section, not who is accountable for it. This keeps every model update from reopening an organizational accountability question. What does each section need behind it before its named role can credibly sign? Coverage needs a scenario catalogue traced to requirements, thresholds set before the run, and results from the deployed artifact. Hazard linkage needs a failure-mode analysis tied to the system hazard analysis with each residual hazard addressed. Provenance needs dataset lineage and train/test isolation; acceptance needs the agreed criteria in the customer’s terms. Without the backing, the signature isn’t credible even if the role is correct. How does the per-section signatory map change between an internal QA reviewer and an OEM customer reviewer? The internal QA reviewer gives an engineering attestation that the evidence is sound on its own terms. The OEM customer reviewer gives a release acceptance confirming the package meets the agreed contractual criteria, which sits on top of the internal sign-offs rather than replacing them. The structure stays the same; the acceptance section simply references the internal signatures it rests on. Where does the package’s internal sign-off end and a regulatory safety-case attestation begin? Internal sign-off ends at the engineering and acceptance signatures within the package — coverage, hazard linkage, ODD, and release acceptance. A regulatory safety-case attestation is a separate, higher-order claim made to an external authority, and it consumes the package as evidence rather than being a section of it. When that boundary is in scope, the per-section signing roles map onto governance-grade attestation requirements, but the safety case itself lives outside the package. The cleanest test of whether a validation package is review-ready is to read it section by section and ask, at the bottom of each, whether the right person could sign that page today — and whether they’d have the evidence to defend the signature if the OEM reviewer pushed back. A package that can’t pass that test isn’t short on data. It’s short on a section-and-signatory map, which is the artifact the validation engagement should hand the reviewer before the first page is ever written.
