Validation and release review

IVI 2.0 XML validation for eCoC

IVI 2.0 XML validation should answer two questions: does the file follow the required structure, and is the vehicle information ready for release? Electronic COC connects XML review with the manufacturer’s data-correction and approval workflow, so a failed check has a clear next action.

Request a workflow demoExplore the platform
01

Check structure, content and destination separately

The applicable XSD defines the XML structure, data types and constraints. A file can satisfy structural checks while still containing a value that needs technical review. The destination may also require a particular schema revision or national profile. Record which checks were run and against which version.

  • Structure: required elements, data types and permitted formats.
  • Vehicle content: VIN, approval references and technical values for the actual build.
  • Destination: applicable schema revision, signing requirements and submission instructions.
02

Turn a validation result into a correction task

A useful result identifies the affected record, the field or rule, the issue and its owner. For example, if a required production value is missing, the reviewer needs to return that specific value to the source-data owner. Generating the same file again without correcting the source will reproduce the problem. This example describes a review approach, not an authority test result.

  • Keep the rejected input and the reason for correction linked to the vehicle.
  • Correct the approved source and generate a new candidate version.
  • Repeat the relevant checks before the corrected version moves to signing.
03

Protect the reviewed version through signing

Treat the reviewed XML as a specific release candidate. A content change after review should reopen the affected checks. After signing, preserve the resulting file and verify that it is the version handed to the delivery process. XML validity, signature verification and the authority’s response are separate evidence points.

04

Make the pilot test failure paths as well as success

Use sanitised samples representing your vehicle categories and source systems. Include missing fields, unexpected formats, a corrected record and a repeat submission scenario. Agree which findings block release and which require a reviewer’s decision. The demonstration should make those decisions understandable to the people who resolve them.

Questions and answers

Which schema should we use for IVI 2.0 XML validation?

Use the schema revision and any national profile specified by the receiving authority. Keep that reference with the test results; the label IVI 2.0 alone does not identify every destination-specific requirement.

Does passing an XSD check mean the eCoC will be accepted?

No. Structural validation does not establish the correctness of every vehicle value, the validity of a signature or the receiving authority’s acceptance. Review and record those outcomes separately.

Can validation be connected to our production workflow?

Scope the source-data mapping, checks, review ownership and release handover together. Bring an example of both a complete and an incomplete record so the proposed workflow can be evaluated against real production tasks.

Official references

Reviewed . Requirements are defined by the linked authorities and service documentation.

  • EReg: IVI 2.0 guidelines

    Technical guidance for the IVI 2.0 data structure. Use the receiving authority’s applicable schema and instructions for your submission.

Continue through the eCoC workflow

eCoC XML signing and API integration

Connect eCoC XML signing to the reviewed vehicle record. Scope certificate ownership, signing API handovers, validation and submission evidence.

Review your IVI XML validation workflow

Tell us which vehicle categories, source files and target schema you use. We can identify the checks and correction handovers to demonstrate.

Request a workflow demo

Review implementation scope and pricing