Battery
The Battery Pass Data Model and Catena-X
What the Battery Pass data model, Catena-X and the GBA pilots give a manufacturer versus what the law requires, and how Annex XIII maps to JSON-LD and AAS.
Annex XIII says what the battery passport contains; it does not say how each attribute is named, in which unit it is measured or in which data type it travels. That gap was filled by three initiatives that started before the regulation took effect: the publicly funded German Battery Pass consortium, the Catena-X battery passport use case and the Global Battery Alliance pilots.
For a manufacturer the question is which of these is binding, which is guidance, and how a Digital Product Passport platform reduces all three to a single canonical model. AAS and the Catena-X ecosystem explains the architecture; here we look at the data model itself.
Three sources, three roles
| Source | What it gives | Status |
|---|---|---|
| Regulation, Annex XIII | Attribute list, access tier, application date | Binding |
| Battery Pass consortium | Content guidance (definition, unit, data type, legal basis), technical guidance, open data model | Reference; not binding |
| Catena-X battery passport | SAMM aspect model, Tractus-X reference implementation, sharing over EDC | Ecosystem standard; binding through OEM contracts |
| Global Battery Alliance | Passport pilots; rulebooks on topics such as greenhouse gases and due diligence | Voluntary, global |
What the law says, what the guidance adds
Annex XIII defines an attribute in prose: "the carbon footprint of the battery", "share of recycled cobalt", "rated capacity". In practice that is quickly found wanting. Is the carbon footprint declared as a total or per kWh? Is the recycled share a percentage or a mass? Under which test condition is rated capacity measured?
The Battery Pass content guidance answers exactly these questions: for each attribute, a definition, unit, data type, cardinality, access tier and the article of the regulation it rests on. The technical guidance and the open data model make it machine-readable. The "roughly 90 attributes" figure in Annex XIII data fields comes from this mapping.
The boundary must stay clear: guidance removes the law's ambiguity but does not replace it. If secondary legislation sets a different unit or format, the guidance follows it, not the other way round. Why the carbon field deserves its own article, with its dependence on the methodology delegated act, is explained in the battery carbon footprint declaration.
How Catena-X carries the same fields
Catena-X translates the Battery Pass dictionary into its own semantic language: a battery passport aspect model defined in SAMM binds every attribute to a typed, versioned structure. The Tractus-X reference implementation provides an open-source application that reads, displays and requests this model over an EDC connector. When an automotive OEM asks a supplier for "the passport", this is usually what it means; details in the DPP in automotive and Catena-X.
The critical point for a manufacturer: the aspect model uses Catena-X field names, not Annex XIII field names. Without a maintained mapping table there is no crossing between the two worlds.
From Annex XIII to JSON-LD and AAS
What a passport platform has to do is not carry three models side by side, but keep one canonical model and generate the serialisation required:
- Key every field to its Annex XIII attribute and access tier; write the consortium definition and unit into the field definition.
- Produce JSON-LD for the public and API surface: the EN 18223 core model as context, battery fields as an extension. See the EN 18223 core data model and JSON-LD and DPP data.
- For the automotive customer, generate the AAS submodel or Catena-X aspect output from the same record; keep the mapping table in configuration, not in code.
- Write the model version used into every passport version, so old versions remain interpretable when the model changes.
- Fix units at input: kWh, kg CO2e/kWh, percent. Do not leave conversion to the serialisation layer.
The general principles of this approach are in the data model guide; how Article 78's open-standard and interoperability requirements shape the same architecture is covered in battery passport technical design.
Managing change
All three sources are alive: the consortium model is updated, Catena-X releases new versions, and the Commission's secondary legislation setting the passport's technical specifications is still expected. Keeping field definitions in a versioned dictionary rather than embedding them in code lowers the cost of the re-mapping that will happen at least once after 2027. The dictionary also needs an owner: who updates the data model, who approves, and how long old versions stay readable?
Frequently asked questions
Is using the Battery Pass data model mandatory?
No. What binds is Annex XIII and the secondary legislation attached to it. The model is the sector's shared reference for interpreting the fields; using it eases compliance but does not deliver it on its own.
Can I publish a battery passport without being a Catena-X member?
Yes. The regulation requires the passport to be publicly accessible through the QR code; Catena-X is an additional channel your automotive customer may ask for in data exchange.
Is publishing the same data as both JSON-LD and AAS double work?
Not if you keep a single canonical model; both outputs are generated from the same record. Double work arises from filling two models separately by hand.
