Skip to content

What the EU's published definitions ask of your product data

The registry will not accept a passport whose data does not conform to the definitions the Commission publishes, which makes those definitions a gate rather than a reference library. For at least one product group the Commission's own user guide says the catalogue behind that gate is not defined yet, and registration therefore cannot succeed. That is worth knowing before anybody sells you a mapping project.

Sources as at
28 August 2026
Share
LinkedIn X Email
On this page

The short answer

Two provisions decide this and they should be read together. Article 12 of Commission Implementing Regulation (EU) 2026/1778 sets up a semantic repository, described in the text as "an authoritative and machine-readable source for the data models, semantic definitions and vocabularies applicable to digital product passports across all product groups". Article 11(3) then says that all data contained within a passport "shall be structured in accordance with the common data models and semantic definitions published in the semantic repository referred to in Article 12".

So the repository is not documentation you consult if you feel like it. It is the specification your data has to satisfy, and Article 8(7)(a) has the Commission confirm semantic conformity at the moment you submit.

The good news is that it costs nothing. Article 12(7) makes access to the repository and its APIs free of charge, Article 12(5) requires a search service so any user can read and retrieve the definitions, and Article 12(6) requires publicly documented APIs in common data formats. There is no licence, no membership and no fee.

The awkward news is that a repository can exist as a legal object before it contains anything useful for your product group, and that is where the system currently sits.

The gate nobody mentions

The Commission's user guide for economic operators, updated in August 2026, contains this sentence:

Successful registration of DPPs for batteries is not currently available, as the semantic catalogue for this product group has not yet been defined.

Set that beside the launch announcement from 20 July 2026, which says businesses "will have access to a free semantic repository providing machine-readable data models, definitions and vocabulary across product groups through documented APIs". Both statements are the Commission's. The second describes the facility. The first describes what happens when you try to use it.

The consequence is worth stating plainly, because it does not appear to have been drawn anywhere else. Batteries carry the first hard deadline named in the Commission's own announcement, 18 February 2027 for certain types of large battery. Batteries are also the product group the same Commission's guide says cannot currently be registered. A deadline and a gate are pointing at each other.

This is a statement about the position we found in August 2026, at the two Commission documents named above, rather than a prediction. A catalogue that does not exist in August can exist in October. What it establishes is the shape of the dependency: a registration duty for your product group is not operable until the semantic catalogue for your product group exists. Where any date on a duty sits, and what has actually been set rather than signalled, is kept on the status record rather than asserted here.

What the repository has to contain

Article 12(2) sets a floor of five things. Read as a list it looks administrative. Read as a specification it is more demanding than most product data models in commercial use.

What Article 12(2) of the registry implementing regulation requires the semantic repository to contain, and what each requirement means for a business holding product data.
What Article 12(2) requiresWhat it means for your data
The semantic meaning of each required attribute, and technical specifications for typed and resolvable links between passports and to underlying evidenceA field is defined by what it means, not by what it is called. And a value can be pointed at the thing that supports it
Data models for each product in scope, and their formatsStructure and serialisation are both fixed, not just the field list
Metadata about those data models, conformant with the DCAT-AP specificationsThe catalogue describing the models is itself machine readable to a published European profile
The semantic meaning of the roles set out in the applicable delegated actsWho an actor is becomes a defined term, not a label a system chooses
Multilingual labels and definitions for every mandatory attributeThe definition, not the English word, is the thing that travels

Article 11(4) adds that data models are versioned, which is the provision that will matter most in three years and is being ignored today. A mapping is not a one time project against a fixed target. It is a dependency on a moving specification.

Meaning is not field names

This is the part that decides whether a mapping project is two weeks or two quarters, and it is the part almost every plan underestimates.

Two systems can carry a field called material and mean different things by it. The estate works this problem in detail at where product data stops meaning the same thing, which is about two commercial systems quietly disagreeing. Mapping to a published European definition is the same problem pointed in a different direction, and it is harder in one specific way: there is no negotiation. Your system can be wrong about the definition and the definition cannot be wrong about your system.

Nine things break a mapping, and only the first is a naming problem.

  1. The name. Two labels for one concept, or one label for two.
  2. The meaning. Composition that includes trims against composition that does not.
  3. The format. A free text string where a coded value is required.
  4. The unit. Grams against kilograms, or a percentage by mass against a percentage by volume.
  5. The permitted values. A controlled vocabulary that does not contain the word your catalogue uses.
  6. The granularity. A value that is true of a model held against a passport registered per item.
  7. The applicability. An attribute that is mandatory for one product type inside a group and not for another.
  8. The identifier. The value is right and it is attached to the wrong thing.
  9. The provenance. The value is right and nothing records where it came from or how far the evidence behind it reaches.

The published battery material shows what several of these look like in practice. The Commission's battery data point list sets out numbered data points with a legal source reference and an applicability column per battery type, and at least one carries a controlled vocabulary: the status of the battery, expressed as original, repurposed, re-used, remanufactured or waste. A system holding that value as free text has a mapping problem it cannot see, because the field is populated and looks fine.

That document is a requirements table rather than a machine readable model. It carries no URIs, no datatypes, no cardinalities and no multilingual labels, which is to say it is not the thing Article 12(2) describes. It is the closest published thing to it, and the distance between the two is the work that has not been done yet.

Which of these failures each attribute is prone to, and how far the evidence behind a value actually reaches, is the subject of the attributes we track rather than of this page.

The provision worth reading twice

Article 12(2)(a) requires the repository to carry, alongside the meaning of each attribute:

technical specifications for creating, where relevant, typed and resolvable links between different digital product passports, and links between digital product passport attributes and underlying evidence communicated through the product value chain

Article 12(2)(a) requires the repository to carry, quoted verbatim.

That is a specification for pointing a value at the thing that supports it, expressed at the level of a shared vocabulary rather than one vendor's schema. A passport that asserts a recycled content figure and a passport that carries a resolvable link from that figure to the document behind it are different objects, and the difference is exactly the one this estate has been making since before the provision existed. How a value is typed, and what a blank means, is set out at how we know.

Two qualifications keep this honest. The provision says "where relevant", which delegates the decision. And a repository requirement is not a passport requirement: what any given product group's passport must actually carry is set by its own delegated act, not by Article 12. We did not find a delegated act making use of the linking limb.

What is published, and what is not

Three dependencies underneath the repository are less settled than they look.

The repository itself. We tried to reach it. The registry hosts return an application shell to any path without executing JavaScript, the Commission's DPP pages publish a user guide and a battery data point list and no API documentation, and the user guide states that access runs through EU Login. We did not find a published API reference, an OpenAPI document, a search endpoint or a downloadable data model as at 28 August 2026. That is a statement about where we looked.

DCAT-AP. Article 12(3) requires the model metadata to conform to "the DCAT-AP specifications" without naming a version. DCAT-AP is a European application profile of the W3C data catalogue vocabulary, maintained under the Commission's own semantic interoperability work, and it is itself versioned and currently moving. An unversioned pointer to a versioned specification is a small ambiguity now and a larger one later.

The standards. Eight European standards for digital product passports were developed with CEN and CENELEC. Six references are cited in the Official Journal by Commission Implementing Decision (EU) 2026/1736, covering data exchange protocols, unique identifiers, data carriers, storage and archiving, lifecycle APIs and system interoperability. The two that are not cited are the ones covering access rights management with information system security and business confidentiality, and data authentication with reliability and integrity. Published is not the same as cited, and only a cited reference carries a presumption of conformity, which is worked through at which passport standards carry a presumption.

What to do now

The useful work here is cheap, and the expensive work is premature.

  1. Read your own catalogue against the definitions that exist. For a product group with a published data point list, walk it attribute by attribute and mark each one as matching, mismatched or unknown. That exercise costs an afternoon and tells you the size of the problem.
  2. Find your controlled vocabulary problems first. They are the failures that look like success. A populated free text field where a coded value is required passes every internal check you have.
  3. Do not commission a mapping build against a catalogue that does not exist. For a product group whose semantic catalogue is undefined, there is nothing to map to, and a vendor quoting for the work is quoting against an assumption.
  4. Ask any vendor which version. Data models are versioned under Article 11(4). A proposal that does not name a version has not thought about the second year.
  5. Record provenance now, whatever the schema turns out to be. Where a value came from survives every remapping. A value with no history has to be re-established each time the target moves.

None of this depends on which way the specification settles, which is the test worth applying to any registry work offered to you this year. The architecture that all of it sits inside, and what the registry actually holds against what stays with you, is set out at where your passport data actually lives.

You might want to read next

Since you have read this, these may answer the questions that usually come next.

Sources

Worth sharing?

Help someone else make sense of product passports.

LinkedIn X Email