Start with the boundary: confirmed versus candidate data
ESPR establishes common passport building blocks, but the applicable product measure selects the final information for a category. A useful readiness inventory therefore needs two layers: confirmed architecture and candidate product data.
Confirmed architecture includes the need to connect a carrier and persistent product identifier to structured passport information, keep data accurate and current, manage access rights, and support continuity. Candidate data can include materials, durability, repair, recycled content, environmental performance, or other product attributes that may be selected by the category rule.
Sources for this section
The seven data groups worth mapping now
The goal is not to predict every final field. It is to expose where data live, who can vouch for them, and how reliably they can move into a passport service. The following groups create a useful cross-category starting point.
- Product identity: model, batch, item, SKU, GTIN or other identifiers, variants, and the relationships between them.
- Economic operators: manufacturer, importer, authorised representative, distributor, and the legal entity placing the product on the EU market.
- Suppliers and facilities: source organisation, facility identity, evidence owner, and permitted disclosure level.
- Product composition: materials, components, substances, weights, units, calculation method, and source documents.
- Compliance and instructions: declarations, certificates, test reports, manuals, safety information, and applicable commodity codes.
- Lifecycle information: repair, spare parts, disassembly, use, return, remanufacture, and end-of-life records where relevant.
- Data governance: field owner, reviewer, status, effective date, correction history, access class, retention rule, and next review trigger.
Sources for this section
Turn the inventory into an evidence ledger
A passport value without provenance is a future reconciliation problem. For each candidate field, record the value, unit, product level, source system, source document, supplier or internal owner, verification state, effective date, and the person who can approve publication.
Use explicit states such as supplier-submitted, calculated, estimated, verified, expired, unknown, and not applicable. This prevents a clean interface from making weak evidence look equivalent to checked data. It also lets the team quantify gaps without filling them with marketing copy.
- Field name and plain-language definition.
- Model, batch, or item level and the identifier used to join records.
- Authoritative system and supporting document or calculation.
- Owner, approver, verification state, and permitted audience.
- Update event, retention period, and correction path.
Sources for this section
Run a 30-day readiness sprint
Choose one representative product family rather than trying to catalogue the entire business. Include enough variants and supplier complexity to expose real joins, but keep the scope small enough to finish. The outcome is a reusable operating model, not a one-off demo.
- Week 1: classify product scope, legal entities, identifiers, and systems of record.
- Week 2: collect source evidence for the seven data groups and mark gaps.
- Week 3: define access, approval, correction, export, and provider-exit workflows.
- Week 4: publish a controlled prototype, test failures, and record open assumptions.
What not to hard-code before the category act
Do not turn a consultant template, pilot dataset, or software default into the legal field list for an unsettled category. Avoid irreversible carrier placement, item-level identity, retention, and public-access decisions until the applicable act supports them.
You can still test those choices as assumptions. Record the source, confidence, cost of reversal, and event that will reopen the decision. That makes the prototype useful even if the final rule differs from today's best estimate.
- Do not label every candidate field as mandatory.
- Do not equate missing supplier data with zero or not applicable.
- Do not let a vendor own the only copy of product identifiers or evidence.
- Do not publish commercially sensitive data without a field-level access decision.
- Do not call prototype completion proof of legal compliance.
Sources for this section
Frequently asked questions
Is there one final DPP data template for every product?+
No. ESPR establishes common architecture and possible information building blocks, while the applicable product rule determines the final dataset, granularity, access, and timing for its scope.
Should we ask suppliers for DPP data now?+
Yes, if the request is framed as evidence mapping and readiness. Define each requested field, allow unknown states, record provenance, and avoid presenting the list as a final legal template where the category act is still pending.
Which system should hold DPP data?+
There is rarely one universal system of record. Map authoritative sources across ERP, PIM, PLM, supplier, compliance, and service systems, then define how governed data are assembled, approved, published, exported, and corrected.