The battery passport becomes mandatory on 18 February 2027, and with it comes a question that had no good answer until now: how do you know your provider's system actually complies? A claim of “we follow the standard” is worth nothing. That is why the BatteryPass-Ready project — the successor to Battery Pass, which closed in February 2025, funded by the German federal government — published a conformance suite for the CEN-CENELEC JTC24 data model — and we ran it end to end, from zero to eleven green tests. This article covers what we measured along the way, what we got wrong, and what is worth knowing whether you are with us or elsewhere.
Schema validation and conformance testing are not the same
They are easy to confuse, yet they prove entirely different things.
| Schema validation | Conformance testing | |
|---|---|---|
| What does it inspect? | a submitted file | a running system, over the network |
| What does it answer? | “is the submitted data correct?” | “does the system behave as the standard requires?” |
| What does it miss? | missing fields, access rights, versioning, outbound reporting | — |
| How long? | seconds | the system must be prepared: test adapter, credentials, external services |
The suite does not ask you for a file — it calls you. It prepares the state (inserts passports, issues an access token), then runs the scenarios against your live interface. That proves far more, and it is far harder to pass.
The biggest lesson: a green validator does not mean coverage
Our own battery passport had “passed every test” at the official validator for months. We took that to mean our model was complete. Then we measured it differently: we took every leaf field of the official data model and checked how many we could actually emit.
The result: 129 out of 211. That is 61%.
Eighty-two fields were missing — including fourteen field groups our schema did not know at all: the absolute carbon footprint, certified and remaining usable energy, the cadmium/lead marking, the warranty period, the date of putting into service, the number of overcharge and deep-discharge events, supply-chain risk indices. And — most telling of all — the recycled content per material (cobalt, lithium, nickel, lead), which we actually stored, just in a different shape, and therefore never mapped.
Why did nothing warn us? Because a validator checks whether what you submitted is correct — not whether it is sufficient. It will never complain about a missing optional field. This is the most dangerous class of error: it reassures you without grounds.
Coverage is now measured by a dedicated tool here, and a test guards it so it cannot silently regress. It currently stands at 100% — with a single field deliberately left out, and the reason recorded: the format of the content specification identifier is not described by the schema and does not appear in the official sample document, and we do not send made-up identifiers.
The 11 tests — and what they mean in practice
| Test | What it checks | What it means in practice |
|---|---|---|
| Read by ID | the DPP identifier returns exactly its own passport | two passports cannot get mixed up |
| Read by product ID | returns the active version of the product | the current data goes out, not an old version |
| Read a data element | a single field can be read on its own | partners need not download the whole document |
| Access filtering | the response is filtered field by field by role | the public does not see what it must not |
| Withdrawn passport | a withdrawn passport is not served on normal reads | invalid data stops circulating |
| Full update | an update creates a new, auditable version | what changed, and when, stays traceable |
| Update a data element | exactly one field changes, nothing else | no side effects on other data |
| Add an attribute | a new sub-field can be added | the passport is extensible, not frozen |
| Delete an attribute | null deletes the field | wrong data can be removed, not merely overwritten |
| Permission check | no write without write permission | a read link does not let anyone edit |
| Placing on the market | did the copy reach the backup provider, and was the registry notified | the obligation is not a matter of declaration — it is checked |
That last row matters most. (EU) 2023/1542 is not satisfied by you holding the data: it must also be stored with an independent provider, and placing on the market must be reported. The suite does not read your statement — it checks whether the call was actually made.
What we got wrong — seven concrete cases
This section is the most useful if you are integrating too. Every item is a real, measured failure, not theory; none of them would have surfaced from schema validation.
1. The shape of an error message is part of the standard
We started with our own {"error":{"code","message"}} shape. The specification expects a message array instead, each entry carrying a type, text, code and timestamp. Serve your own error format and you fail the error-handling tests — and your partner cannot parse it either.
2. A data-element response must be wrapped in the field name
When a single data element is requested, you must not return the bare object but the object under its field name:
| Wrong | Right |
|---|---|
{ "name": "…", "postalAddress": "…" } |
{ "economicOperatorInformation": { "name": "…" } } |
We returned byte-identical content and still failed — and stared at it for a while, until we printed the executor's own diff report.
3. “Last updated” is not the moment of serving
This was the sneakiest one. We wrote the time of serving into lastUpdated, so two consecutive reads never produced the same document. The comparison tests (our copy ↔ the copy at the backup provider) therefore depended on second-level luck: sometimes they passed, sometimes not. If you see this in your own system, do not blame the network — the field means the passport's actual modification time.
4. A withdrawn passport is 404 for everyone
We assumed the economic operator should still see their own withdrawn passport. Wrong: on this machine interface a withdrawn passport is served to nobody, not even the owner. You must of course retain it (authorities may request it retrospectively), but normal reads must not serve it.
5. The withdrawn state comes from the document
The suite inserts a document in archived state, and the status sits inside the document itself — not in a separate command field. Miss that, and the passport is created as active, leaving the “withdrawn is not readable” test with nothing to examine.
6. Missing role: 401, not 403
Semantically, 403 (Forbidden) is the right answer when someone is authenticated but lacks write permission. In the suite's vocabulary, however, this case is “Unauthorized”, and on a 403 the executor errors out — it does not even inspect the response. The official specification does not list 403 for updates at all.
7. The registry does not want the document
When reporting the placing on the market, we submitted the full passport. The registry, however, asks for three identifiers: Product_ID, Backup_ID, Operator_ID. The Backup_ID is what the backup provider returns to you — meaning the order is fixed: back up first, report second. You cannot read that out of the standard, only out of the failure.
On top of that, an update sent to the backup provider for a passport it does not hold returns 401, not 404 — so you cannot build “it is not there yet” logic on the status code. Our backup therefore switches in both directions between create and update.
Access levels: the quietest source of error
The JTC24 data model specifies field by field who may see what. This is not decoration: it follows from the regulation, and the suite measures it field by field.
A purpose-built audit found four mismatches here. Three were disclosed to the public when they should not have been:
- the economic operator's identifier — only notified bodies, authorities and the Commission may see it;
- the manufacturing facility identifier — the same circle;
- the cathode, anode and electrolyte materials — for repairers, recyclers and purchasers, not for the general public.
The fourth ran the other way: we had hidden the due diligence report, which the regulation intends to be public. Also an error — just in the opposite direction.
Why is this area dangerous? Because the failure is silent. If a field is public by mistake, nothing errors, nothing warns, the page works perfectly — simply more data leaves the system than should. Only targeted measurement finds it.
What did not even depend on the standard
For a long time most tests failed because our outbound calls never arrived at all. The error read: unable to get local issuer certificate. Our server's HTTP client had no usable root certificate store, while the other side's certificate chain was flawless.
This is instructive because it affects every outbound call — the payment provider, e-mail delivery, webhooks — and the symptom shows at the other end: nothing happens there. If your system says “reported” but the partner has no trace of it, check this first.
Two lessons: carry the root certificates with you rather than trusting the server to have them — and never turn certificate verification off. You are sending passport data; an unverified connection would break exactly the trust the whole system exists for.
“Saveable” and “legally complete” are two different things
One closing lesson that is not about the standard but about software. Every system has a technical minimum: the few fields without which no meaningful record exists (name, SKU, category). Ours is 12 fields.
We filled in exactly those twelve for an EV battery and measured legal completeness. The result: 17%. Fifty-eight fields were missing.
If the interface calls those twelve “mandatory”, it signals that you are done — yet that is not what decides a penalty. That is why our editor now warns before saving when a passport is legally incomplete: it shows the percentage, the missing fields and the legal basis. It does not block — data often accumulates in stages, and it is not software's job to decide when a passport is “finished” — but it no longer lets it go out silently.
When choosing a provider, this distinction is worth asking about: does the system warn me if I issue a legally incomplete passport?
What a green result does NOT mean
This deserves saying plainly, because the market is full of ambiguous claims:
- It is not an official certificate. The suite is an industry consortium's tool, not EU accreditation. Passing it does not make a system “EU certified”.
- It is not about your data. It measures that the system behaves correctly — not that your passport is complete. That remains your responsibility.
- It does not replace registration. The EU semantic catalogue for batteries is not live yet; until it is, nobody can actually register a battery passport.
- It is not forever. The data model has versions and profiles; the set binding from February 2027 is narrower than the full model. What conforms today must be re-measured at the next version.
Seven questions for your provider
If you have to issue battery passports, these will reveal within minutes where a system stands:
- Does it pass the official conformance suite? Which tests are green? “Standards-compliant” is not an answer in itself.
- What percentage of the official data model can it emit? A schema validator will not tell you — this has to be measured separately.
- Does it handle access levels field by field? Ask for a concrete example: who can see the economic operator's identifier?
- Does a copy reach the backup provider, and is there an auditable trace? “Did we report it?” must have a demonstrable answer.
- What happens to a withdrawn passport? Is it retained for authorities while being removed from normal reads?
- Does it warn me if I issue a legally incomplete passport? Or does it let it through silently?
- What happens to my data if I switch providers? The passport URL belongs to the product, not the provider — we wrote about this separately in the article on switching providers.
Where does Veridyn stand?
Our system passes all 11 tests of the official BatteryPass-Ready conformance suite — repeated three times in a row so that luck does not decide — and can emit every mappable field of the official data model. The suite does not look at a file: it addresses the running system, over the same standard interface (the CEN-CENELEC JTC 24 lifecycle API, EN 18222) that the rest of the battery ecosystem uses.
You will find the machine interface described in the developer documentation, and you can see it working in the live demo, where the JTC24 document is downloadable. If you need to issue battery passports, start a free account.
We have put the numbers in one place — the 11 tests one by one, coverage of the official data model broken down by data group, the emitted profiles and a downloadable sample document — on our battery passport page.