Product Data Across EU Systems: What Can Be Reused and What Must Stay Separate

The cross-system product data matrix

Two related comparisons: how a DPP differs from an EPD and vehicle passports and the DCVP.

How to read this matrix

May be reusable does not mean copy the field.

A value can move safely only after it passes the equivalence test below. The source record may also have access restrictions, legal-signature requirements or lifecycle rules that do not travel with the raw value.

The ten-question reuse test

Before one system feeds another, ask these questions in order.

1. Same object? Does the value describe the same product, component, material, facility, plot, packaging object or organisation?
2. Same level? Is it true at model, variant, SKU, batch, item, component, shipment or event level?
3. Same definition? Are the two systems asking the same semantic question rather than using the same label for different concepts?
4. Same unit and method? If it is measured or calculated, are unit, method, reference conditions and denominator compatible?
5. Same time basis? Is the source value current for the target product or period?
6. Same actor role? Is manufacturer, producer, supplier, importer or operator being used in the same legal sense?
7. Same jurisdiction and instrument? Does the value depend on a Member State, EU scheme, nomenclature year or sector-specific act?
8. Evidence strong enough? Can you show where the value came from and why it supports the target claim?
9. Access compatible? Is the source value public, authority-only, commercially sensitive or otherwise restricted?
10. Same lifecycle? What event makes the value stale, and who has to update each target system?

If any answer is no or unknown, the value is not ready for direct reuse. It may need transformation, evidence work or a separate record.

A seven-condition test for reusing the factual value itself

Before reusing a value across legal records, check seven things:

• Object: is the fact about the same regulated object?
• Granularity: does it apply at the same model, batch or item level?
• Definition: does each rule mean the same thing by the field?
• Method: was the value produced using a method acceptable for both uses?
• Evidence: can the source and calculation or declaration still support the reused value?
• Access: can the value lawfully be shown to the same audience?
• Lifecycle: does the value change on the same event and at the same time in both systems?

If one of those conditions fails, reuse the underlying evidence or transformation logic rather than blindly copying the published value.

The safer operating statement: one physical or digital entry point can support several obligations, while legal ownership of each fact remains regime-specific.

A field-reuse matrix for the values businesses see most often

Steel is a useful test of semantic reuse

Steel can carry several adjacent identifiers and country-shaped values in the same governed record without any of them becoming substitutes for the others.

These objects can be joined when identity, meaning and scope line up. The join is legitimate because the semantics stay separate, not because one field can be converted into another. The steel-specific origin comparison shows why steel grade, tariff and origin are separate facts when melt-and-pour evidence enters the same product-data record.

Why "one source of truth" is too crude

The phrase sounds clean and often produces bad compliance architecture.

There can be one governed business fact without there being one legal record.

Take an operator's legal name. The same controlled name may feed EPREL, EPR registration, a DPP and technical documentation. But those systems can still have different:

• legal roles
• jurisdictions
• registration IDs
• effective dates
• submission statuses
• evidence requirements
• access rules.

So a practical ownership model separates:

1. The governed fact

The value the business maintains once, with a clear object and owner.

2. The evidence

The document, source system, supplier declaration or measurement that supports the value.

3. The regulatory record

The system-specific submission, registration, alert or passport record required for a legal purpose.

4. The published representation

The value rendered for the customer, recycler, authority or other audience with the access rules that apply there.

That is the cross-system extension of which system should own each product fact. For a shop, see one record reused across a WooCommerce shop.

Reuse can happen at four different layers

When two EU rules touch the same product, “reuse the passport” can mean four very different things:

1. Carrier reuse: one physical or digital entry point gives access to more than one regulated information set.
2. Identifier reuse: the same product identity is recognised across systems where the law allows it.
3. Passport-container reuse: one DPP container carries information needed by more than one interacting legal regime.
4. Factual-value reuse: the same governed product fact is transformed or referenced in several regulatory records.

EU law already contains controlled examples. Toy Safety provides rules for a single carrier/single DPP interaction with other Union law. The Critical Raw Materials Act can require permanent-magnet information to be included in another Union-law product passport. PPWR allows product and packaging information to share an access route without making packaging and product the same legal object. The Construction Products Regulation also builds interoperability into its DPP architecture.

None of those examples establishes a universal “one passport for everything” rule.

System-by-system boundaries that matter

DPP Registry is not the full passport database

The Commission's July 2026 launch material describes DPP data as decentralised. The central Registry registers each DPP's unique identifier and associated metadata.¹

So registered in the DPP Registry and all product data stored by the Commission aren't equivalent statements.

SCIP is not just a chemical reference field

SCIP records article or complex-object identity and Candidate List substance information, including concentration range and location/material context. Reusing a substance value means preserving that article hierarchy.²³

EPREL is the strongest live example of official once-only direction

The 2025 ESPR working plan names EPREL as an alternative digital system where equivalent information is provided. The Commission's June 2026 proposal would go further by interlinking EPREL and the DPP Registry and avoiding duplicate reporting of equivalent model information. The proposal remains ongoing at this page's verification date.⁴⁵⁶

Safety Gate is an event system, not a master product record

GPSR Article 25 defines Safety Gate as the rapid alert system for exchanging information on corrective measures concerning dangerous products.⁷

Product identifiers help resolve which product the alert concerns. The alert and corrective measure remain event records with their own lifecycle.

EUDR combines reusable identity with non-reusable due-diligence context

The EUDR due-diligence statement includes operator information, EORI where relevant, Harmonised System code, product description, quantity and production geography. Some identity/classification values may be reusable. Plot geolocation, due-diligence findings and the statement reference remain EUDR-specific records.⁸

EPR registration is about the producer in a jurisdiction

The 2025 amendment to the Waste Framework Directive requires textile producer registers in each Member State and specifies information including producer identity, official IDs and CN codes. Those underlying party/classification facts can be governed once. The registration number and Member-State scheme status are still separate.⁹

PPWR can share a carrier without merging the product and packaging records

PPWR Article 12 expressly provides that, where Union law requires packaged-product information through a data carrier, one carrier is used for product and packaging information while the two remain distinguishable, so one access point does not mean one regulated object.¹⁰

Customs classification is reusable only with its scheme and date

The Commission describes the Combined Nomenclature as the EU's system for classifying goods for customs and trade statistics, with eight-digit CN codes. The nomenclature is updated annually.¹¹

A code copied without its scheme and applicable version is weaker than it looks.

Technical documentation is evidence infrastructure

EU guidance says manufacturers prepare technical documentation before placing a product on the market, keep it available for authorities and generally retain it for ten years unless product-specific law says otherwise.¹²

That technical file may be the best source for many DPP facts. It does not follow that the whole technical file should be copied into a public passport.

The operating model: govern once, transform deliberately, submit separately

For most businesses the target architecture can be expressed in three verbs.

Govern once

Maintain each stable fact at the level where it is true. Give it an owner, source, status and version.

Transform deliberately

When another EU system wants the fact, compare semantic definition, unit, object, granularity, access class and evidence. Record any mapping or calculation rather than silently copying the output.

Submit separately

Create or update the system-specific record with its own identifier, actor, jurisdiction and lifecycle. Only collapse the workflow where official law or system integration explicitly supports it.

This is a business-data architecture recommendation. It does not change which legal obligations apply.

From one governed fact to many destination packages

The three-verb model becomes easier to operate when each destination is treated as a governed package rather than another copy of the master record.

Start with the strongest reusable fact and the evidence that supports it. Then apply an explicit destination transform where the target asks for a different object, granularity, unit, definition, actor, time basis or presentation. Keep the transform visible. A value that had to be converted, aggregated or re-scoped should not arrive in the destination looking as if it were copied unchanged. That is the same boundary explored in Where Product Data Stops Meaning the Same Thing.

A useful flow is:

governed fact + evidence → destination transform → destination package → validation or submission → destination state

The destination package is the representation prepared for one target system. Alongside the fields themselves, keep the target schema or rule version, destination identifier, validation result, submission or publication status and the point at which the package becomes stale.

The same upstream fact can remain correct while a destination changes. The EU Customs Data Model, for example, is versioned and was updated to EUCDM 7.0.11 in August 2026. A changed destination contract is not, by itself, evidence that the governed product fact is wrong.

This architecture also keeps failures diagnosable. A rejected destination package can point to a source-fact problem, a mapping problem, a destination-only field or a changed target rule. Only the first of those should automatically trigger a correction to the upstream fact.

Same carrier does not mean same legal record

EU law already contains examples of reuse without legal equivalence.

Under PPWR, one data carrier can be used to provide packaging information and other information required under Union law, while the information remains distinguishable. ESPR can also allow other Union-law data to be included in a DPP. Neither provision turns all of the underlying obligations into one legal record.

The same caution applies to every architecture diagram that shows several systems behind one QR code, resolver or product identifier. A shared access point can reduce duplication for the user. It does not remove the different legal objects, actors, evidence requirements, lifecycles or submission states behind it.

A representation or exchange layer does not become the source of truth

The same boundary holds outside the legal databases. Current AAS specifications define a standardised digital representation architecture for an asset, data-space frameworks add governance, policies, semantics and exchange mechanisms for sharing data between participants and Catena-X combines digital twins, semantic models and connector-based exchange in its own ecosystem. An Asset Administration Shell (AAS), a data-space layer, an API or another exchange representation can carry selected governed product facts without becoming their authoritative system, so no ERP, PIM, PLM or evidence system has to surrender authority merely because a value is published through another layer.

Preserve the chain:

authoritative fact → evidence/provenance → representation → exchange or publication

If the representation changes the unit, scope, vocabulary or aggregation, record that transform. If it merely carries the fact, keep the authority pointing back to the system that owns it.

For the deeper distinction between data spaces, digital-twin discovery and sector exchange, hand the question to What Is a Data Space, and How Does Catena-X Fit Digital Product Passport Architecture?. The source-of-truth question itself remains with Which System Should Own Each Product Fact?.

Worked example: one governed PCF, several destinations

One PCF object, governed with its method, boundary, period, version, provenance and assurance status, can be reused in several permitted destinations: one may need a machine-readable exchange record, another a published disclosure, a future DPP requirement may ask for a particular carbon field or method and a customer or supplier data space may have its own exchange contract. It can be reused where the meaning is genuinely the same, but the destination records shouldn't be treated as interchangeable merely because they started from the same number. PACT's current voluntary methodology and technical specification separate calculation from exchange, and under the current PACT v3 technical specification a changed PCF can receive a new footprint identifier with lineage to the preceding one; PACT isn't, by itself, an EU DPP legal requirement, and technical conformance to an exchange protocol doesn't certify that the footprint calculation is correct. The versioning and exchange mechanics are on product carbon footprint (PCF) exchange.

Add destination state, not just destination fields

The existing provenance questions should be extended with the operational state of each destination.

For every important destination package, keep enough information to answer:

• Which target system and schema or rule version did we build against?
• Which identifier did the destination assign?
• Was the package accepted, rejected, warned or still pending?
• Which validation errors came back?
• When was the destination last refreshed successfully?
• Which destination-only overlay or transformation was applied?
• Does the destination error require a source-fact correction, or only a mapping or local fix?

This is the difference between a reusable product-data architecture and a collection of exports. The first can explain what was sent, why it was valid at the time and what changed. The second can only regenerate another file.

Minimum provenance to keep with a reusable value

A reusable product fact should carry enough metadata to answer:

• What is the value?
• What object does it describe?
• At what granularity is it true?
• Who supplied or measured it?
• What evidence supports it?
• Which definition/method/unit applies?
• When was it observed or verified?
• What makes it stale?
• Which systems has it been rendered or submitted into?
• What transformation did each target apply?

If your architecture cannot answer those questions, reuse increases the speed at which an error propagates.

Regulatory, retail and AI destinations use the same governance principle for different contracts

The governed-fact model does not stop at EU regulatory systems.

Retailers and marketplaces also expect destination-specific schemas, category rules, allowed values and validation states. Product data syndication covers the operating model for turning governed product facts into those retailer and marketplace packages.

AI-shopping destinations add another commercial family. They can combine stable product and variant facts with faster-changing seller, price and availability data, then expose the result through feeds, catalogues or agent-facing tools. What Product Data Do AI Shopping Agents Need? covers that product-and-offer boundary.

The architecture principle is shared: govern the strongest reusable fact once, transform it explicitly for the target and keep destination state separate. The legal status is not shared. A retailer feed or AI catalogue is a commercial destination contract, not another EU regulatory record.

Direct answers

Can I use the same product data for multiple EU systems?

Yes, often. Stable identity, party, classification and evidence-backed facts are good reuse candidates. Reuse is safe only when the target system asks the same semantic question about the same object and level.

Does a DPP replace SCIP, EPREL, EPR or EUDR?

Not as a universal rule. Each relationship has to be established by the relevant EU law. EPREL currently has the clearest explicit move toward equivalent-data interlinking with DPPs, and that June 2026 amendment remains a proposal on this page's verification date.

Which system should be the source of truth?

Choose the source of truth per fact, not per regulation. A PIM may own the commercial model name, a PLM may own engineering composition, a technical file may own conformity evidence and an authority system may own the legal registration record.

Should I copy EU database exports into my DPP?

No, not blindly. Treat exports as source records. Map fields only after the reuse test and retain source, object, version and evidence.

Can one QR code serve product and packaging information?

PPWR is a concrete case: one data carrier is used for packaged-product and packaging information while both remain distinguishable, so the carrier can be shared without merging the regulated objects.¹⁰

What would change this resource?

This is a living matrix. Re-check when:

• the Commission's DPP semantic repository publishes or revises formal product data models
• a new DPP delegated act establishes field-level equivalence with another EU system
• COM(2026) 565 on EPREL is adopted, amended or withdrawn
• ECHA changes the SCIP format or notification model
• sector regulations change the identity, granularity, access or record rules shown here
• new Commission APIs create formal system-to-system reuse that changes the operational recommendation.

Primary official sources

• European Commission, DPP Registry now live, 20 July 2026
  European Commission
• ECHA, SCIP database
  Official guidance
• ECHA, Suppliers of articles
  Official guidance
• European Commission, ESPR Working Plan 2025-2030, section 3.2
  Official guidance
• European Commission, COM(2026) 565, EPREL once-only proposal
  European Commission
• EUR-Lex, Procedure 2026/0169/COD
• Regulation (EU) 2023/988, GPSR Article 25, Safety Gate
  EU law
• Regulation (EU) 2023/1115, EUDR Annex II and Information System provisions
  EU law
• Directive (EU) 2025/1892, Article 22b, textile producer registers
  EU law
• Regulation (EU) 2025/40, PPWR Article 12
  EU law
• European Commission Taxation and Customs Union, Combined Nomenclature
  European Commission
• Your Europe, Preparing technical documentation, last checked 12 July 2026
  Official guidance
• Regulation (EU) 2023/1542, Battery passport Articles 77-78
  EU law
• Commission Implementing Regulation (EU) 2026/1778, DPP Registry and semantic repository
  Delegated or implementing act