AN INDEPENDENT KNOWLEDGE PUBLICATION Our editorial approach ↗
BatteryPassport.digital Search guides /
Menu & topics
Software & providers

How Do Interoperability and Open Data Differ for Passports?

Interoperability governs controlled exchange between systems under access rights, while open data governs publication of the public tier without authentication.

GUIDE / SOFTWARE & PROVIDERSIDENTITY → INFORMATION → EVIDENCE

Interoperability and open data are related but distinct ideas in passport software. Interoperability means that passport systems can exchange data without loss of meaning, under the access rights that apply. Open data means that some passport data are made available to the public or to defined actors without restriction, where Annex XIII and the access rules provide for it. A system can be interoperable without making restricted data open, and a system can publish open data without being interoperable with other passport systems. The two ideas must be designed separately, even though they share format and vocabulary work.

The distinction protects both purposes. Open data serves transparency, comparison and public accountability for the public tier. Interoperability serves repair, recycling, authority checking and supply chain coordination across systems for all tiers. A design that treats every interoperable field as open will disclose restricted data. A design that treats every open field as a private exchange will hide public data. The access tier map is the control that keeps the two purposes apart.

What data are open in a battery passport?

Open data in a battery passport are the Annex XIII fields assigned to the public access tier, including manufacturer and model identification, chemistry and capacity presentation, carbon footprint presentation where public, and general information that a member of the public needs to identify and understand the battery. The public tier is defined by Annex XIII, not by a vendor or operator choice, and the software must implement the tier as defined, with the implementing act detail where it applies. A field assigned to a restricted tier must not be published as open data, even when publication would be commercially convenient.

An open data check should list each public field, its source, its value and its publication route, and should confirm that no restricted field appears in the public route. A check that confirms only that public fields are present, without confirming that restricted fields are absent, is incomplete. The public route should be tested from an unauthenticated device, with the result recorded, so that the test reflects the public experience rather than an internal view.

How does interoperability differ from open data?

Interoperability differs from open data in audience, control and purpose. Interoperability governs exchange between identified systems and actors, under authentication and access rights, for all tiers. Open data governs publication to an undefined public audience, without authentication, for the public tier only. An interoperable exchange with a recycler, for example, can carry dismantling information under legitimate interest access, while the public route for the same battery carries only the public tier. The same passport therefore produces different data sets for different audiences, and the software must generate each set from the same source record under tier control.

AudienceAccess basisData set
PublicNo authentication, public tierPublic fields only
Legitimate interest actorAuthenticated, tier rightsPublic plus legitimate interest fields
Authority and notified bodyAuthenticated, tier rightsFields assigned to authority tier

Worked check: a recycler requests dismantling information through an interoperable exchange, and a member of the public scans the QR code. The recycler receives the dismantling fields after authentication and access checking. The public scan returns only the public fields. A system that returns the same data set to both audiences fails the tier distinction in one direction or the other. The test should be carried out for both audiences on the same battery, with the results compared.

What standards support open and interoperable data?

Open and interoperable data are supported by the same harmonised standards for data exchange, identifiers, carriers and APIs, together with the shared vocabulary and data model for the product group. The standards define how data are structured and exchanged, while Annex XIII and the access rules define which data are open and which are restricted. Software should implement the standards for structure and exchange, and implement Annex XIII for tier assignment, with the two implementations tested separately. A standard conformance test does not prove correct tier assignment, and a tier test does not prove standard conformance.

Standard and tier testing should be recorded as separate test suites, with separate results. A release note that states only that the system passed interoperability testing, without stating whether tier testing was carried out, leaves the tier question open. A release note with both suites, each dated, allows an exchange partner and an authority to judge the system on both dimensions. The suites should be rerun after a standard version change or a tier rule change.

How should open data be published?

Open data should be published through the QR code resolution route and any other public route that the Regulation or implementing act provides, in a machine readable format that allows comparison and reuse, subject to the access and integrity rules. Publication should be stable, versioned and linked to the battery identifier, so that a public record consulted today can be compared with the same record consulted later. A public page that changes without versioning, or that is available only through a closed application, does not serve the open data purpose, even when the data are technically public.

Publication checks should cover availability, machine readability, versioning and identifier linkage. A check that confirms only that a human can read a page misses machine readability. A check that confirms only that data are present misses versioning. The combined check should be carried out with a standard browser and a standard data tool, with the results recorded. A publication failure in any element should be treated as an open data failure, not as a cosmetic issue.

What limits apply to open data reuse?

Open data reuse is limited by the accuracy and currency duties that apply to the passport, and by the prohibition on operators authorised to store or process passport data selling, reusing or processing data beyond what is necessary for the storing or processing service, as set in Article 78. A third party that reuses public tier data must not present the data as verified beyond the passport source, must not merge public data with restricted data obtained elsewhere and present the merge as a passport, and must respect the identifier and versioning that link the data to the battery. Reuse that breaks the link to the source record creates a detached data set that cannot be verified.

Reuse guidance in the public route should state the source, the version and the identifier, and should warn against detached reuse. A public route without source and version information invites detached reuse, because a reuser has no link to preserve. A public route with source, version and identifier allows a reuser to preserve the link and allows a reader to verify the data. The guidance is part of the open data design, not an addition after publication.

How are interoperability and open data reviewed together?

Interoperability and open data should be reviewed together after each standard, catalogue or access rule change, because a change in one area can affect the other. A vocabulary change can affect both exchange meaning and public presentation. An access rule change can affect both exchange audiences and public publication. A joint review should list the change, the fields affected, the exchange test and the public test, with dates. As checked on 28 October 2026, the battery semantic catalogue and access rules were still progressing, so joint reviews should be scheduled around the next catalogue and act publications. 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. The tier map keeps exchange and publication apart, and both should be tested on the same battery.

Sources & further reading

Source links point to primary materials and further reading, including commercial implementation resources where cited. This introductory guide does not replace the legislation.