Mapping Digital Product Passport Requirements onto ETIM Fields

The Digital Product Passport regulation is unusually clear about the shape of what it wants and unusually quiet about the content. Product information must be machine-readable, structured and interoperable, resting on internationally recognised open standards. It does not say which standard. That is left to the delegated act for each product group, and most of those acts do not exist yet.

This creates a peculiar situation for a manufacturer of electrical, HVAC, plumbing or building products. You know a requirement is coming. You know roughly what it will demand. You cannot yet know the exact field names. And you have a classification standard sitting in your PIM that already describes most of your product's technical properties unambiguously.

The sensible move is to map what you have onto what you can reasonably predict, build the record now, and leave the regulatory plumbing until the act that governs your products is published. This piece is that mapping — including, importantly, the parts where the mapping fails.

What ETIM actually gives you

ETIM is a dictionary, not a file format. Its job is to make a technical property mean the same thing to a German manufacturer, a Dutch wholesaler and a Polish contractor without any of them agreeing a private schema first.

Three code types carry that meaning:

ETIM 8.0 contains 18,766 features across 5,145 classes. Each feature has one of four data types: numeric, numeric range, alphanumeric, or logical.

The constraint that matters for compliance is easy to miss. Alphanumeric features do not accept free text. Each is bound to a list of permitted values, and each of those values has its own EV code. You cannot write "approximately IP66" into an ingress-protection field. You select a value or you do not populate it.

That single restriction is the difference between data a machine can read and data a machine can evaluate. A regulator checking conformance, a distributor's procurement system filtering on a threshold, and an AI assistant answering "which of these is rated for outdoor use" all interrogate that field identically. This is what "interoperable" means once you stop treating it as a synonym for "shared".

Where the DPP requirements land on that structure

The requirements fall into four groups, and only two of them are ETIM's problem.

Identification — mostly not ETIM

The passport needs a unique product identifier, an issuing scheme for it, and an operator identifier. ETIM classifies what a product is; it does not issue identity. This is GS1 territory, or an equivalent scheme, and it is the first thing to settle because everything else keys off it.

Technical characteristics — squarely ETIM

This is the part ETIM was built for and where the mapping is close to one-to-one. Dimensions, materials, performance ratings, electrical characteristics, ingress protection, temperature ranges: these already exist as EF features on your class, with defined units and permitted values. If your products are classified, most of this is done and you simply have not been thinking of it as compliance data.

Environmental and circularity — ETIM xChange 2.0

Here is the development most people have not registered. ETIM xChange 2.0, released in November 2025, added extended environmental fields for life-cycle assessment and Environmental Product Declaration data, developed with ETIM International's environmental data working group. It also added a packaging material element aimed at the Packaging and Packaging Waste Regulation.

Whether those fields align one-to-one with a given delegated act is unknowable until the act is published. But the structure exists, it is versioned, and manufacturers are already populating it. That is a materially better position than an empty column headed "carbon footprint".

Carrier, registry and access — not ETIM at all

The data carrier on the physical product, registration in the EU registry that went live in July 2026, and differentiated access control — some fields public, some visible only to regulators or recyclers — are all outside the classification standard. ETIM tells you what a property means. It has nothing to say about who may read it.

What a compliant-shaped record looks like

ETIM xChange is JSON with a published JSON Schema, and it separates generic product data from the trade items that carry it. The shape below is that separation, with a miniature circuit breaker as the subject.

One deliberate omission needs explaining. The ETIM model is licensed ODC-BY, and this article does not reproduce it. EC000001 and EF000007 appear because ETIM International and its national organisations publish them as illustrative examples in their own documentation. Every other code below is shown as a placeholder. Pull the real ones from your ETIM release — that is the licensed, attributed, always-current source, and republishing a dictionary you do not own is a poor foundation for a compliance record.

{
  "product": {
    "manufacturerProductNumber": "MCB-C16-1P",
    "manufacturerGLN": "<GS1 Global Location Number>",
    "productIdentifier": {
      "scheme": "GS1",
      "value": "<GTIN>"
    },
    "classification": {
      "system": "ETIM",
      "release": "ETIM-8.0",
      "class": "EC000001",
      "features": [
        { "code": "EF000007", "type": "A", "value": "<EV code for colour>" },
        { "code": "EF<rated-current>", "type": "N", "value": 16, "unit": "A" },
        { "code": "EF<poles>", "type": "N", "value": 1 },
        { "code": "EF<tripping-characteristic>", "type": "A", "value": "<EV code for C>" },
        { "code": "EF<ip-rating>", "type": "A", "value": "<EV code>" }
      ]
    },
    "environmental": {
      "epd": {
        "declarationNumber": "<EPD registration>",
        "validUntil": "2029-11-30",
        "gwpTotal": { "value": 2.41, "unit": "kg CO2e" }
      },
      "recycledContent": { "value": 18, "unit": "%" }
    },
    "packaging": {
      "materials": [
        { "material": "corrugated board", "weight": { "value": 42, "unit": "g" }, "recycledContent": { "value": 82, "unit": "%" } }
      ]
    }
  },
  "tradeItems": [
    {
      "gtin": "<GTIN>",
      "packagingQuantity": 1,
      "orderUnit": "PCE"
    }
  ]
}

Three things about this record are worth drawing out.

The classification block carries its release. "release": "ETIM-8.0" is not decoration. Features move between releases, and a record that does not state which dictionary it was written against becomes ambiguous the moment the next version ships. This is the single most common defect in real-world ETIM data.

Every feature carries its type. A consumer can validate "type": "N" against a numeric and "type": "A" against a permitted-value list without knowing anything about circuit breakers. That is what makes the file checkable rather than merely parseable.

Generic data and trade items are separate. One product, many pack sizes, one set of technical truths. Flattening these — which is what most spreadsheet-based exchanges do — is how a 10-pack ends up claiming the weight of a single unit.

The gaps, stated plainly

A mapping article that claims complete coverage is selling something. Four honest gaps:

1. 01No delegated act exists for most product groups. The only firm date is 18 February 2027 for certain industrial, EV and light-transport batteries, under the Batteries Regulation rather than ESPR. Anyone quoting you a single DPP deadline is oversimplifying.
2. 02ETIM's environmental fields are new. Released November 2025, they have not been tested against a published delegated act, because there is not one to test against.
3. 03Access control is unsolved in the format. The regulation contemplates tiered visibility. ETIM xChange does not express it. That will need to live in whatever serves the passport.
4. 04Classification coverage is uneven. 5,145 classes is a lot, but if your product sits in a sparsely-featured class, the dictionary will not carry your differentiators and you will be back to attachments and free text.

Why this record is worth building anyway

Strip the regulation away entirely and the same file is still the most valuable thing you could build for your catalogue.

A structured, typed, dictionary-backed product record is what lets a distributor ingest your range without a mapping project, what lets a procurement system filter on a threshold rather than a keyword, and what lets an AI assistant answer a specification question about your product and cite you rather than guess. We measured 984 industrial catalogues on that last point and the median score was 50 out of 100 — the constraint is almost never the product, it is that the data describing it is trapped in PDFs and JavaScript.

The compliance deadline is a forcing function for work that pays for itself. That is an unusually comfortable position, and it is worth recognising it as one.

Where to start

In this order, because each step makes the next cheaper:

1. 01Classify against your current ETIM release, and record which release. If you are already classified, verify the release is stated in your exports — often it is not.
2. 02Export to ETIM xChange 2.0 and validate against the published JSON Schema. Validation failures here are data-quality problems you already had and had not seen.
3. 03Populate the environmental block with whatever EPD and LCA data exists today, even if partial. Partial structured data beats complete unstructured data.
4. 04Settle identity — GTIN or equivalent, and the issuing scheme — because the passport keys off it.
5. 05Leave carrier and registry until your delegated act is published. Building against a draft is how you end up doing it twice.

The first three steps produce an asset that is useful the day it exists, regardless of what the delegated acts eventually say. That is the test to apply to any DPP work someone proposes to you: if it is worthless without the regulation, it is probably premature.