What does a battery passport record look like?
There is no universal six-field “battery passport form” that can be copied into production. The legal information groups sit in Annex XIII of the EU Batteries Regulation, with different access categories and both model-level and individual-battery information. The record below is a fictional teaching example, deliberately incomplete. Its labels and values illustrate how to organise evidence and ownership; they are not an approved format, a real battery, or a claim of compliance.
For a real product, start with the legal scope and a field register.
A fictional record with separate layers
Example: “Learning Pack A,” a made-up industrial battery model. The capacity and chemistry below are illustrative labels only; this example does not decide whether a real product is in scope.
| Layer | Example field | Fictional value | What a real record would need |
|---|---|---|---|
| Identity | Unit identifier | DEMO-UNIT-001 | A valid, unique identifier linked to the actual battery |
| Model | Model revision | LEARNING-A / REV-2 | Controlled specification and effective range |
| Model | Chemistry | “Example chemistry” | Defined composition and supporting source evidence |
| Model | Rated capacity | “Example value” | Correct unit, test basis and approved specification |
| Unit | Status | Original | Controlled update when status changes |
| Evidence | Specification reference | DEMO-SPEC-02 | Retrievable, versioned technical document |
| Governance | Data owner | Example product team | Named responsibility and approval process |
None of these sample values should appear on a public page for a real product. Annex XIII contains much more detail, and access to some information is restricted. A passport system should not publish its internal evidence register or restricted fields by default.
What would a public visitor and an authorised user see?
A public view would contain the model information that the applicable Annex XIII section makes publicly accessible. An authorised view may include other information according to the legal access rules. Test reports, detailed dismantling information and individual-battery use data should not be put on an unrestricted page simply because the QR code is public.
For this example, imagine that a public visitor sees the appropriate approved model facts and an authorised service role can view additional relevant fields after access control. The exact implementation must be mapped to current legislation and adopted measures. The QR code guide explains the scan and access path.
Follow one value back to evidence
Suppose the sample model shows a rated capacity. An internal reviewer should be able to answer: Which model revision does the value describe? In what unit? Which test or approved specification supports it? Who approved it? Does it apply to the scanned unit? If the specification changed, which batteries retain the earlier value?
A plain table cannot answer all of those questions. Behind the presentation, the process needs versioned source records and a way to resolve the correct value for the individual battery. This is the difference between a visual mockup and a maintainable information system.
What happens when the battery changes status?
In a learning exercise, add an event such as assessment for repurposing. Do not simply overwrite “original” with “repurposed” and discard the old state. Record what happened, when, who approved it and which evidence supports it. Article 77 contains specific provisions for batteries after preparation for re-use, repurposing or remanufacturing, including a new passport linked to the original passport or passports when the stated conditions apply. An exercise should flag that legal review rather than inventing a universal workflow.
The lifecycle hub sets out the related stages. The point here is record continuity: a future user should be able to understand why the displayed state differs from the original one.
Use the example as a workshop
- Replace the fictional labels with a non-sensitive representative product.
- Mark every field as model-level, unit-level, evidence or internal governance.
- Map each proposed passport field to the current Annex XIII and its access category.
- Give each value a definition, unit, source version and owner.
- Add one missing supplier input and one corrected value.
- Scan a test QR code and verify that the right record and view appear.
- Export the structured information and see whether another system can interpret it.
If the team cannot complete a step, record the gap rather than generating a plausible value. An incomplete but honest pilot is more useful than a convincing mockup with invented data. The software evaluation guide shows how to use this scenario in provider demonstrations.
What this example cannot establish
It cannot determine a battery’s legal classification, provide every mandatory field, assign legal responsibility, validate a QR standard, grant legitimate-interest access, or certify conformity. It is a learning aid for data architecture. Consult the current consolidated regulation and relevant adopted measures for decisions involving a real 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.