How does a Digital Product Passport work? A complete guide to DPP

A Digital Product Passport (DPP) is a structured set of information about a product made available electronically through a persistent data carrier, such as a QR code or another identifier. It is not a single file or a marketing product card. It is a controlled record that can link identification data, materials, origin, instructions, evidence and information for different audiences.

The key question is not ‘do we already have all the data?’, but ‘can we show where each value comes from and who approved its publication?’. DPP Grid helps separate source data, AI suggestions, private evidence and the approved public version. This enables a brand to begin preparations without pretending that unresolved fields already fulfil an obligation.

In practice, a passport is an experience for several groups. A manufacturer or importer needs the full record, a supplier is responsible for its part, and a consumer should be able to find accurate product information quickly. Supervisory authorities may need yet another level of access. A well-designed DPP shows these boundaries instead of putting all the data on one page.

The process starts with sources: a catalogue, document, supplier data, test report or manually entered value. Each source should have an owner, date, scope and review status. Import is not publication. It is only a way of preparing suggestions that a human can check.

The values are then mapped to the product model. This is when it is necessary to distinguish between a model, variant, batch and individual item. A model identifier can describe a shared design, while a batch number or serial number makes it possible to narrow down information about production, repairs and withdrawal.

After review, a versioned record is created. Publication creates an immutable point of reference, and subsequent corrections are a new version with their own date and integrity hash. This means that a link placed on the packaging can remain persistent, while the user can still see what changed after the first publication.

A QR code is an access route, not the passport itself. It should lead to a stable resolver capable of directing the user to the correct product, version and language. It is not advisable to encode the entire content in the graphic: long text makes scanning, changing the language and withdrawing an incorrect version more difficult.

The resolver should work in a standard phone browser, without requiring an app to be installed. In the simple view, the consumer sees the product name, brand, image, whether the record is up to date, and a warning if one is active. The full view may reveal the data structure, documents and technical evidence, but only where the visibility policy permits this.

DPP Grid also creates machine-readable formats, such as JSON and JSON-LD, as well as PDF files and QR-code graphics. Each should point to the same public record, and file names and web addresses must not disclose private supplier or owner data.

The minimum record should identify the product and the scope of the data unambiguously. Record the brand, name, category, model, variant and the relevant identifier. For production, a batch number, date of manufacture, location and responsible economic operator are useful. If a field cannot be confirmed, it is better to mark it as unknown than to fill it in based on guesswork.

The scope should be defined before import. Does the record concern a model, a particular batch or a single product? Is the materials data common to all variants? Does the care instruction differ by colour or market? These decisions affect the eventual number of records, the way codes are generated and maintenance costs.

A consistent field dictionary helps to limit duplicates. DPP Grid displays values, sources, evidence, review status, visibility and history. Users do not need to see table names or technical keys; what matters is that the operator can trace the path of a value from its source to publication.

Information about composition and origin is often dispersed among the brand, suppliers, facilities and laboratories. Instead of copying content from a spreadsheet to a webpage, ask for structured values and a document that confirms them. Retain the unit, geographical scope and date, because “cotton” without a percentage and without production context says little.

The supplier portal should restrict access to the specific request. A supplier should not be able to see another brand’s data or the client’s entire catalogue. The deadline, reminder, revocation of access and latest response should remain in the history. These rules make it easier to explain later why particular information was included in the passport.

It is worth separating the material’s origin from the entity’s headquarters. The country of origin, place of processing, facility and responsible importer may be different values. In the public passport, show only information that has been approved and does not breach commercial confidentiality.

A DPP does not become trustworthy merely because a field has a green indicator. Evidence should be linked to a specific value, product scope and date. A document may be private; on the public page, it is sufficient to provide a clear explanation that the value was approved on the basis of the specified source.

Monster AI may classify a document, read a proposed value or identify a gap, but it should not approve claims on its own. The operator sees the source excerpt, proposed value, current value and conflict. They can accept it, edit it and then accept it, reject it, or ask the supplier for clarification.

The review should have an unambiguous outcome: approved, rejected, expired, conflicting or requiring further work. The public version contains only values permitted for publication. This separation protects the consumer and facilitates auditing without presenting the DPP as a certificate.

Consumers should not be given instructions on how to use the data system. After scanning the code, they should be able to quickly recognise the brand and product, check the basic facts, and move on to materials, origin, care, repair and the product’s next life. Each section may contain simple text, an icon and optional details, but missing data must be communicated clearly.

The simple view should limit the number of decisions. Two main actions are enough: go to the full details and contact the brand or report a problem. Information such as the record summary, technical schema version or publication history is useful in the full view, but should not obscure the product.

Language, contrast, text size and operation without an app are just as important as the data. A localised interface should have local links, a title, description and alternative text. Product content belongs to the customer and may require separate approval, independent of translations of the DPP Grid interface.

The passport can remain useful long after the sale. Care instructions should be short, specific and linked to the correct variant. Safety guidance must be visible regardless of marketing consent. If an instruction is fictional or for demonstration purposes, this must be clearly marked.

Repair and resale require an event history, but do not need to disclose all personal data. Record the event type, date, status and the entity that can confirm it. When ownership is transferred, retain the product’s original identity and show only information permitted by the privacy policy.

Take-back and recycling are best designed as the next step, not as a slogan. The link to return instructions, a repair partner or a collection point should be up to date. If the service is not yet available, the passport should say so clearly rather than suggesting that a ready-made network exists.

Regulations and standards change, so every passage concerning an obligation or deadline should have a source and a verification date. Official legal acts determine the scope of the obligation; an article helps to explain them, but does not replace an assessment of the product and the business’s role.

Assign an owner for updates. When a source document changes, the record may move to a ‘requires review’ state, rather than automatically to ‘approved’. Retain the previous version and the difference. This makes it possible to explain what the consumer saw before the change and why the later version is different.

In DPP Grid, the update date, source and publication status are part of the experience. Uncertainty should not be hidden behind the words ‘compliant’ or ‘verified’ when only the integrity of the record has been confirmed. Precise language matters more than a striking label.

The safest first project is small: one category, a few models, one business owner and a specified review date. Start by compiling the catalogue, mapping sources and listing gaps. Then ask suppliers for specific documents, accept only checked values, and publish a demonstration record with a clear indication of its scope.

Measure more than just the number of passports. Record the time from import to review, the number of conflicts, the proportion of fields with evidence, the number of documents nearing expiry and consumers’ questions. These data help determine which automations are safe and which need an additional owner.

When the pilot works, expand it according to the same policy: identifiers, sources, evidence, visibility, versions and languages. More products without these rules create only a larger catalogue of uncertainty. More evidence without a good consumer experience delivers no value after the sale.

The first mistake is equating a DPP with a single PDF document. A PDF may be a useful export, but it does not provide a stable link, up-to-date language content or separated access. The second mistake is treating the QR code as proof of the physical item's authenticity. The code leads to a record; authenticity requires its own data and process.

The third mistake is publishing AI suggestions or supplier data without review. The fourth is using a single status, "compliant", for different meanings: data completeness, signature integrity, legal obligation and product authenticity. Each of these needs a separate explanation.

The fifth mistake is having no plan for a change of team, supplier or platform. A durable resolver, JSON export, versioning and ownership documentation make it possible to transfer the record. It is also worth rehearsing withdrawal and restoration before the code reaches thousands of packages.

A Digital Product Passport works when data, evidence and decisions remain connected from the first source to the public scan. This connection requires an identifier, access control, versioning, human review and honest language. It does not, however, require pretending that every future rule is already final.

If you want to move from sources to a signed record, see the DPP Grid platform, business implementation and EU requirements. Also read the DPP guide to compare concepts and limitations.

The best next step is to prepare one product model, gather the sources, review the gaps and only then publish. This rhythm gives brands control, suppliers clear tasks and consumers information they can make sense of.

Scanning should be a short route from the physical product to the correct record. The phone reads the carrier, opens the resolver and passes it the identifier. The resolver can then select the language, version and scope of the visible information. This is the layer that makes it possible to change the content without printing a new label, while retaining the address that the brand placed on the packaging.

A well-designed screen first answers the question, "What product is this?" Only further down does it show materials, origin, care and history. If the record is a demonstration record, this should be visible before the data is interpreted. If there is a safety warning or withdrawal, the message must have a higher priority than the marketing description.

Scanning should not require an account or an app. An account may be needed for a private wardrobe, an ownership transfer or a submission, but public product identification must work in a standard browser. This division is important for accessibility, recycling and oversight bodies, which may use different tools from the brand owner.

An identifier is not a decorative number. It should be unambiguous within the scope it describes: a model, variant, batch or serialised item. Before creating the QR code, the team should establish whether the identifier will remain stable after a change of packaging, supplier or sales channel. Assigning the same number to different products makes withdrawal and repair more difficult.

Versioning separates the persistence of the address from the currency of the information. The same resolver can show the latest approved version, while the history makes it possible to reconstruct what was published previously. The version description should retain the date, scope of the change and the person responsible. Do not overwrite the old record without leaving a trace, even if the change is only a correction to a typographical error.

When planning the carrier, check the contrast, margin, size and placement on the product. A code placed on a curved surface, under film or next to a dense pattern may be difficult to read. Test it in the conditions in which consumers actually scan: in shop lighting, with a mid-range phone and without a special app.

Completeness is not the only measure of quality. Every field should have a source, unit, scope and review status. “Cotton” without a percentage content may be too general, while “eco-friendly product” without evidence may be a claim that must not be published. A list of missing items helps plan the work without pretending that an unknown value is valid.

Review should cover conflicts between documents, expired data, different variants and language consistency. A suggestion generated by Monster AI is a proposal, not a decision. The reviewer should be able to see the source excerpt, change the value and leave a justification. Only an approved record may proceed to the public version.

Before release, perform a test scan, open the simple and full views, and check the links, language and alt text, as well as the export format: JSON/JSON-LD. It is also worth checking that the public page does not contain private supplier names, reviewers’ comments or owner data. Visibility control is part of quality, not an add-on after publication.

A shop catalogue describes the offering and helps sell the product, but it usually does not store full provenance or a history of changes. An instruction manual may contain care information, but it does not have to identify the source of every claim. A PDF is a useful export for archiving; however, on its own it does not provide a resolver, up-to-date language versions or access separation.

A DPP can combine these elements in one controlled record, but it does not have to replace all source systems. ERP, PIM, supplier documents and the shop may still be the owners of specific data. The key is a clear map: where each value comes from, who approves it and when it becomes public.

This approach reduces the risk of duplicating content. Instead of copying a description in five places, a brand can publish an approved representation and maintain a history. The consumer receives simple information, the operator a decision trail, and the technical team a stable integration point.

The biggest change with a DPP is not the QR code itself, but the way information is reconciled. Marketing may know the product name and description, procurement the supplier, quality the test report, and customer service users’ questions. A shared record helps connect these perspectives, but it does not remove the need to discuss who owns each value.

At the outset, use simple questions: what do we know, how do we know it, who can confirm it and who should see it? These questions are more useful than declaring that the product is already “compliant”. Each answer can be marked as approved, preparatory, private or requiring further review.

Shared names and examples limit errors when scaling. Show operators the same workflow using one fictional product, then agree which steps will be mandatory in the real catalogue. This makes the DPP a tool for everyday work rather than a one-off technology project.

Source → review → signed record → QR → consumer experience.

Identifier, evidence, visibility and language are checked before publication.

The same identifier retains context from first sale through to its next life.

No. The scope depends on the legislation and timelines applicable to the relevant product group. Treat preparation as work based on current sources, not as an automatic declaration that a DPP is required.

No. A DPP is a structured data record. Certification, legal compliance and product authenticity require separate evidence and processes.

No. A QR code is a carrier that opens a persistent resolver. The content, version and permissions are maintained within the record.

AI can help with extraction and flag conflicts, but publication should be approved by an authorised human.

Store the evidence privately, limit access to the specific request and publish only approved fields.

Yes, but a change should create a new version with a date, history and a clear description of the difference.

Choose a few models, a data owner and one success criterion. Expand after completing the review.

No. The platform organises data and evidence, but it does not replace legal advice or a compliance assessment.