The public infrastructure
The Commission operates the EU Registry. Registration does not replace hosting or establish the truth of every product claim.
ESPR, Article 13 ↗What the Registry holds ↗Where we stand · ActivateDigital
Let product identity travel.
Keep its authority intact.
A Digital Product Passport should make product information useful beyond the system that created it. It should not make that information ownerless, expose what should stay private or trap a business with one provider.
A public position, not a conformance certificate. Sources checked 22 October 2026.
The architecture
Different jobs.
One accountable chain.
The engine makes decisions. The business approves. The published record carries the result and its basis. Other systems use it through the right access.
How the two fit together. ActivateDigital is the software a business uses to turn its product records and evidence into a passport and to approve it. dppcode.org is the public address where that approved passport is published and found. The code printed on a product holds the product’s identifier. Scanning it opens dppcode.org, which sends the reader to that product’s passport. Both are run by SIGNALANALYTICS.AI LTD.
The inputs
Brand data
Store records, files, supplier evidence and product identifiers.
ShopifyCSVPDFSuppliers
Data + evidence→
The business layer
Engine + Workspace
Connect. Resolve. Review.
The responsible business approves.
{Activate}→Approved releaseThe published record
dppcode.org
Stable identity. Released version. Evidence and access rules stay attached.
Publication boundaryEU Registry
Register identifiers and required metadata when the applicable rules require it.
Registration data + referencePartners
Retailers, marketplaces, data pools, repairers and recyclers.
Permitted data + shared viewsPeople + software
Scan the product. Read the appropriate record or machine-readable representation.
Public facts / authorised accessThe responsibilities
A passport is a record.
Responsibility belongs to people.
Law sets duties. Standards support exchange. Our product design must respect both. They are not interchangeable.
The common language
GS1 supplies identification and exchange standards. CEN-CENELEC develops the DPP standards. Neither makes our implementation independently approved.
GS1 Digital Link ↗CEN-CENELEC DPP work ↗The responsible business
Passport data must be “accurate, complete and up to date”. The relevant economic operator must fulfil the applicable duties. Hiring software does not transfer all of those duties to its supplier.
ESPR, Articles 9 and 27 ↗The service provider
Provider use of passport data is restricted. Necessary backup, continuity and access cannot be reduced to a marketing promise.
ESPR, Articles 10 and 11 ↗When a provider or link disappears →The Engine + Workspace
ActivateDigital connects evidence, resolves supported values and brings decisions to the business for approval. Product Packs, Protect and Measurement use the governed identity in the business layer.
Our decision methodology →Products and their current status →The published record
dppcode.org is the publication and resolution layer. It should serve the approved result, not quietly invent a new one. It is not the EU Registry or an independent regulator.
How dppcode.org describes its role ↗Read an annotated passport →Identifiers
A product needs one identifier
that stays the same.
GS1 barcodes come first, always. Where a brand has none yet, we provide an identifier so its passport can go live now, as a step on the way to GS1.
Why one identifier matters
The Ecodesign for Sustainable Products Regulation builds the passport around a unique product identifier. A data carrier on or with the product holds it, and the passport is connected to the product through that carrier. The identifier and the carrier meet the ISO/IEC 15459 series listed in Annex III, or equivalent European or international standards. No article names a numbering scheme. We support the regulation and a consistent identifier on every point.
ESPR, Article 2 ↗ESPR, Article 10 ↗ESPR, Annex III ↗What the regulation points to
ISO/IEC 15459 sets out how a unique identifier is formed. GS1 Digital Link writes a GS1 number as a web address that a phone can open, so one printed code reaches one passport.
ISO/IEC 15459 ↗GS1 Digital Link ↗GS1 barcodes first
GS1 is the best, most consistent and most scalable option, and we recommend every brand gets GS1 barcodes. Shops, marketplaces and tills read a GTIN. One number works in every country and every system, so the passport address never changes.
Get GS1 barcodes from GS1 UK ↗No GS1 barcode yet?
In line with the regulation, we provide the product with an AD ID so its passport can go live now. It is a step on the way to GS1 and not an alternative to it. An AD ID has 15 digits and is built the way a GTIN is: a fixed issuer part (71) that marks it as ours, a company part of 6 digits given once to each brand, an item part of 6 digits for each product with its own number for each size or colour, and a check digit worked out in the GS1 way. For example, 719999990000019.
Two addresses, one passport
An AD ID has its own address on dppcode.org, written /a/ followed by the 15 digits, beside the GS1 form /01/ followed by the GTIN. Every identifier is kept in a register and none is reused or changed. When a brand gets GS1 barcodes, its GTIN is linked to the same passport and the earlier /a/ address keeps working.
Not a GS1 number
An AD ID is not a GS1 number, not a standard and not certified. No one has approved it. A GTIN is still what a retailer will ask for.
Our principles
Openness with boundaries.
Control without captivity.
These are our positions on how the ecosystem should work. Where we go beyond a legal minimum, we say so.
The record stays still. The work happens behind it.
Keep interpretation in the engine. Publish its approved result with its evidence and method. A modelled figure remains modelled after publication; it does not become a measurement.
What a passport field can prove →Publish a release. Preserve the change.
Our design rule is to give an approved release its own version and make later corrections traceable. A stable product address can resolve to the current release. A legal correction or erasure takes priority over retaining an inappropriate public copy.
Our proposed record contract ↓Separate responsibility, not just domains.
The Workspace and published record have different jobs. Both are operated by SIGNALANALYTICS.AI LTD. That is not independent ownership or certification. We recommend a backup that remains recoverable if our service fails; the statutory backup and provider definitions still apply.
ESPR, Article 2(32) and Article 10(4) ↗Share for a purpose. Respect the right to see.
The business should control optional sharing of information it is entitled to share. Statutory access is not optional. Neither a commercial agreement nor a brand setting should remove a right granted by law.
Public and restricted information →Keep evidence attached. Keep unknowns visible.
A full-looking record is not the same as a supported record. Preserve the source, product scope and reason behind a value. Conflicting evidence needs a decision, not a hidden overwrite.
When sources disagree →Build on standards. Keep the exit open.
ESPR calls for exchange “without vendor lock-in”. Our position is to use shared identifiers and documented interfaces. Make records and permissions portable where the applicable requirements allow. Changing a service provider should not force a product to lose its identity.
Identity, links and resolution →One identity can do many useful jobs.
A retailer, repairer and measurement tool can use the same product identity without receiving the same data. Each destination needs a deliberate representation and an appropriate permission.
How destination requirements differ →
A practical recommendation
A record people can inspect.
A contract software can use.
The law does not prescribe our folders or require every passport to use our JSON format. This is the publication contract we recommend, not a statement that these example endpoints are deployed.
Stable product identifier
identifier → current approved releaseReleased record
release ID + version + effective dateMachine-readable representation
schema + facts + source + method + stateRestricted evidence
authorised request → permitted evidenceThe same boundary in HTML and data
Serve public facts for people and software. Use typed links and documented schemas, including the GS1 Web Vocabulary where appropriate. Keep confidential evidence behind access controls, not hidden in a public JSON file.
On an update, validate the changed inputs, obtain the required approval and release a new version. Tell authorised recipients which revision changed. Do not let a destination-specific edit silently rewrite the source record.
GS1 resolver and linkset requirements ↗GS1 Web Vocabulary ↗Product identity through an API →Where the boundary breaks
A useful exchange must
also be a protected one.
We see an exchange for governed product information: connected participants, useful reuse and clear authority. That does not make the record a licence to trade away data or restrict legally required access.
A governance failure
An unapproved change, missing provenance or the wrong product mapping breaks the record's controls. Investigate the affected release and correct it visibly.
Our policy positionUnauthorised access or reuse
Sharing outside an agreed scope can break contractual or statutory duties. Selling access to the platform does not create an unrestricted right to sell the underlying passport data.
ESPR, Article 11 ↗A personal data breach
This has a specific GDPR meaning. Apply the relevant security, assessment and notification duties when personal data is involved. A product-data error is not automatically a GDPR breach.
GDPR, Articles 4(12), 32 to 34 ↗Neutral publication needs a boundary people can test.
Our authoring and publication services share an operator. Our position is to document that relationship, make the division of duties inspectable and avoid presenting our own checks as independent assurance. Technical separation is useful. It is not the same as legal independence.
Where this is going
Use today's rules.
Be precise about tomorrow's.
The Registry is operating
The Commission announced its launch on 20 July 2026. Registration, provider identity checks and technical standards have distinct roles. Being listed or registered does not certify every passport statement.
Commission launch announcement ↗Registry implementing rules ↗Read the exact scope
A published standard, a cited harmonised standard and a sector-specific legal duty are different things. Track the relevant act and its application date. A textile readiness model is not the final statutory textile field list.
Commission implementation information ↗Decision 2026/1736: cited DPP standards ↗CIRPASS-2 implementation pilots ↗We will review this position when provider rules, sector acts, cited standards or operational evidence change the responsibilities above. Our recommendations must remain open to correction.
The evidence and the product
Read the reasoning.
See what it supports.
How we decideEvidence, conflicts and the engine's control architecture.Where passport data livesThe record, the EU index and the systems behind them.What identity is worthThe business case and the limits of the evidence.What you can usePassports, connected applications and current availability.
Passports: Live beta. This page states our public design position. It does not claim independent certification, legal separation between our services or completion of every proposed integration.
Primary sources
Check the basis.
Read each source for its own scope. Law, standards, official guidance and our recommendations are labelled separately above.
- ESPR (EU) 2024/1781Articles 2(32), 9 to 13 and 27: roles, availability, access and provider rules.
- Implementing Regulation (EU) 2026/1778Operational arrangements for the EU Registry.
- Commission: the DPP RegistryIndexing, registration and the distinction from decentralised passport data.
- GS1 Digital LinkGS1 identifiers expressed on the web.
- GS1-Conformant Resolver StandardDiscovery, linksets and resolution behaviour.
- ISO/IEC 18975:2024Encoding and resolving identifiers over HTTP.
- CEN-CENELEC: Digital Product PassportEuropean standardisation work, distinct from sector application dates.
- Decision (EU) 2026/1736Cited harmonised standards: presumption of conformity within their covered scope.
- CIRPASS-2Implementation pilots, not a regulator or a legal certification scheme.
- GDPR (EU) 2016/679Personal data, rectification, erasure and security duties where applicable.
This is a public policy position and a guide to the distinctions. Applicable duties depend on the product, operator role and legislation. It is not a substitute for reading those rules.