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

Source: https://activatedigital.ai/knowledge/guides/mapping-to-the-eu-definitions
Last verified: 28 August 2026
Summary: 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 isn't defined yet, so registration can't succeed. Know that before anybody sells you a mapping project.

## In 60 seconds

Two provisions decide this and they should be read together. Article 12 of [Commission Implementing Regulation (EU) 2026/1778](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202601778) 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) requires all passport data to be structured to the semantic repository's models, and Article 8(7)(a) has the Commission confirm semantic conformity at submission.
- Access is free: Article 12(7) makes the repository and its APIs free of charge.
- User Guide v1.03, checked **7 October 2026**, says successful Battery DPP registration is not yet available because the Battery semantic catalogue is not defined.
- Data models are versioned under Article 11(4), so a mapping depends on a moving specification.
- Implementing Decision (EU) 2026/1736 cites six DPP standards. The two on access rights and data authentication are not cited.
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](https://single-market-economy.ec.europa.eu/document/download/079a45e2-469f-4eec-b1e5-32e8e05d1357_en?filename=dpp_registry_user_guide_for_economic_operators.pdf), 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](https://single-market-economy.ec.europa.eu/news/digital-product-passport-registry-now-live-2026-07-20_en) from [20 July 2026](https://activatedigital.ai/knowledge/digital-product-passport/timeline), 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.

This consequence doesn't 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 been set rather than signalled, is kept on the [status record](https://activatedigital.ai/knowledge/status/textile-passport) 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) requires | What 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 evidence | A 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 formats | Structure and serialisation are both fixed, not just the field list |
| Metadata about those data models, conformant with the DCAT-AP specifications | The 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 acts | Who an actor is becomes a defined term, not a label a system chooses |
| Multilingual labels and definitions for every mandatory attribute | The 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 part decides whether a mapping project is two weeks or two quarters, and almost every plan underestimates it.

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](https://activatedigital.ai/knowledge/guides/what-does-not-map), 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.

- **The name.** Two labels for one concept, or one label for two.
- **The meaning.** Composition that includes trims against composition that does not.
- **The format.** A free text string where a coded value is required.
- **The unit.** Grams against kilograms, or a percentage by mass against a percentage by volume.
- **The permitted values.** A controlled vocabulary that does not contain the word your catalogue uses.
- **The granularity.** A value that is true of a model held against a passport registered per item.
- **The applicability.** An attribute that is mandatory for one product type inside a group and not for another.
- **The identifier.** The value is right and it is attached to the wrong thing.
- **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](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/batteries_en) 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, so it isn't 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 reaches, is the subject of [the attributes we track](https://activatedigital.ai/knowledge/fields) rather than of this page.

## Canonical value and translated label

A canonical semantic value and a translated customer label are different layers. [See how to keep product identity separate from country and language presentation.](https://activatedigital.ai/knowledge/guides/dpp-eu-countries-languages)

## 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

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](https://activatedigital.ai/knowledge/fields/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 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](https://activatedigital.ai/knowledge/evidence).

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 carry is set by [its own delegated act](https://activatedigital.ai/knowledge/regulation/what-a-delegated-act-decides), 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](https://interoperable-europe.ec.europa.eu/collection/semic-support-centre/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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AL_202601736), 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](https://activatedigital.ai/knowledge/passport/who-sees-what) 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](https://activatedigital.ai/knowledge/status/standards).

## Semantic interoperability is a requirement; one modelling stack is not

The EU requirement is that passport information can be understood and exchanged consistently. That should not be translated into a claim that every business must use one industrial modelling technology.

EN 18223:2026, the DPP system-interoperability standard, is now among the six DPP standards cited as harmonised standards under ESPR. The 2026 Registry implementing regulation also establishes a semantic repository as the authoritative machine-readable source for the data models, definitions and vocabularies used by the EU DPP system.

Those are strong interoperability requirements. They still leave room for different implementation approaches behind the governed output.

Asset Administration Shell submodels, RDF-based representations and Catena-X semantic models can all contribute to machine-readable product information. Current interoperability work between AAS and RDF is evidence that more than one modelling approach is live. Catena-X's use of AAS-aligned digital twins is a sector architecture choice, not a universal legal instruction to model every DPP that way.

The test for an internal product-data model isn't "does it use the fashionable stack?" It's:

- can the required DPP facts be mapped to the applicable published definitions;
- are units, controlled vocabularies, scope and identifiers preserved;
- can the resulting information be exchanged in the required interoperable form;
- can provenance be traced back to the governed source?
If those conditions are met, the internal representation can remain an architecture decision. The comparison between DPPs, digital twins and AAS is covered in [Digital Product Passport vs digital twin vs Asset Administration Shell](https://activatedigital.ai/knowledge/product-data/dpp-vs-digital-twin-aas).

## What the Registry's current operational state adds

The semantic repository is established in law, but its product-group content is progressive: as checked on **7 October 2026**, Commission User Guide v1.03 says successful Battery DPP registration is not yet available because the Battery semantic catalogue and content have not yet been defined, so a repository existing in law isn't the same as one populated for your product group. Current position: [EU DPP Registry Operational State Snapshot](https://activatedigital.ai/knowledge/regulation/where-passport-data-lives#operational-state); what a submission is validated against today: [register a DPP in the EU Registry](https://activatedigital.ai/knowledge/regulation/how-to-register-a-dpp-eu-registry).

## What to do now

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

- **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.
- **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.
- **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.
- **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.
- **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. Apply that test to any registry work offered to you this year. The architecture it all sits inside, and what the registry holds against what stays with you, is set out at [where your passport data actually lives](https://activatedigital.ai/knowledge/regulation/where-passport-data-lives).

Mapping is a question about your own fields before it is a question about the repository, so it helps to [check which of these meanings your data can already carry](https://activatedigital.ai/dpp-readiness-checker).

## Keep exploring

The question this one usually raises next.

- [CompareImplementationWhere product data stops meaning the same thingThe same failure between two commercial systems, worked attribute by attribute, with the pairs that catch people.→](https://activatedigital.ai/knowledge/guides/what-does-not-map)
Also worth reading

- [Evidence behind thisEvidence & suppliersWhat proof of registration provesWhat comes out of the registry once your data does conform, and the narrow thing that document establishes.→](https://activatedigital.ai/knowledge/evidence/proof-of-registration)
- [Another angleRules & scopeWhich passport standards carry a presumption of conformityThe eight standards underneath this, and why two of them not being cited in the Official Journal matters.→](https://activatedigital.ai/knowledge/status/standards)

## Sources

- [Commission Implementing Regulation (EU) 2026/1778 establishing the Digital Product Passport registry](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32026R1778) Delegated or implementing actRelevant provisions reviewed
Articles 8(7)(a), 11 and 12 in full, plus recitals 19 and 20. Article 12(2)(a) quoted from the enacting terms.

- [DPP Registry user guide for economic operators](https://single-market-economy.ec.europa.eu/document/download/079a45e2-469f-4eec-b1e5-32e8e05d1357_en?filename=dpp_registry_user_guide_for_economic_operators.pdf) Official guidanceRelevant provisions reviewed
One sentence, quoted verbatim, on the battery semantic catalogue. Also the EU Login access route. Guide updated August 2026.

- European Commission announcement that the Digital Product Passport registry is operational Reviewed in full
The repository being free and available across product groups, and the first named deadline.

- [Regulation (EU) 2024/903 (Interoperable Europe Act)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202400903) EU lawRelevant provisions reviewed
The one published attribute level artefact found, used for the controlled vocabulary example and for what it is not.

- [DCAT-AP, the DCAT application profile for data portals in Europe](https://interoperable-europe.ec.europa.eu/collection/semic-support-centre/dcat-ap) European CommissionRelevant provisions reviewed
Named in Article 12(1) as the basis on which the repository is developed. Read for Articles 4, 7 and 8.

- [Commission Implementing Decision (EU) 2026/1736 on harmonised standards for digital product passports](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AL_202601736) Delegated or implementing actOfficial source confirmed, detailed review pending
What DCAT-AP is and who maintains it. The version position is described as unsettled because two Commission surfaces state different current releases.

- [Digital Batteries Passport, data point by category](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/batteries_en) European CommissionRelevant provisions reviewed
The six standard references cited in the Official Journal, read from the Annex.