The DPP criteria catalogue: requirements you can check

How the open repository dpp-criteria turns the ESPR and the harmonised standards into machine-checkable criteria – what a criterion contains, which tool checks it, where each requirement comes from, and how anyone can contribute.

For DPP service providers, developers, standardisation and compliance experts Last reviewed 16 October 2026 6 min read

One criterion, one file: what applies, where it comes from, who is checked how, and the check itself.

In short

• dpp-criteria is an open repository that writes the requirements of EU law and the DPP standards down as machine-checkable criteria – one file each, with the exact clause it comes from.
• The repository checks nothing itself. The DPP Linter applies the passport criteria, the DPP Service Validator the service criteria.
• Besides the criteria it lists data points: what each EU legal act requires or allows in a passport, and who may see it.
• Anyone can propose a criterion by pull request. It counts in results only after review.
• Licence: Apache 2.0. Statements paraphrase their sources; no text from licensed standards is copied.

Why a catalogue

The requirements for Digital Product Passports are spread across the Ecodesign Regulation, its delegated acts, product regulations such as the Battery Regulation and eight European standards. Each says something about identifiers, data models, APIs, security or access – in prose, and often in different words for the same thing.

A criteria catalogue turns that prose into short, testable statements: this must hold, here is where it comes from, and this is how to check it. Because the catalogue is open, every result of the linter and the validator can be traced back to a rule anyone can read, question and improve.

What is in the repository

Folder	Content
criteria/	the criteria, one YAML file each, grouped by area – identifiers, data model, API, data exchange, security, access and others
datapoints/	the data points EU legal acts require or allow in a passport – for reference, not checked
services/	one entry per DPP service in the daily checks
soya/	the SOyA structure with the SHACL shapes the passport is checked against
schema/	JSON Schemas for criteria, data points and service entries
tests/	test vectors for the schemas, the shapes and the path expressions
scripts/	tools that render the readable overviews and test the structures

Every file is checked against its JSON Schema whenever something changes, so a malformed criterion never reaches the tools.

A criterion in four parts

The picture at the top shows criterion DPP-ID-001: the product identifier resolves to its passport.

1. What applies. The statement says in one or two sentences what must hold, paraphrasing the source. level is MUST, SHOULD or MAY.
2. Where it comes from. basis names each legal act or standard, the exact clause and the kind of source.
3. Who and how. target says what is checked – a published passport, a DPP service, or the economic operator. method says how: automatically from the public internet, automatically with test credentials from the operator, or by self-declaration.
4. The check. check names one of nine check types and its parameters. catalogue_ref lists the rows of the requirements catalogue the criterion covers – several rows that lead to the same check share one criterion, so a requirement is never counted twice.

A criterion keeps its ID for good; a deleted ID is never reused. When its meaning changes, its version goes up.

The criteria in numbers

State of 16 October 2026. The target decides which tool runs a criterion.

Check type	What it does
http	calls the API, checks status codes and the JSON returned
shacl	validates the passport against SOyA shapes – the data model of EN 18223 and the identifiers of EN 18219
resolve	requests the product identifier like a phone that scanned the code
tls	checks the certificate, the TLS versions and the HTTP versions
proof, did	verifies integrity proofs and the passport’s hash; resolves and checks DIDs
links, html	follows linked resources; checks that the readable view loads nothing from elsewhere
declaration	records a self-declaration with a link to evidence – never shown as passed

Each check type is implemented exactly once in the tools. A proposal that needs a new kind of check adds it to the tool in the same pull request.

Every requirement names its source

Kind of source	Meaning
regulation	an EU regulation, such as the ESPR or the Battery Regulation
harmonised-standard	a standard cited in the Official Journal, which gives a presumption of conformity
standard	any other published standard – including EN 18239 and EN 18246 until they are cited
draft-standard	a standard not yet published
guidance	official guidance, such as Commission guidance documents
derived	an engineering conclusion from the other sources – never the only basis of a MUST

Clauses refer to the published 2026 editions of the standards. When a standard is cited in the Official Journal, its entries change from standard to harmonised-standard.

From proposal to result

New criteria arrive as pull requests with the status proposed. A maintainer reviews them and sets them to active. Only active criteria count in the “N of M automated checks passed” that the tools report; proposed ones are shown separately so everybody can see what is coming.

Each check ends as passed, warning, failed or skipped. A skipped criterion always carries a reason – not applicable, not implemented, no evidence, needs credentials, not sent, unreachable or not evaluated – and never counts.

The results are automated checks. They are not a certification and do not establish a presumption of conformity.

Data points: what goes into a passport

Criteria ask whether a service or a passport works as the standards require. Data points ask a different question: what content does an EU legal act require or allow in a passport? They are not checked; they are the reference from which product-specific criteria can be derived.

Each data point names the term used in the legal act, a paraphrased description, the attribute of EN 18223 where one exists, who provides it, how binding it is (tier, from fixed in every passport to voluntary), who may see it (access) and its source with clause.

State of 16 October 2026. The battery data points follow the Commission's guidance document on the battery passport, version 2.0 of 15 August 2026.

One number stands out: for 61 of the 229 data points, only a future delegated act will decide whether they are public or restricted to certain readers. Anyone building passport systems today has to keep access levels flexible – which is why the DPP Service classifies data per attribute instead of hard-coding who sees what. See Role-based access to passport data.

How to contribute

• Propose a criterion – as a pull request; it enters as proposed.
• Add data points – for legal acts or product groups not yet covered.
• List your DPP service – so it is checked every day like any other; see the DPP Service Validator.

The numbers in this article reflect the repository on 16 October 2026. The catalogue grows with every merged pull request; the readable overviews in the repository always show the current state.

Read the catalogue – or improve it

Every criterion and data point is listed in readable form. New proposals are welcome as pull requests.

Browse the criteria The repository

Further reading

• Criteria formatevery field, check type and result code
• Data pointswhat EU legal acts require or allow in a passport
• Data point formattiers, access classes and sources

Related articles

Tools

DPP Linter: check any passport against the standards

Enter the link from a product's QR code and see, criterion by criterion, whether its passport can be read, follows the EN 18223 data model, uses valid identifiers and can be checked for integrity. Free, open source, no account.

Tools

DPP Service Validator: daily, public checks of DPP services

Every listed DPP service is checked every day against open criteria – transport security, the EN 18222 API and protection against unauthorised changes – and the results are published for everyone to see.

Basics

Roadmap: when Digital Product Passports become mandatory

Batteries come first, then one product group after another. Which groups are planned when, what has been decided so far, and how a passport obligation comes about – as of October 2026.