What Data Exchange Formats Support Battery Passports?

Data exchange formats are the structured formats in which passport data are stored, transferred and read by different systems, covering the data model, the serialisation, the vocabulary and the exchange protocol. For battery passports, Article 78 requires full interoperability with other digital product passports required by Union ecodesign law, in technical, semantic and organisational aspects of end to end communication and data transfer. Interoperability is therefore a legal design requirement, not a vendor preference, and format choices must be judged against it.

Format work is often treated as a technical detail to be settled by a software vendor, but the format determines whether a repairer, recycler or authority can read a passport created by a different system. A passport stored in a closed format, with a private vocabulary and no exchange protocol, fails the interoperability requirement even when the data are complete inside the originating system. Format decisions should be recorded as compliance decisions, with the standard, vocabulary and protocol named, and with the interoperability test that was carried out.

What does interoperability require of a format?

Interoperability requires that passport data can be exchanged between systems without loss of meaning, that identifiers resolve across systems, that access rights are respected during exchange, and that data integrity is preserved. Technical interoperability covers the format and protocol. Semantic interoperability covers the shared vocabulary and data model, so that a field means the same thing in the sending and receiving systems. Organisational interoperability covers the processes, roles and responsibilities that govern the exchange, including who may update a field and when.

A format assessment should test all three aspects, not only the file format. A test that shows a file can be opened in another system, without showing that the fields mean the same thing, tests only technical exchange. A test that shows field meanings align, without showing that update rights are respected, tests only semantics. The combined test is a round trip: create a passport in one system, transfer it to a second system, read and update it under access control, and return it without loss or unauthorised change.

What role do harmonised standards play?

Harmonised standards for digital product passports cover data exchange, unique identifiers, data carriers, storage and persistence, application programming interfaces and interoperability, among other horizontal aspects. Secondary reporting as checked on 28 October 2026 indicated that six horizontal standards were cited in the Official Journal in July 2026, covering those areas, with further standards on access rights and data integrity progressing. Standards provide the technical detail that the Regulation framework requires, and software should be built to the cited standards where they apply, rather than to a vendor specification alone.

Worked check: two passport systems claim interoperability. The first system exports a passport using the cited data exchange standard and the shared vocabulary, and the second system reads the fields with the same meanings. The second system exports using a private vocabulary, and the first system misreads a carbon footprint field as a capacity field. The first direction passes; the second fails on semantics. The interoperability claim should be stated direction by direction, not as a single yes or no for the pair.

How should a data model be structured?

A data model for passport software should be structured around the Annex XIII fields, with each field carrying a stable identifier, a defined type, a defined vocabulary value where applicable, a source, an access tier and a version. The model should separate model data from individual data, separate current values from history, and separate passport data from internal service data. A flat model that merges those separations will make access control, updating and auditing harder, because a change to one separation will affect the others.

Model documentation should include a field catalogue, listing each field, its Annex XIII source, its tier, its type and its update rule. A catalogue that lists field names without sources or tiers is a naming list, not a compliance model. A catalogue with sources, tiers and update rules can be reviewed by an authority, tested by an exchange partner and maintained when Annex XIII or a delegated act changes a field. The catalogue version should be recorded with the software version.

What exchange protocols matter?

Exchange protocols matter where passport data move between operator, supplier, repairer, recycler and authority systems, and where the registry is queried. Application programming interfaces defined by the harmonised standards provide the exchange route, with authentication, authorisation and integrity controls. A protocol that transfers data without authentication, or that returns restricted tier data without an access check, fails the exchange purpose even when the data format is correct. Protocol design and access design must be tested together, because a correct format with a weak protocol exposes data that the format was designed to protect.

Protocol testing should cover successful exchange, failed authentication, unauthorised tier request, and tampered payload, with each outcome recorded. A test suite that covers only successful exchange gives no evidence about failure handling, and failure handling is where access and integrity controls are proven. The test evidence should be kept with the software release record, so that a later exchange partner can see what was tested and what remains open.

How are formats versioned and migrated?

Formats are versioned through the data model, vocabulary and standard versions that the software implements, and migration must preserve meaning when a version changes. A version change that renames a field, changes a unit or redefines a vocabulary value without a mapping will corrupt historical passports if applied retrospectively. Migration should use explicit mappings, preserve the original values in the audit trail, and apply the new version only to new or updated records where the Regulation requires it, with the version recorded per record.

Migration planning should include a mapping document, a test migration on sample records, and a rollback plan. A migration carried out directly on live records, without a test migration, risks a loss that cannot be reversed from the live system alone. A migration with a test, a mapping and a preserved original can be audited and, where needed, reversed. The mapping document is part of the passport evidence for the affected records, and it should be dated.

What format claims should be avoided?

Format claims should avoid stating that a system is interoperable because it uses a common file format, that a system is standard compliant because it uses a standard name, or that a system is future proof because it uses a flexible model. Each claim needs a test: an exchange test for interoperability, a conformance test for standard compliance, and a version migration test for future readiness. As checked on 28 October 2026, the horizontal standards and the battery semantic catalogue were still progressing, so format claims should carry the standard version and the review date. This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting.

This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting. Format choices are compliance choices, and the exchange test should prove meaning, access and integrity together.