A perception validation package answers a release reviewer’s questions about one model release. An OEM governance review asks a different set, and the difference is not depth — it is whether the evidence can be read without the perception team in the room.
That single test decides how the next few weeks go. Ship the validation package unchanged into a governance review and it will come back with requests for provenance, ownership records and change-control scope: material the package was never built to carry. The technical sections were fine. The wrapper was missing.
What “governance-grade evidence” means in an OEM trust pack
A governance reviewer at an OEM is not re-checking your detection metrics. They are establishing four things: where the data and the model came from, who is accountable for each claim, how a change to the system is controlled after start of production, and whether an auditor with no access to your engineers could reconstruct the same conclusions from the artefacts alone.
Governance-grade evidence is evidence that survives the absence of its authors. If a claim in the pack only resolves because a perception engineer can explain it in a meeting, it is a test report with a cover sheet, not governance-grade evidence.
The good news is that the validation package’s reviewer-shaped structure is the right foundation. We keep it intact — sections defined by the question each answers, with named owners — and wrap a governance layer around it rather than rewriting from scratch. The structural discipline that makes a package readable at release review is the same discipline that makes it auditable at governance review, which is why teams who invested in reviewable validation structure find the escalation cheap and teams who exported a test backlog find it expensive.
Which sections carry forward, and which need a governance rewrite
| Package section | Status in the trust pack | What changes |
|---|---|---|
| Operational design domain / scope of claim | Reused unchanged | Nothing — the scope statement is already the boundary a governance reviewer needs |
| Metric definitions and acceptance thresholds | Reused unchanged | Nothing, provided the rationale for each threshold is stated |
| Per-scenario coverage results | Reused, re-anchored | Each result must resolve to a versioned dataset manifest, not a run ID in an internal tracker |
| Failure-mode log and disposition | Reused, re-attributed | Each disposition needs a named accountable role, not the engineer who closed the ticket |
| Dataset and model provenance | New layer | Data origin, consent/licensing basis, version hashes, training-to-release lineage |
| Decision records | New layer | Versioned records of why thresholds, exclusions and residual-risk acceptances were set as they were |
| Ownership matrix | New layer | Who signs each section, and what authority that signature carries |
| Change-control path | New layer | What class of model change triggers what re-validation scope |
| Residual-risk statement | Reused, re-signed | Same content; countersignature moves up to the accountable owner, not the author |
Four sections carry through untouched. Four are additions. One changes signatory. That ratio is the practical answer to whether this is a rewrite — it is not, if the underlying package was built around reviewer questions in the first place.
Where supplier sign-off ends and OEM sign-off begins
This boundary is worth fixing in writing before the first submission, because ambiguity here produces the review rounds the whole exercise is meant to avoid.
The supplier signs to what was measured and what it means: the scope of claim, the evidence behind each metric, the failure modes searched for, and the limits the supplier will stand behind. The OEM governance function signs to acceptance in their system context: whether the claimed operational domain matches the vehicle programme, whether the residual risk is acceptable at system level, and whether the change-control path is compatible with their own configuration management.
Neither party can sign the other’s half. A supplier that offers a system-level safety argument is claiming authority it does not hold; the boundary between component evidence and the regulatory safety case is a separate question, and one we treat as a hard line rather than a grey zone.
Keeping the governance layer stable after start of production
The most expensive failure we see is not a rejected first submission. It is a team that assembles a governance layer once, then rebuilds it at the next model refresh because nothing defined what a refresh actually invalidates.
Change-control scope is the fix, and it is written before the refresh, not after. A workable classification looks like this:
- Re-training on the same data campaign, same architecture — evidence slots for metrics and per-scenario coverage re-populate; provenance, ownership and decision records stand.
- New data campaign or new sensor configuration — dataset provenance re-issues, coverage re-runs, ODD statement is re-checked against the new distribution.
- Architecture or backbone change — failure-mode analysis re-opens; threshold rationale decision records are re-examined, not merely re-signed.
- Change to the claimed operational design domain — the scope statement changes, which means the OEM’s acceptance decision is a new decision.
With that table agreed up front, a post-SOP perception model update triggers a bounded re-validation set instead of a full package rebuild. The measurable payoff shows up in two places: the number of governance review rounds before sign-off — one round rather than three or four — and the elapsed time from evidence submission to supplier approval. Both are observed patterns across the automotive perception engagements we have run, not published benchmark figures, and both depend on the OEM’s own governance maturity as much as on the supplier’s.
How do you test whether the evidence reads without you?
A practical audit: hand the pack to a colleague with relevant engineering literacy but no involvement in the programme, and ask them to answer five questions using only the documents.
- What exactly is being claimed, and under what conditions does the claim stop holding?
- Which dataset version produced each headline number, and can that version be retrieved?
- Who is accountable if the claim turns out to be wrong?
- What happened to every known failure mode — accepted, mitigated, or open?
- If the model is updated next quarter, what has to be redone?
Every question they cannot close from the artefacts is a question the OEM governance reviewer will ask, at a cost of one review round each. Running this internally is far cheaper than discovering the gaps in the reviewer’s own timeline. In our experience the questions that fail this test cluster on provenance and ownership — the technical evidence is usually present, just unattributable.
Where the trust pack still stops
An OEM trust pack is supplier-side evidence that has been made independently readable. It is not a regulatory safety case. It carries no system-level hazard argument, no assurance-case structure, and no claim about the vehicle as a whole — those belong to the OEM’s safety organisation and follow a different standard. Confusing the two invites a supplier to author argumentation it has no authority to make.
The governance layer is also not a substitute for the underlying validation work. Provenance records around weak coverage evidence produce an auditable account of a weak claim. The layer makes evidence readable; it does not make it stronger.
Which leaves the question worth carrying into your next OEM conversation: of the sections in your current validation package, how many would a reviewer be able to attribute to a named owner and a retrievable artefact — without asking you?
Frequently Asked Questions
What does carrying the perception package into governance-grade evidence for OEM trust packs mean in practice? OEM reviewers require perception validation packages that distinguish between sensor-level performance claims and full-stack inference guarantees. Perception Validation Package OEM is one of those terms that hides a simple idea. Perception Validation Package OEM answers cleanly when you separate two things. Perception Validation Package OEM is one of those terms that hides a simple idea. It means keeping the validation package’s reviewer-shaped sections intact and wrapping them in a governance layer: data and model provenance, versioned decision records, a named-owner matrix, and a defined change-control path. The technical evidence does not change; what changes is that the pack becomes readable and attributable without the perception team present.
Which sections of the perception validation package are reused unchanged, and which have to be rewritten for a governance reviewer? Scope of claim, metric definitions with threshold rationale, and the residual-risk statement generally carry through as written. Coverage results and failure-mode logs are reused but re-anchored to versioned artefacts and named owners, and four sections are genuinely new: provenance, decision records, the ownership matrix, and change-control scope.
What provenance, ownership and change-control evidence does a governance review require that a release review does not? Data origin and licensing basis, version hashes linking dataset to trained model to released artefact, versioned records of why each threshold and exclusion was set, an accountable role per section, and a statement of what class of model change triggers what re-validation scope. A release reviewer accepts the perception lead’s word on most of this; a governance reviewer needs it written down.
Who signs what — where does supplier sign-off end and OEM governance sign-off begin? The supplier signs to what was measured, what it means, and the limits it will stand behind. The OEM governance function signs to acceptance in its own system context: whether the claimed operational domain fits the programme, whether residual risk is acceptable at system level, and whether the change-control path matches its configuration management.
How is the governance layer kept stable when the perception model is updated after start of production? By classifying change types up front and mapping each to a re-validation scope — same-campaign re-training re-populates metric slots only, a new data campaign re-issues provenance and coverage, an architecture change re-opens failure-mode analysis, and an ODD change makes acceptance a new decision. Without that classification, every refresh becomes a full package rebuild.
How do you tell whether the evidence can be read without the perception team present? Give the pack to someone technically literate but uninvolved and ask them to state the claim and its boundaries, trace each headline number to a retrievable dataset version, name the accountable owner, account for every known failure mode, and say what a model update would require. Each question they cannot close from the documents alone is one the OEM reviewer will raise.
Where does an OEM trust pack still stop short of a regulatory safety case? The trust pack is supplier-side component evidence made independently auditable; it carries no system-level hazard argument and no assurance-case structure. The safety case is owned by the OEM’s safety organisation and argues about the vehicle as a whole, using the trust pack as one input among several.
Three non-negotiables for OEM handoff
Version control, reproducibility, and complete hyperparameter lineage form the foundation every automotive partner expects before signing. Perception Validation Package OEM rewards teams that measure first and argue later — start with the smallest instrumented slice and let the numbers settle the design.
