Compliance map
How this platform meets the EU rules
Requirement by requirement, from the ESPR, the Battery Regulation, the registry implementing regulation, the harmonised EN 182xx standards and the data models. Statuses are checked against the code in this repository. Where something is a mock or left to contracts, it says so.
36 × Implemented4 × Implemented (mock registry until EU credentials)22 × Partial1 × Not implemented2 × Waiting for the EU model4 × Out of scope (legal/contractual)
What's new from the Commission (30 Oct 2026)
- Registry API published as OpenAPI 3.1: async submissions per product group and sub-group, task polling, idempotency keys. Implemented in
packages/eu-dpp/src/registry.tsand mirrored by the local mock at/mock-registry. - Service-account authentication:
private_key_jwtclient assertions signed with ES256, exchanged for an access token. Implemented; real use needs a verified organisation with EU Login and an uploaded public key. - Self-hosted endpoint rules: no
Authorization→ public view (200); a valid registry token → public + protected views; an invalid token → 401, never the public fallback; wrong scope or requestor → 403; alwaysVary: Authorization. Implemented in the resolver. - Battery semantic model 1.0.0: JSON Schema, SHACL and JSON-LD per view (public, Restricted 1–3) and per sub-group. The platform validates with the JSON Schemas and serves a JSON-LD context; SHACL shapes are not used.
- Data points v3.2: per-category obligations (EV / LMT / industrial). Read from the vocabulary scope notes and exposed by the field API that drives the dashboard forms.
A. ESPR — Regulation (EU) 2024/1781
| # | Requirement | Source | How this platform does it | Status | See it |
|---|---|---|---|---|---|
| A1 | DPP connected through a data carrier to a persistent unique product identifier | ESPR Art. 10(1)(a), 2(30) | Each passport gets a GS1 Digital Link UPI (/01/{GTIN-14}/21/{serial}, /10/{lot} or model-level /01/{GTIN}) on the platform's resolver domain (PLATFORM_URL). The QR code encodes the UPI. | Implemented | Demo passport |
| A2 | Carrier and UPI comply with ISO/IEC 15459 / EN 18219 / EN 18220 | ESPR Art. 10(1)(c), Annex III | GTIN check digit and GS1 AI 21/10 syntax (CSET 82, max 20 chars) are validated on issue (packages/eu-dpp/src/identifiers.ts). GS1 is an ISO/IEC 15459 issuing agency. QR at error-correction level Q, no logo, human-readable (01)…(21)… printed under it. | Implemented | Demo passport |
| A3 | Open, interoperable, machine-readable, structured, searchable, no lock-in | ESPR Art. 10(1)(d), 11(a) | Data is the Commission's compact JSON with typed values (unit URIs, vocabulary URIs). The UPI serves JSON (?format=json or Accept: application/json), a JSON-LD context, the signed VC and a GS1 linkset. Lookup by UPI: GET /api/v1/dpps/lookup?upi=. Search: GET /api/v1/dpps?q=. | Implemented | Public JSON |
| A4 | No customer personal data without explicit consent | ESPR Art. 10(1)(e) | Passports carry product data only; there is no field for an owner or end user. Personal data the platform does hold: names and e-mails of access requesters, and the IP address of restricted-view reads in the access log. No retention period is configured for those yet. | Partial | |
| A5 | Model, batch or item level | ESPR Art. 10(1)(f) | Granularity model, batch or item per passport. Model-level data points live on the product and are inherited by every batch and item passport. | Implemented | Batch passport |
| A6 | Access regulated per actor | ESPR Art. 10(1)(g), 11(b) | Four views (public, Restricted 1–3) with fixed role → view rules (ROLE_VIEWS). Authorities and notified bodies are verified by a platform admin; legitimate-interest parties need an approved grant per operator or per passport, with optional expiry. | Implemented | Demo passport |
| A7 | Write rights restricted by access rights | ESPR Art. 11(f) | Only members of the operator's organisation or its API keys can write. API keys have scopes (read, write, dynamic, admin); a dynamic key may write only the data points listed on the key (e.g. the BMS key). | Implemented | API example |
| A8 | Stored by the operator or a DPP service provider | ESPR Art. 11(c) | The organisation profile stores the written authorisation (file + scope) for the platform to act as service provider. Whether the contract exists is a legal matter. | Partial | Dashboard |
| A9 | New passport linked to the original | ESPR Art. 11(d) | POST /api/v1/dpps/{id}/successor issues a new passport with predecessorId, marks the original superseded (dppStatus invalid) and links both ways in the viewer. | Implemented | Successor passport |
| A10 | Authentication, reliability, integrity | ESPR Art. 11(g) | Every version is a W3C VC signed with the operator's Ed25519 key (eddsa-jcs-2022, issuer did:web). Restricted views are bound to the VC by salted SHA-256 digests. Events are hash-chained; versions and events tables are append-only (database triggers). The viewer re-verifies all of it on each request. | Implemented | Demo passport |
| A11 | High security and privacy, fraud avoided | ESPR Art. 11(h) | Restricted views AES-256-GCM encrypted at rest; signing keys encrypted at rest; access keys and API keys stored as SHA-256 hashes; restricted reads logged. Gaps: one platform-wide encryption key (no per-organisation keys or HSM), no rate limiting on public reads. | Partial | |
| A12 | Available for the set period, including after insolvency | ESPR Art. 9(2)(i), 11(e) | Passports cannot be deleted (API returns 409); every version is replicated to a backup target and can be exported. The escrow of the decryption key and the hand-over agreement with a backup provider are contractual. | Partial | |
| A13 | Backup copy through an independent DPP service provider | ESPR Art. 10(4), 27(1), 29(2), Annex III(l); EN 18221 §4.5 | Each version (public view, signed VC, encrypted restricted views) is written to an S3-compatible bucket or a separate volume; the reference is stored on the passport and shown in the viewer. The demo writes to a local replica directory; choosing an independent provider is contractual. | Partial | Demo passport |
| A14 | Provider must not reuse or process data beyond the service | ESPR Art. 11; BR Art. 78(d) | The platform runs no analytics on passport data and does not log public reads. The binding commitment belongs in the data processing agreement. | Out of scope (legal/contractual) | |
| A15 | Operator and facility identifiers | ESPR Art. 12(2)–(3) | Typed EORI and LEI fields on the operator profile (format-checked); registry organisation identifier stored. Facility identifiers (GLN) are not modelled; place of manufacture is the EU model's city/region/country. | Partial | Dashboard |
| A16 | Digital copy of the carrier, or link, for online sellers | ESPR Art. 10(3) | QR as PNG (/dpp/{id}/qr.png, 1024 px) and SVG, the UPI, and a GS1 linkset are public endpoints. | Implemented | QR PNG |
| A17 | Annex III content (GTIN, commodity code, DoC, operator IDs, EORI, backup reference) | ESPR Annex III | GTIN, EU declaration of conformity (related resource), EORI/LEI and backup reference are present. TARIC commodity code is not a field yet. | Partial | Demo passport |
B. Battery Regulation — Regulation (EU) 2023/1542
| # | Requirement | Source | How this platform does it | Status | See it |
|---|---|---|---|---|---|
| B1 | Passport for LMT, industrial >2 kWh and EV batteries from 18 Feb 2027 | BR Art. 77(1) | Products carry a sub-group (evb, lmt, ind) that selects the Commission schemas, the battery category and the per-category obligations. | Implemented | Field catalogue (JSON) |
| B2 | QR code linking to an ISO/IEC 15459 unique identifier | BR Art. 77(3), 13(6); EN 18220 | QR encodes the GS1 Digital Link UPI; level Q; no logo; human-readable identifier below. Minimum print size per EN 18220 is the label designer's job. | Implemented | QR PNG |
| B3 | Access tiers: public (Annex XIII 1); legitimate interest + Commission (2); notified bodies, MSA + Commission (3); legitimate interest, per battery (4) | BR Art. 77(2), Annex XIII | The view of each data point comes from the Commission schemas, so tiers cannot be misconfigured. Views: pub, res1, res2, res3 exactly as in Annex XIII. | Implemented | Demo passport |
| B4 | Free access by right; write rights limited by tier | BR Art. 78(b), (f) | Reads are free. Authorities get access keys after verification; legitimate interest is self-service (request form on every passport) with operator approval. The Art. 77(9) act defining legitimate interest is not adopted, so the approval stays manual. | Implemented | Demo passport |
| B5 | Authentication, integrity, security, anti-fraud; key management | BR Art. 78(g), (h) | Per-organisation Ed25519 signing keys, revocation via a W3C Bitstring Status List, signature and digest checks in the viewer. Key rotation adds a new active key; old keys stay stored, so earlier versions keep verifying. Keys are encrypted at rest, not in an HSM. | Partial | Demo passport |
| B6 | Authorities can reach restricted data without special software | BR Art. 77(2)(b), 78(b) | An access key in any browser (viewer form) or as Authorization: Bearer dppa_… on the JSON endpoint. Platform admins register and verify authority parties. | Implemented | Demo passport |
| B7 | Operator ensures accuracy; may authorise another operator in writing | BR Art. 77(4) | Authorisation document and scope stored on the organisation; every change records the actor. | Partial | Dashboard |
| B8 | Open, interoperable, machine-readable, no lock-in | BR Art. 77(5), 78(a) | As A3, plus GET /api/v1/dpps/{id}/export: full document with decrypted restricted views, every version and the event chain. | Implemented | API example |
| B9 | Annex XIII point 1 content | Annex XIII 1(a)–(s) | Validated against the Commission JSON Schemas for each sub-group; mandatory/optional per category from the vocabulary scope notes (GET /api/v1/schema/batteries/{sg}/fields). | Implemented | Field catalogue (JSON) |
| B10 | Point 2: detailed composition, spares, dismantling, safety | Annex XIII 2 | Restricted 1 view, encrypted at rest; documents can be uploaded and are gated by view. | Implemented | Demo passport |
| B11 | Point 3: test reports, authorities only | Annex XIII 3 | Restricted 2 view: notified bodies, market surveillance, Commission. | Implemented | Demo passport |
| B12 | Point 4: per-battery dynamic data (SoH, status, cycles, negative events, temperature, SoC) | Annex XIII 4; BR Art. 14 | Restricted 3 view. Written by the operator or a delegated key limited to named data points; each write is a signed version plus an event. | Implemented | Demo passport |
| B13 | Repurposed or remanufactured battery gets a new passport linked to the original | BR Art. 77(7) | Successor flow with battery status from the EU vocabulary (repurposed / remanufactured / reused). Hand-over to a different operator organisation is not built: the successor is issued by the same organisation. | Partial | Successor passport |
| B14 | Passport ends after recycling | BR Art. 77(8) | POST /api/v1/dpps/{id}/end-of-life: battery status Waste, dppStatus invalid, read-only, kept. | Implemented | Recycled battery |
| B15 | Available after the operator ceases | BR Art. 78(e) | As A12. | Partial | |
| B16 | Provider does not sell or reuse data | BR Art. 78(d) | As A14. | Out of scope (legal/contractual) | |
| B17 | Due diligence information | Annex XIII 1(d); Art. 48 | Not in the Commission battery model 1.0.0. Added when the semantic repository publishes the data points. | Waiting for the EU model | |
| B18 | Carbon footprint declaration | BR Art. 7, Annex XIII 1(a)–(c) | Not in model 1.0.0 (the calculation and format acts are pending). Same as B17. | Waiting for the EU model | |
| B19 | Upload the unique identifier to the registry | BR Art. 77(10) | POST /api/v1/registry/submissions submits UPIs per sub-group, polls the async task and stores the registry ID on each passport. Runs against a local mock of the Commission API until the organisation has EU service-account credentials. | Implemented (mock registry until EU credentials) | Dashboard (registry) |
C. Registry — Implementing Regulation (EU) 2026/1778
| # | Requirement | Source | How this platform does it | Status | See it |
|---|---|---|---|---|---|
| C1 | Register through the registry UI or API at the right level | IR Art. 8(1), (2), (6) | API client (packages/eu-dpp/src/registry.ts): private_key_jwt client assertion (ES256), token exchange, idempotent submission, task polling with the guide's back-off. Item, batch and model granularity sent per item. | Implemented (mock registry until EU credentials) | Dashboard (registry) |
| C2 | Third-party registration: Union-law basis, verification, client stays responsible | IR Art. 8(2), 19(4), 6(1) | Written authorisation stored per organisation. Qualified e-seal / EU Login verification of the platform as a registrant is not set up. | Partial | |
| C3 | https UPI, max 2000 characters, resolving to the hosted DPP | Registry user guide v1.03 | UPIs are short GS1 paths on PLATFORM_URL (https in production) and resolve to the passport. The local demo runs on http. | Implemented | Demo passport |
| C4 | Semantic conformity to the semantic repository | IR Art. 8(7), 11(3), 12 | Vendored Commission schemas, vocabularies and test instances (model 1.0.0); every write is validated (Ajv, JSON Schema 2020-12) and refused with the EU error codes. The mock registry re-validates what the resolver returns. | Implemented | Field catalogue (JSON) |
| C5 | Registration identifier | IR Art. 6a, 8(8) | Registry ID stored per passport and shown in the viewer's verification panel. | Implemented (mock registry until EU credentials) | Dashboard (registry) |
| C6 | Proof of registration | IR Art. 8(9) | Each submission is stored with the full task outcome; a registered event is appended to the passport's chain. | Implemented (mock registry until EU credentials) | Dashboard (registry) |
| C7 | Updates and versioning | IR Art. 9 | A change to a registered passport sets it to update pending. Re-submission is manual; no automatic registry update call yet. | Partial | Dashboard (registry) |
| C8 | Transfer of responsibility | IR Art. 10 | Not implemented (no operator-to-operator transfer, in the platform or in the registry). | Not implemented |
D. Harmonised standards — EN 182xx (Decision (EU) 2026/1736)
| # | Requirement | Source | How this platform does it | Status | See it |
|---|---|---|---|---|---|
| D1 | Unique identifiers: approved scheme, never reassigned, persistent | EN 18219 §4–5 | GS1 Digital Link; a UPI that exists is never issued again (409); passports are never deleted. | Implemented | Demo passport |
| D2 | Data carrier: QR per ISO/IEC 18004, readable by a stock phone, human-readable ID | EN 18220 | As B2. | Implemented | QR PNG |
| D3 | Exchange protocols and formats | EN 18216 | HTTPS + JSON, JSON-LD context, W3C VC, GS1 linkset, content negotiation on the UPI. Not yet checked clause by clause against EN 18216. | Partial | Public JSON |
| D4 | Archiving: no silent overwrite, persistence, replication | EN 18221 | Append-only versions (database trigger), each replicated; any version readable at /dpp/{id}/versions/{n} (public part) or via the API by number or date. | Implemented | Version 1 |
| D5 | Life-cycle API (ReadDPPById, ReadDPPByProductId, ReadDPPVersionByIdAndDate, CreateDPP, UpdateDPPById, …) | EN 18222 | All of these operations exist under /api/v1/dpps (paths are the platform's own). DeleteDPP is refused by design. | Implemented | API example |
| D6 | Interoperability model: JSON (Annex A), XML (Annex B) | EN 18223 | Output is the Commission's compact JSON, which the registry requires. No EN 18223 XML serialisation. | Partial | Public JSON |
| D7 | Access rights, revocation, transfer | EN 18239 (not harmonised) | Grants with approve / deny / revoke and optional expiry. Access-party keys have no revoke action yet. Transfer between operators: see C8. | Partial | Dashboard |
| D8 | Signed data, anti-scraping, anti-phishing | EN 18246 (not harmonised) | Signed VC per version, verification shown to the reader. No rate limiting or bot protection on the resolver yet. | Partial | Signed VC |
E. Data models
| # | Requirement | Source | How this platform does it | Status | See it |
|---|---|---|---|---|---|
| E1 | Attribute metadata (access level, type, unit, obligation) | DIN DKE SPEC 99100 | The field catalogue carries view, type, default unit, obligation per category, Annex reference and definition for every data point, taken from the Commission model. | Implemented | Field catalogue (JSON) |
| E2 | Battery Pass data model mapping | github.com/batterypass | Superseded for registry purposes by the Commission model 1.0.0, which this platform uses directly. No Battery Pass crosswalk. | Out of scope (legal/contractual) | |
| E3 | Commission data points per category | Commission guidance (data points v3.2) | Obligations per EV / LMT / industrial come from the vocabulary scope notes shipped with model 1.0.0. | Implemented | Field catalogue (JSON) |
| E4 | Textile DPP | JRC draft, May 2026 | Not in scope; the identifier, access, versioning and registry parts are product-agnostic. | Out of scope (legal/contractual) | |
| E5 | Core DPP plus an append-only signed life-cycle log | JRC145830 Annex 9 | Typed events (soh_reading, repair, maintenance, inspection, incident, transfer, note, issued, superseded, end_of_life, registered) in a SHA-256 hash chain; each data change is a signed version. | Implemented | Demo passport |
F. Engineering
| # | Requirement | Source | How this platform does it | Status | See it |
|---|---|---|---|---|---|
| F1 | Persistence if the provider disappears | A12 | As A12. | Partial | |
| F2 | Identifier scheme and resolver | A1 | GS1 Digital Link resolver on a configurable domain the operator can point elsewhere. | Implemented | Demo passport |
| F3 | QR generation | B2 | As B2. | Implemented | QR PNG |
| F4 | Versioning and audit trail | Signed versions, hash-chained events, access log of restricted reads. | Implemented | Demo passport | |
| F5 | Access control, encryption per role, key management | Role-based views, encrypted restricted data, signed digests. One encryption key for the platform; per-tier keys and HSM not built. | Partial | ||
| F6 | Personal data / GDPR | A4 | As A4. | Partial | |
| F7 | API (REST, JSON-LD) | REST JSON under /api/v1, session or API-key auth; JSON-LD context for the passport vocabulary. | Implemented | API example | |
| F8 | Export | As B8. | Implemented | API example | |
| F9 | Multilingual | Viewer interface in 7 languages (en, de, fr, es, it, pl, nl), multi-language data values shown in the reader's language when present. Field labels come from the Commission vocabulary, in English only. | Partial | Viewer in German | |
| F10 | Schema validation | As C4: all four views validated on every write. | Implemented | Field catalogue (JSON) | |
| F11 | Accessibility of the passport page | Built to WCAG 2.1 AA (landmarks, contrast, focus states, labelled forms, no colour-only status, light/dark, print). No external audit yet. | Partial | Demo passport | |
| F12 | Template changes must not affect old passports | Each version records its contentSpecificationIds (model 1.0.0) and is signed; a new model release does not rewrite old versions. | Implemented | Version 1 |
Requirement IDs and wording follow an earlier independent audit framework (A ESPR, B Battery Regulation, C Registry IR, D standards, E data models, F engineering). Standards marked "contents" or "not harmonised" were assessed from their published scope. Last reviewed 9 Nov 2026.