Prove It: DPP Conformance Testing Is Live on the EU Test Bed

Here is a link. Open it, drop a Digital Product Passport into the form, and get a verdict:

https://www.itb.ec.europa.eu/shacl/openepcis/upload

It runs on European Commission infrastructure. It is free, it needs no account, and there is no vendor in the middle. It tells you whether a passport conforms to the OpenEPCIS DPP-Ready shapes, with the same engine, the same shapes and the same verdict for everyone who asks.

The useful part is the independence: a claim about a passport can now be settled by a machine that belongs to neither side of the conversation.

A specification nobody can check is a PDF with ambitions

The DPP space has no shortage of models. Everyone has a data model, a profile, an alignment, a mapping table, a slide with boxes and arrows. What almost nobody has is the boring half: a way for a third party to take a document, hand it to a machine neither side controls, and get back an answer that both sides accept.

Without that, "we support the standard" is a statement of intent. Intent is where interoperability projects go to die, slowly, in a meeting where two implementers are each right about different things and nobody can show it.

Once the check exists, a few things get cheaper for everyone. The supplier runs the file instead of arguing about it. The buyer can point at a validation type instead of writing bespoke acceptance criteria into a contract. The solution provider avoids a bilateral test cycle with every single customer, which is a cost that rarely appears in a business case and is paid anyway. One upload replaces a correspondence.

Keep the two words straight, because they get mixed constantly. Compliance is meeting a regulatory requirement, the ESPR or the Battery Regulation. Conformance is adhering to a published specification. A validator can only ever give you the second. It is still the half that makes the first tractable, because a regulator, an auditor or a customer asking "does this passport carry what it must" needs a repeatable answer, and repeatable answers come from machines running published rules.

Why it is open

A conformance check that is closed puts whoever runs it in the position of deciding what passes, and whoever charges for it in the position of deciding who gets to ask. For a check tied to public regulation, that seems like the wrong arrangement, and it falls hardest on the companies with the least slack: the small manufacturer, the supplier three tiers down, the project that just wants to interoperate.

Three properties follow from that, and you can verify all three today.

The rules are readable. Every constraint the validator applies is published as SHACL in a public repository, derived from published ontologies. When your passport fails you get the constraint, the node and the reason, so you can read the shape that rejected you and disagree with it.

The verdict is not ours to give. We wrote the shapes and we do not operate the service that applies them. The European Commission does, on its own infrastructure, with its own off-the-shelf validator. We cannot make a passport pass, and neither can anyone else. That separation is the reason for using the Test Bed rather than hosting this ourselves.

It costs nothing and asks nothing. No account, no registration, no usage tier. Upload a file, read the report, close the tab.

The shapes are Apache-2.0, the bundle sits in a repository anyone can fork, and the validator image is a standard Commission artifact, so none of this depends on OpenEPCIS continuing to exist.

What it actually validates

Sixteen validation types. Pick the one that matches your passport:

• dpp.core for the cross-cutting ESPR core
• one per regulation module: battery, textile, electronics, detergent, EUDR, packaging, construction products, the ESPR iron and steel product group, and US FSMA §204
• eu.battery.model, .batch and .item for the three EN 18223 granularity levels, because obligations genuinely differ by level. A model passport has no serial number. An item passport resolves model and party identifiers up the Digital Link hierarchy instead of restating them.
• eu.battery.ev, .lmt and .industrial for the EC battery passport category guidance

Submit JSON-LD, Turtle, RDF/XML or N-Triples. There is a web form, a REST API and a SOAP endpoint, the last one being what the Test Bed's own test engine speaks. The REST API is the interesting one for you, because it turns conformance into a build step:

curl -s -X POST https://www.itb.ec.europa.eu/shacl/openepcis/api/validate \
  -H 'Content-Type: application/json' \
  -d "{\"contentToValidate\":\"$(base64 < my-passport.jsonld | tr -d '\n')\",
       \"embeddingMethod\":\"BASE64\",
       \"validationType\":\"eu.textile\",
       \"contentSyntax\":\"application/ld+json\",
       \"reportSyntax\":\"application/json\"}"

Put that in your pipeline and your passports stop drifting. A sh:Violation fails you. Warnings and info results are reported and tolerated, deliberately, because the conditional and optional data points of the EC readiness shapes live at those severities and a gate that failed on them could never go green.

The interesting part: what a hosted validator cannot do

This is where it stops being a deployment story and becomes an engineering one. Our shapes are authored against the ontologies, layered the way the vocabulary is layered. A stock hosted validator cannot run them as authored, and we measured three reasons rather than guessing at them.

It applies no RDFS entailment. The module ontologies specialise core properties with rdfs:subPropertyOf, and the core shapes state the obligation on the superproperty. Nothing in the delivery chain applies that axiom, so a document stating only the specialised property comes back non-conformant. The bundle is therefore rewritten into plain SHACL Core: every such path becomes an sh:alternativePath over the property and its specialisations, and targets are extended the same way. The authored shapes stay layer-clean, and the published bundle needs no reasoner.

It cannot flip sh:deactivated per request. The granularity and category shapes ship deactivated and get activated one set at a time, which is impossible per request on a hosted service. So the generator emits one pre-activated copy per validation type. That is why three battery granularity levels are three types rather than one type with a switch.

It needs the class hierarchy in the data graph. sh:class and the subclass resolution behind sh:targetClass are evaluated over the data, and the hierarchy plus the code-list individuals live in the ontology. Every type therefore ships a background.ttl, which the validator merges in before validating. Without it the shapes are vacuous in one direction and wrong in the other.

None of that is visible when you upload a file, which is the point. It is also why the bundle is generated from the ontologies on every build rather than hand-maintained, with a drift gate that fails the build when the two disagree.

How we know the shapes are not empty

A validator that says SUCCESS to everything is worse than no validator, and from the outside it looks identical to a good one. So the suite proves the negative case too.

Every reference passport we publish, 46 of them, goes through the real Commission validator image on every run. Alongside them run 73 test suite fixtures, of which 27 are deliberately broken, each derived from a correct passport by exactly one documented mutation: a granularity mismatch, a missing economic operator role, an out-of-range fraction, a missing required property read straight out of the shapes. Every one of them must fail. If an upstream change ever makes a mutation stop violating, the build goes red instead of the suite quietly asserting nothing.

The full chain, green

The validator is the half you can use today. The other half went live alongside it: the OpenEPCIS community on the Test Bed, where a conformance statement gets recorded against a specification rather than merely computed.

Sixteen specifications, one per validation type. The DPPDataProvider actor under each. The GITB test suite deployed as a shared suite and linked to all sixteen, 32 test cases in total. A system under test carrying sixteen conformance statements for the reference passports we publish.

Then we pressed go on all sixteen self-tests:

dpp.core                 SUCCESS
eu.battery               SUCCESS
eu.battery.model         SUCCESS
eu.battery.batch         SUCCESS
eu.battery.item          SUCCESS
eu.battery.ev            SUCCESS
eu.battery.lmt           SUCCESS
eu.battery.industrial    SUCCESS
eu.cpr                   SUCCESS
eu.detergent             SUCCESS
eu.electronics           SUCCESS
eu.eudr                  SUCCESS
eu.iron-steel            SUCCESS
eu.ppwr                  SUCCESS
eu.textile               SUCCESS
us.fsma204               SUCCESS

16/16

Every link in that chain belongs to someone else. The Commission's test engine calls the Commission's hosted validator over the public internet, loads our shapes, fetches our contexts from ref.openepcis.org, validates our published passports, and separately insists that the deliberately broken ones fail. Nothing in that sentence runs on our laptops.

The community is provisioned from the repository too, by a script that reads the same configuration the validator serves, so rebuilding it is one command and the Test Bed cannot quietly drift away from the shapes.

Open, and it updates itself

The validator configuration lives in its own public repository:

https://github.com/openepcis/validator-resources-openepcis

Apache-2.0, the shapes and the configuration exactly as the Commission serves them. It is a mirror, generated from openepcis-dpp-ready where the ontologies are the source of truth, and a webhook redeploys the live service within a couple of minutes of a push. Shapes improve, the public validator follows, with no release dance.

One honest caveat: the Test Bed UI runs Monday to Friday, 05:00 to 20:00 CET, and carries no SLA, so treat it as what it is, a shared public good, used fairly. The validator itself answers around the clock.

What you can use, and what would help us

Three things are available, and none of them need a conversation with us first.

The validator. For your own passports, in your pipeline, in a procurement checklist, or in a workshop where two parties read the same requirement differently.

A conformance statement. The community on the Test Bed is set up. If you would like your system recorded as conforming to one of the sixteen specifications, get in touch and we will add you as an organisation in it.

A regulation we do not cover yet. If your product group is missing and you can bring the requirements, we will model it in the open, with the same layering, shapes and tests as the existing modules.

What would help us most is the opposite direction: finding out where the shapes are wrong.

Sixteen green results show that our passports satisfy our own reading of the regulations. That reading can be mistaken, and we will not discover it from our own examples. The interesting cases are real passports from real products, built by people who read the ESPR, a sectoral regulation or the EN 182xx series differently than we did.

So if the validator rejects something you believe is correct, please open an issue on openepcis-dpp-ready with the document and the report. The same goes for a shape that accepts something it should reject, a confusing label, a missing validation type, or a disagreement with the granularity model. Those reports are the main way the shapes improve, and there are only so many passports we can think of on our own.

Thanks to the Interoperability Test Bed team, who onboarded the project, host the validator and answered a long list of questions. A free, Commission-operated conformance service is a good thing for this field to have, and it is worth using.