One vehicle change. Which evidence supports release?

Suggested review roles: Item owner; homologation owner. Lifecycle: Change intake and applicability. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Vehicle population bounded

   Evidence to request: Vehicle-scope record. Document only when: Variants and lifecycle state are explicit.

2. Markets and categories reviewed

   Evidence to request: Applicability decision. Document only when: Relevant markets and categories have a reviewed basis.

3. Change decision identified

   Evidence to request: Change request. Document only when: The intended release or update decision is named.

Suggested review roles: Cybersecurity/update managers; homologation reviewer. Lifecycle: Engineering and approval basis. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Engineering basis recorded

   Evidence to request: Edition register. Document only when: The engineering standard and applicable edition are identified.

2. R155 applicability reviewed

   Evidence to request: Homologation assessment. Document only when: CSMS and vehicle approval questions are separated.

3. R156 applicability reviewed

   Evidence to request: Update-management assessment. Document only when: SUMS and update approval implications are separately considered.

Suggested review roles: Item architect; interface owners. Lifecycle: Item definition and change impact. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Baseline fixed

   Evidence to request: Item definition reference. Document only when: The changed baseline can be identified.

2. Interfaces compared

   Evidence to request: Interface delta assessment. Document only when: Changed external and internal interfaces are covered.

3. Dependencies bounded

   Evidence to request: Dependency review. Document only when: Backend and shared-service assumptions are recorded.

Suggested review roles: Cybersecurity risk assessor; risk owner. Lifecycle: Threat analysis and risk treatment. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Threat delta assessed

   Evidence to request: Threat analysis delta. Document only when: The changed configuration is reflected in the reasoning.

2. Treatment traced

   Evidence to request: Risk treatment record. Document only when: Each reviewed risk has an accountable treatment.

3. Residual uncertainty accepted explicitly

   Evidence to request: Risk decision reference. Document only when: An authorised role owns the remaining uncertainty.

Suggested review roles: Requirement owners; implementation/verification leads. Lifecycle: Development and traceability. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Goals allocated

   Evidence to request: Goal-to-requirement trace. Document only when: Relevant goals reach named implementation owners.

2. Implementation traced

   Evidence to request: Implementation record. Document only when: The changed requirements link to the released baseline.

3. Verification linked

   Evidence to request: Requirement-to-result trace. Document only when: Results and deviations cover the stated claim.

Suggested review roles: OEM integrator; supplier engineering lead. Lifecycle: Distributed development and handover. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Responsibilities agreed

   Evidence to request: Development-interface agreement. Document only when: Required handovers and decision owners are explicit.

2. Evidence accepted critically

   Evidence to request: Supplier handover review. Document only when: Assumptions and limitations are not lost at integration.

3. Integration gaps owned

   Evidence to request: Integration action register. Document only when: Unresolved interface questions have owners.

Suggested review roles: Vehicle validation owner; component verification lead. Lifecycle: Component and vehicle validation. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Component evidence scoped

   Evidence to request: Component result reference. Document only when: The result covers the actual version and configuration.

2. Vehicle context validated

   Evidence to request: Vehicle validation reference. Document only when: The claimed behaviour is assessed in representative context.

3. Deviations resolved or escalated

   Evidence to request: Deviation review. Document only when: An authorised role decides how open findings affect release.

Suggested review roles: Configuration manager; software-update owner. Lifecycle: Software identification and target selection. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Software state identifiable

   Evidence to request: Software-identification record. Document only when: Released identifiers link to the intended baseline.

2. Target variants matched

   Evidence to request: Target-population review. Document only when: Compatible vehicles are distinguished from other variants.

3. Applicable RXSWIN handling reviewed

   Evidence to request: Regulatory software-identity assessment. Document only when: The required identification approach has an applicability rationale.

Suggested review roles: Update engineer; release authority. Lifecycle: Update readiness and installation. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Update authorisation checked

   Evidence to request: Release authorisation. Document only when: The package and actor have the appropriate authority.

2. Integrity and authenticity verified

   Evidence to request: Package verification result. Document only when: Checks cover the package actually to be delivered.

3. Installation prerequisites verified

   Evidence to request: Readiness test record. Document only when: Vehicle state and dependencies are checked before installation.

4. Interruption handled

   Evidence to request: Approved interruption-test reference. Document only when: Power or connection loss leads to assessed handling.

Suggested review roles: Update/recovery owner; safety reviewer. Lifecycle: Failure handling and recovery validation. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Failure state assessed

   Evidence to request: Failure analysis. Document only when: The effect of an incomplete update is understood.

2. Recovery strategy verified

   Evidence to request: Recovery result reference. Document only when: The strategy works under the assessed constraints.

3. Rollback assumptions challenged

   Evidence to request: Recovery decision. Document only when: Rollback is not presumed feasible or safe in every case.

Suggested review roles: Release authority; homologation owner. Lifecycle: Internal release and approval-impact decision. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Engineering conclusion owned

   Evidence to request: Cybersecurity conclusion. Document only when: The evidence and unresolved issues support an explicit internal decision.

2. Approval impact reviewed

   Evidence to request: Homologation change-impact record. Document only when: The team has assessed changes to type-approved characteristics.

3. Formal and internal decisions separated

   Evidence to request: Release dossier index. Document only when: Internal sign-off is not presented as an authority approval.

Suggested review roles: Post-production security owner; field response lead. Lifecycle: Fleet monitoring and reassessment. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory.

1. Field evidence received

   Evidence to request: Monitoring and intake record. Document only when: Relevant findings can reach the vehicle security team.

2. Affected variants assessed

   Evidence to request: Exposure and response review. Document only when: The deployed population can be assessed when evidence changes.

3. Decision reopened

   Evidence to request: Reassessment trigger record. Document only when: An owner tracks invalidating changes and new findings.