Which Battery Passport Data Model Should You Choose? (State of Play, 18 September 2026)

State of play on 18 September 2026. That is the first thing to say, and the most important: this article describes a situation that moves every two to three months. If you are reading it in spring 2027, skip straight to the last section — at least two lines of the table below will have stopped being true.

A company searching today for “the battery passport data model” almost always lands on the GitHub repository batterypass/BatteryPassDataModel and its version 1.2.0, and concludes that this is the standard to follow. It is the old model, from a project that has ended — and the repository has said so itself since 14 September 2026.

The short answer

The rest of this article explains why that split exists, and why it is unstable by construction.

What is settled, and what is not

Regulation (EU) 2023/1542 requires a digital passport from 18 February 2027 for three categories: electric vehicles, light means of transport (LMT), and industrial batteries above 2 kWh, including stationary storage. The passport is in Article 77, the list of information in Annex XIII. The Commission detailed that list in guidance published as version 2.0 on 15 August 2026: 71 data points, with their applicability by category.

That layer is stable. Which information must appear in a battery passport is a question settled by law.

The Regulation, however, does not say how to name the fields, how to structure them, or how to serialise them. That format must come from a semantic catalogue published by the Commission, which does not yet exist for batteries. This is not a guess: the user guide for the EU DPP registry, published by DG GROW, states plainly that registration of battery passports is unavailable precisely because the semantic catalogue for that product group has not yet been defined. We covered it in our article on the DPP registry.

What does exist is the infrastructure. CEN-CENELEC JTC 24 has produced eight standards for the digital product passport — unique identifiers, data carriers, exchange protocols, APIs, persistence, interoperability, that is references EN 18216 to EN 18223, published in 2026. They describe the plumbing, not the battery business vocabulary.

Hence today's situation: the data is settled, the plumbing is standardised, and the vocabulary joining the two is still the object of pre-normative work.

The GitHub repository declared itself obsolete

On 14 September 2026, a banner appeared at the top of the README of batterypass/BatteryPassDataModel:

The project BatteryPass concluded successfully in April 2025. This repository is no longer actively maintained and is provided for reference purposes only for now. It contains the BatteryPass data model as of 2025. For ongoing developments and the latest information on regulatory and standardization requirements, please visit the follow-up project BatteryPass-Ready.

This is the single most useful fact in this article, because it is verifiable in ten seconds and it contradicts what search results hand you. Between January 2025 and September 2026 the repository received only editorial changes: licences moved to CC BY 4.0 in October 2025, preferred names added for the AAS in November 2025. The model itself stayed at 1.2.0.

A repository that does not move for twenty months, in a field where regulation moves every quarter, is not a stable standard. It is an abandoned one.

The two models are not two versions of the same thing

This is the costliest mistake, because it leads teams to plan a “1.2.0 → 2.0 migration” that does not exist. The BatteryPass-Ready Data Model documentation is explicit, in its Relation to Other Work section:

The BatteryPass-Ready Data Model is a new development and does not represent an updated version of the previous Battery Pass Data Model published on GitHub.

Same normative basis — DIN DKE SPEC 99100 — but a complete rebuild seventeen months later, additionally incorporating JTC 24 work and the ESPR. What that changes in practice:

That last line is the only area where the old model retains an advantage, and it is not a small one: per-attribute semanticId values make it directly usable inside an Asset Administration Shell or a Catena-X dataspace. The BatteryPass-Ready model does not carry them.

“v1.3” is not newer than “1.2.0”

A versioning trap, and it wastes everyone's time: the longlist and the data model are two different objects, each with its own version counter.

• •The Data Attribute Longlist is an inventory of attributes, delivered as a spreadsheet. Its versions: 2023, v1.2 in January 2025, v1.3 in March 2026 (100 attributes), v2.0 on 27 August 2026 (92 attributes).
• •The Data Model is a set of schemas. On the Battery Pass side: 1.0.0 on 28 May 2024, 1.2.0 on 14 January 2025. On the BatteryPass-Ready side: v1.0 on 24 June 2026, v2.0 on 27 August 2026.

The BatteryPass-Ready model started at v1.0 because it was its first version, not because it predates the GitHub 1.2.0. Four versions of the attribute list in three years, two successive data models in fifteen months: that is the real cadence of this field.

What v2.0 of 27 August 2026 changed

• •92 attributes, down from 100 in v1.3.
• •8 categories instead of 7, with a new DPP header category derived from the interoperability requirements of EN 18223.
• •Explicit requirement marking: M (mandatory), C (conditional), V (voluntary), or none.
• •New attributes from the JTC 24 standards (content specification IDs) and from the implementing act on the registry (third party service provider).
• •A basis moved from JTC 24 drafts to the final standards published in June 2026, according to the project changelog.
• •A Technical references tab that maps the longlist explicitly onto the model — the most useful piece of the set if you have to build a correspondence table.
• •71 attributes mandatory on 18 February 2027, matching exactly the 71 data points of the Commission guidance.

Why German consortia are the ones publishing the model

The question comes up in every workshop, and the answer prevents misunderstandings.

Two successive projects, funded by the German federal ministry for economic affairs under the same budget line (16BZF363), produced these deliverables. Battery Pass (April 2022 → April 2025), coordinated by Systemiq, produced the Content Guidance, the Technical Guidance, the DIN DKE SPEC 99100 specification and the model published on GitHub. BatteryPass-Ready (2025 → 2027) succeeded it, with acatech, Bitkom, Fraunhofer IPK, GEFEG, TU Berlin, VDA, VDMA and ZIV: a Data Attribute Longlist, a new data model, and an online test environment.

Why not a national standards body such as AFNOR? Because that is not its role. On the DPP, competence sits at European level — that is JTC 24 — and national bodies take part through mirror committees, then publish the European standards nationally; CEN-CENELEC rules do not allow a national body to publish a competing standard while European work is under way. On the German side, DIN DKE SPEC 99100 is not a standard either: a DIN SPEC is a short-cycle pre-normative document, produced by a self-assembled consortium, without the national consensus a standard requires. It is the instrument that allows fast publication alongside the formal standardisation route.

The right word for this work is therefore pre-normative. It brings together industry federations and public research institutions, on public funding, and it feeds the standardisation process rather than replacing it.

So which one do you pick? Four situations

You are starting data collection. Do not start from a schema. Open the Commission guidance and longlist v2.0, and ask the only question that matters about each attribute: who, inside the company or at a supplier, holds this value today? That is the work that takes months, and it is independent of the format you end up with.

You need to serialise now — proof of concept, pilot, tender response. Take the BatteryPass-Ready Data Model v2.0 and its online validation environment. It is the most advanced industry reference, and the only one aligned with the 2026 state of law and standards. Knowing that it has no regulatory force and that it will change.

You are in an AAS or Catena-X dataspace. The GitHub 1.2.0 model keeps its usefulness as a semantic layer, because of the per-attribute semanticId values, but it must no longer serve as a scope reference: it ignores the state of the law since January 2025. Treat it as a semantic dictionary, not as a compliance specification.

You are building your internal model. The rule is simple: one internal model, N exports. Model the business data — the battery, its components, its measurements, its documents — and treat the longlist, the BatteryPass-Ready model, the AAS and the Commission's future semantic catalogue as export targets. Any other architecture makes you redo the work at every new version.

What is stable is the data. What moves is the format.

This is the only genuinely structural trade-off, and it has a direct operational consequence.

Renaming a field is a mapping exercise: a few days of work, with no external dependency. Data that was never collected is an industrial programme: you have to identify who holds it, often a tier-2 or tier-3 supplier, negotiate access, measure it, push it up the chain, check it. On materials, carbon footprint or recycled content, that is counted in quarters.

A company waiting for “the right model” before it starts collecting is losing the time that actually matters. A company collecting now, in its own model, will absorb format changes as mapping tasks. The rest of the validation method is set out in our article on how to test your battery passport before 2027.

Careful: the full model is not the legal obligation

Out of 92 to 100 attributes depending on the longlist version, only 71 are due on 18 February 2027. And some must explicitly not be filled in at that date — the carbon footprint declaration and label in particular, whose format still awaits an implementing act.

Confusing “the full model” with “the legal obligation” leads to a counter-intuitive outcome: publishing a non-compliant passport even though it contains everything the law asks for. Over-disclosure also exposes industrial information with no obligation to do so.

This article has an expiry date

The model authors say so themselves. The longlist v2.0 changelog states that some information is subject to change and only reflects the state of knowledge as of 26 August 2026, in particular in view of the draft environmental omnibus legislation and the expected implementing acts on labelling, carbon footprint declaration and data access. It adds that data formats will be revisited in detail as the model is implemented in the test environment. The consortium's disclaimer does not guarantee that the content is complete, accurate or up to date.

Four events will make this article wrong, and all four are expected within twelve months:

1. 01.Publication of the battery semantic catalogue by the Commission. On that day everything above becomes historical documentation: the format becomes binding, and the consortium models revert to what they are, preparatory work. Watch the Commission's “DPP — batteries” page and successive versions of the registry user guide.
2. 02.A v3.0 of the BatteryPass-Ready longlist or model. The observed cadence is roughly six months. Watch thebatterypass.eu.
3. 03.Publication of the expected implementing acts, notably on carbon footprint. Each one reopens attributes currently marked “do not fill in”.
4. 04.Battery registration actually opening in the EU registry, which will signal that the semantic catalogue is in place.

If you are reading this after February 2027, the obligation is already in force: redo these four checks before using a single line of this article. Good practice in this field is never to cite a data model without its version and its date — including ours.

In short

As of 18 September 2026: follow the Commission guidance for the what, BatteryPass-Ready v2.0 for the provisional how, standards EN 18216 to 18223 for exchange, and forget the GitHub 1.2.0 repository except as a semantic dictionary for AAS work. None of these models has regulatory force: they are candidates, pending the Commission's semantic catalogue.

Arianee runs an open DPP infrastructure built on that principle: one internal data model, exports to industry formats, and passports that outlive specification changes. See our Battery Pass page, assess your position with the DPP readiness simulator, or request a demo.

Sources

• •Regulation (EU) 2023/1542 on batteries — Articles 77, 78 and Annex XIII (EUR-Lex)
• •Guidance Document: Digital Batteries Passport – data points by category, v2.0, 15 August 2026 (European Commission, DG GROW)
• •Digital Product Passport — Batteries, European Commission
• •GitHub repository batterypass/BatteryPassDataModel — banner commit, 14 September 2026
• •Battery Pass project (2022-2025) and BatteryPass-Ready project (2025-2027) — resources
• •Announcement of Data Attribute Longlist v2.0 and Data Model v2.0, 27 August 2026 · longlist v2.0 (XLSX) · longlist v1.3 (XLSX)
• •BatteryPass-Ready Data Model documentation (PDF, GEFEG) — the schemas themselves are hosted on the GEFEG GitLab, where anonymous access is restricted
• •DIN DKE SPEC 99100 (free PDF)
• •CEN-CENELEC JTC 24 “Digital Product Passport” committee