Digital Product Passports · The workflow guide

One connected product story. From the factory to the field.

Explore the Digital Product Passport workflow, understand the regulatory context and follow a full guided tour of UniQorn Trace.

By UniQorn Systems · 18 October 2026 · 16-minute video

Watch the complete workflow

UniQorn Trace: the end-to-end guided tour

British narration · Eight chapters in one video · Live platform screens and existing test records · On-screen captions. Physical tag programming is explained, not filmed.

Read the full video transcript

1. Start with the right workspace

Welcome to UniQorn Trace, the Digital Product Passport and product traceability platform from UniQorn Systems. This guided tour follows the complete operating sequence: configure your product information, define the product model, create a physical asset, connect its identifier, prepare and publish a passport, and maintain its evidence and lifecycle history. We use an existing test item to explain each stage. These are live platform screens, presented as a narrated walkthrough. The example values are training data, not approved engineering specifications. Begin by signing in with your provisioned account. Check the organisation before working. If you belong to more than one organisation, use the account menu to choose the appropriate workspace. From Solution Workspaces, open UniQorn Trace. Access depends on your organisation and assigned permissions. On the dashboard, Traceability estate brings together Product Masters, Serialised Assets, Identifiers and Published Passports. These counts describe the records in Trace; they are not manufacturing output. Follow the relationship shown in Trace Pulse: Product, Serialised Asset, Identifier, Passport, and Lifecycle or Proof. Each stage has a different responsibility. Understanding those responsibilities prevents duplicate records and keeps evidence connected to the correct physical item. Use the left navigation to move between records. A published passport is the outward-facing information experience; the authenticated workspace is where authorised users prepare and govern that information.

2. Configure the information structure

Before entering a product range, agree what information you need, where it comes from and who approves it. The configuration area contains Product Types, Field Definitions, Product Templates, Passport Templates and Lifecycle Event Types. Field Definitions describe reusable pieces of information. A Product Template organises those fields for a product model. A Passport Template controls how trusted information is organised and presented in the passport. It should map back to the source information rather than encourage separate copies of the same value. Start with one product family and a small, agreed field set. Include the product identity, relevant technical attributes, responsible organisation and evidence references. Add sustainability or circularity fields only when you have an agreed definition, unit, source and owner. An empty or estimated value must not be presented as a verified environmental claim. Product-specific legal requirements should guide the configuration. A generic template is not proof of regulatory conformity. In the Product Templates area, review the reusable structure and its status. In Passport Templates, review the structure, source mapping and version before using it. Keep administrator configuration separate from routine record maintenance. For a new deployment, agree and validate the templates first, then use them consistently across Product Masters and physical assets. This gives the organisation a repeatable information process as its catalogue grows.

3. Create and maintain the Product Master

Open Product Masters to work with reusable model-level definitions. A Product Master describes a type or model of product that may have many physical examples. It is not the register of individual serial numbers. The platform shows the relationship Product Type, Product Master and Serialised Asset. Use Create Product Master when a genuinely new model is required, or open an existing master to review its details. Confirm the product type, product code and the selected templates. Complete the model-level fields from authoritative sources, such as an approved specification or the manufacturer's controlled product record. Review units, naming and applicable standards carefully. A reference to a standard should reflect supporting evidence and the correct scope; typing a standard number does not establish certification. Before creating another master, search the catalogue so that the same model is not entered twice under different names. The detail screen shows the selected Product Template and Passport Template, the model data and the number of associated Serialised Assets. Changes at model level can have implications for downstream information, so follow your organisation's review process. Keep shared model properties here and instance-specific values on the physical asset. For example, two items can share a model definition while having different serial numbers, manufacture dates and lifecycle histories. The purpose is clear ownership of each value, with a stable model record that can be reused.

4. Register the physical asset

Next open Serialised Assets. Each row represents an individual physical product instance. Select Create Serialised Asset to begin a new record. The form asks for a Product Master and a serial number, with additional fields for production batch, manufacture date, operational status and notes. Choose the correct master before entering the physical item's details. Match the serial number to the durable marking or controlled manufacturing record, and check for duplicates. A batch groups production; it does not replace the individual serial number in an item-level workflow. Review the information before saving. In an actual onboarding process, save the record only after the details have been checked. This walkthrough uses an existing test asset rather than creating additional production records. Open the asset to see the physical-instance record. Its detail screen links back to the Product Master and brings together identifiers, passports, lifecycle events and supporting documents. Check that the item on your bench, the serial number on the record and the selected model all agree. The manufacture date and the date the asset entered Trace are different concepts. One describes the physical item; the other describes its registration in the platform. Operational status also needs careful handling. An Active record is an application status, not independent evidence that equipment is safe to use. Decisions about fitness, conformity and inspection remain with the responsible people and processes.

5. Connect QR and NFC identifiers

Identifiers connect the physical product to its digital information. From the asset, choose Manage Identifiers. The screen explains that an identifier belongs to a Serialised Asset. It does not replace the serial number and does not create a passport by itself. Review the identifier type, value and status. The example includes an NFC identifier and QR records, with active and retired states. In your own process, issue the identifier against the correct asset and confirm the intended resolver link before producing the carrier. A QR code carries the link optically; an NFC tag can carry a web address that a compatible phone opens when tapped. Those carriers can provide access to the same underlying product record. Programming a physical NFC tag requires compatible hardware and an appropriate tag-writing process. It should not be assumed that viewing the Identifiers page has written the tag. After attachment, scan or tap the actual carrier and compare the opened passport with the physical serial number. Test the intended phone types and the installation conditions, especially when using tags near metal. Keep labels readable and tags securely attached using a method appropriate for the product. Replace damaged carriers through a controlled process and review retired or revoked identifiers. Finally, a working web link is not automatically a GS1 Digital Link. Standards-based identifier syntax and resolver behaviour need their own validation.

6. Prepare, review and publish the passport

A passport brings the product information into a governed presentation for its intended audience. Open the linked passport from the asset or use Passports in the navigation. Check that the passport belongs to the correct physical asset and uses the intended template. Review source values, required fields, presentation and supporting evidence before publication. A filled-field count helps you see whether information is present, but it does not prove that the values are correct or sufficient for a regulation. The example screen distinguishes the working tree from the published experience. It also provides a publication workspace. Use the publication process to review and release the intended version according to your organisation's responsibilities. Publication makes information available through the configured passport experience; it should follow a deliberate approval decision. Our existing example is already published. Its fields are read only, and the interface offers Correct Passport to open the next draft version on the same identity. The current published version remains in place until a later publication step. This separation helps prevent an unfinished correction from being mistaken for approved public information. Published Passport Evidence is associated with the published version. Before release, confirm both the content and the access boundary for every document. Internal evidence should not become public simply because it is useful to an administrator. After publication, open the public passport and check it as a recipient would.

7. Maintain lifecycle evidence and public access

The passport becomes more useful when it stays connected to events and evidence throughout the product's life. On the asset record, Lifecycle and Proof includes Lifecycle Events and Supporting Documents. Use the appropriate event type and link the event to the correct physical item. Record what happened, when it happened and the supporting evidence under your organisation's controlled process. The interface distinguishes Current or Effective records from Complete History. When a correction is needed, preserve the history and review which record is currently effective. Supporting documents on an asset and evidence published with a passport serve different purposes. Adding a file internally does not mean the public can see it. Check the publication and visibility decisions separately. The public passport organises the experience into Overview, Trace, Lifecycle, Proof and Care. Overview identifies the item. Trace shows how the product, physical asset, identifier and published passport connect. Lifecycle contains the public events made available for that product. Proof contains published supporting evidence, and Care contains published guidance. Our test example explicitly shows that no public lifecycle records or evidence have been published. That is a useful reminder: a section heading does not mean evidence exists. Before sharing a passport, verify the visible information, document permissions and the destination opened from the real QR code or NFC tag.

8. Use Trace in a DPP readiness programme

UniQorn Trace provides a practical workflow for product identity, structured information, linked evidence, controlled passport publication and lifecycle records. These are useful building blocks in a Digital Product Passport programme. Regulatory conformity still requires a product-specific assessment. Under the Ecodesign for Sustainable Products Regulation, the applicable delegated acts determine the detailed passport obligations for the product groups they cover. Separate legislation can set different obligations for other products, including batteries. Do not assume a single deadline or a universal field list applies to every manufacturer. Begin by identifying the applicable legislation, product scope, required identity level, data fields, access rights and implementation dates. Then map each requirement to a verified capability, a configured process and supporting test evidence. Standards-based identification, machine-readable exchange, retention, continuity, backup arrangements and any required registry connection must be assessed explicitly. They are not demonstrated by a QR code opening a page. For this platform, GS1 and Digital Link readiness work remains subject to the separate validation programme. This training does not claim that work is complete. A sensible pilot starts with one product family, named data owners, an approved field set and a small number of representative items. Test the complete chain from source data to the physical carrier and recipient view. Review corrections and document visibility, resolve gaps, and then expand. To discuss a pilot, contact UniQorn Systems through the website. Thank you for watching this end-to-end guided tour of UniQorn Trace.

Digital Product Passports · A practical manufacturer guide

From product records to a passport people can trust.

A Digital Product Passport connects a physical product to useful, governed information. UniQorn Trace™ brings product models, serialised items, identifiers, evidence and published passports into one connected workflow.

Manufacturers already hold much of the information their customers need: specifications, certificates, material records and service history. The difficulty is finding the right information for the right product, knowing which version is current and sharing it with the appropriate audience. A DPP programme makes those responsibilities explicit.

This guide explains the regulatory context and shows how UniQorn Trace supports the operating process. The accompanying video uses live platform screens and existing test records. It is a guided tour, with practical checks for administrators and record owners.

What is a Digital Product Passport?

A Digital Product Passport is a digital record linked to a product through an identifier and a data carrier. Depending on the applicable rules and product group, it can provide product identity, material and environmental information, instructions, compliance information and other lifecycle data. Its usefulness depends on trustworthy sources, clear responsibilities and appropriate access. [1]

The physical carrier is the entry point. The information system behind it must identify the correct product and make the intended information available. A QR code that opens a marketing page can be useful, but that alone does not demonstrate that a regulated DPP requirement has been met.

Why this matters beyond compliance

A well-managed product record can reduce time spent locating certificates, clarify which item an event belongs to and help customers retrieve information after delivery. Manufacturers can begin with these practical needs while preparing for the requirements relevant to their products. Those benefits should be measured in a pilot rather than assumed.

What does ESPR require?

Regulation (EU) 2024/1781 establishes the Ecodesign for Sustainable Products Regulation framework. The applicable product-specific delegated acts determine detailed DPP obligations, including the information, identification level, carriers and access arrangements for the products covered. The regulation requires passport data to be accurate, complete and up to date. There is no single generic field list or implementation date that can safely be applied to every manufacturer. [2] [3]

A readiness assessment must therefore start with the product and applicable legislation. Batteries and other product groups can also fall under separate legislation. Do not treat a general ESPR readiness exercise as completion of a battery-passport assessment.

Technical and operational requirements also matter: identity persistence, appropriate access, interoperable information, data integrity, availability and continuity must be considered alongside the visible passport page. The applicable legislation and standards remain the acceptance criteria.

How UniQorn Trace connects the work

The platform follows a clear relationship: Product Master → Serialised Asset → Identifier → Passport → Lifecycle / Proof. The model record, physical item, scan link and published information each have a distinct role. Keeping those roles separate reduces the risk of attaching an item's history to an entire product range.

1. Start with the organisation and responsibilities

Users sign in to a provisioned account, select the appropriate organisation and open its Trace workspace. The dashboard brings together the connected record estate. Before onboarding products, agree who owns source data, who reviews evidence and who authorises publication. Access to a workspace should reflect those responsibilities.

2. Configure the information structure

Field Definitions and Product Templates provide reusable structure. Product Types help organise the catalogue. Passport Templates organise and present source information for the passport. Agree definitions, units and source systems before collecting data. A field labelled “recycled content” needs a clear calculation basis and evidence; a field name alone does not establish reliability.

3. Define the model in Product Masters

A Product Master holds the reusable model-level definition. It can reference the appropriate product and passport templates. Maintain shared product properties here, using controlled specifications. Check for an existing model before creating another one. Serial numbers belong downstream on individual assets.

4. Register each physical instance

Serialised Assets represent individual items created from a Product Master. The creation form includes a required serial number and fields for batch, manufacture date, operational status and notes. Check the item marking against the record. The registration date in Trace is distinct from the manufacture date, and an application status does not establish technical conformity or safe use.

5. Connect identifiers and physical carriers

Identifiers are issued against the asset. QR and NFC workflows can link a physical item to the intended resolver and published passport. Confirm the destination before printing a label or programming a tag. After attachment, test the actual item with the intended reader or phone and compare the displayed serial number. Physical tag programming, durability and mounting require their own controlled process.

6. Review and publish the passport

The passport workflow distinguishes working information from a published version. The observed published example is read only and offers a controlled correction into a later draft. Review the asset relationship, values, evidence and audience before release. Field completeness is a preparation check, not a legal conformity verdict.

7. Maintain events, evidence and the recipient experience

The asset record provides Lifecycle Events and Supporting Documents, with views for current/effective records and complete history. Published Passport Evidence is associated with the passport version. These distinctions matter: internal storage and public availability are separate decisions. The public experience organises information into Overview, Trace, Lifecycle, Proof and Care. Empty public sections should remain explicit rather than imply that supporting evidence exists.

How this supports DPP requirements—and what still needs verification

Requirement area	Trace contribution observed	Deployment verification
Product identity	Product Masters, Serialised Assets and linked identifiers	Required model/batch/item level, identifier standards, uniqueness and persistence
Structured product information	Field Definitions, Product Templates and source mapping	Mandatory fields, definitions, units, data quality and machine-readable exchange
Access through a carrier	Identifier resolver and public passport experience	Permitted carriers, placement, durability, accessibility and applicable standards
Controlled publication	Published version, read-only state and correction workflow	Approval responsibilities, audit behaviour and all required access rights
Evidence and lifecycle information	Asset events/documents and version-associated passport evidence	Authenticity, retention, visibility, updates and obligations of relevant actors
Continuity and external infrastructure	Not established by this guided tour	Availability, backup, portability, service continuity and any required registry connection

The table describes a contribution to a readiness programme. It does not turn an interface observation into a conformance test. Each requirement should have an owner, an acceptance criterion and evidence of the resulting behaviour.

Where GS1 Digital Link fits

GS1 Digital Link provides a standard way to represent GS1 identification keys in web addresses. URI syntax and GS1-conformant resolution are related but distinct subjects. A URL that follows the identifier syntax is not, by itself, proof of a conformant resolver. [4]

For a manufacturer using GS1 identifiers, validate the assigned identifiers, their representation, the intended resolution behaviour and the required information exchange. UniQorn's separate GS1/Digital Link readiness work remains to be completed and evidenced; this guide does not present that work as finished.

Start with one product family

Choose a representative family and define its regulatory scope. Agree the identity level and field set, identify authoritative sources and name the data owners. Configure templates, onboard a small set of items and test the chain from source record to physical carrier to recipient view.

Include deliberate review of incorrect or missing values, passport corrections and private-versus-public evidence. Confirm the behaviour against the requirements, record the gaps and resolve them before expanding. Measure practical outcomes such as record completeness, retrieval time, successful carrier reads and publication errors.

UniQorn Trace gives that work a connected operating structure. A successful DPP programme combines the platform with reliable source data, clear ownership and demonstrable fulfilment of the rules that apply to the product.

Discuss a UniQorn Trace pilot

Primary sources

Prepared 18 October 2026. Training uses existing test records. Regulatory application must be assessed for the specific product and deployment.