Knowledge BaseDigital Product Passports

What Data Goes in a Digital Product Passport, and Where Does It Come From?

Executive Summary

Two questions come up in almost every early Digital Product Passport conversation, and they are almost always answered as if they were one question. The first is what information does the passport need to carry. The second is where does that information come from. Confusing them produces the two most common early mistakes: assuming that a single system already holds everything the passport needs, and assuming that nothing can start until a new system holds everything the passport needs.

Neither is true. A passport is a governed publication of information that has been assembled from several places. Some of that information describes the product as it was designed. Some of it describes how a particular batch was actually made. Some of it was never yours to begin with: it was supplied by a component manufacturer, measured by a laboratory, or attested by a certification body. Some of it will only exist after the product is sold, because it records something that happened to that specific item later in its life.

This article separates those two questions and keeps them separate. It introduces the Passport Data Origin Model, a tieback educational model that puts what the passport needs on one axis and where the information comes from on the other, and then adds the two things that decide whether the result can be trusted: which source is authoritative when several disagree, and what evidence supports each claim.

It is written for a reader who has never used, and may never use, a PLM, ERP, PIM or MES system. All of those terms are explained in ordinary language where they appear. A small manufacturer working from spreadsheets, supplier emails and PDF certificates has exactly the same information problem as a multinational with fifteen systems. The technology differs. The governance question does not.

The legal shape matters too, and it is easy to overstate. Regulation (EU) 2024/1781, the Ecodesign for Sustainable Products Regulation, establishes the passport framework. It does not publish one universal dataset that every product must carry. What a specific product must include is set by the product-specific rules that apply to it. This article therefore describes categories of information that a passport can contain, not a checklist that every passport must contain.

FrameworkTBF-042
The Passport Data Origin Model

A matrix model that separates what information a Digital Product Passport needs from where that information actually comes from. Ten rows describe categories of passport information: product identity and reference data, composition and materials, manufacturing and production data, supplier provided data, compliance and conformity information, certificates and declarations, sustainability and environmental information, lifecycle and event data, and the conditional categories of repair and service information and end of life and circularity information. Each row is read across three further columns: typical origins expressed as functions rather than product names, including product lifecycle management, enterprise resource planning, product information management, manufacturing execution and production records, supplier portals and submissions, compliance and evidence repositories, laboratory testing and certification sources, traceability and event systems, service and repair systems and manually maintained or externally supplied records; the authority for that category, which may be the manufacturer, the production site, the supplying organisation, the issuing body, the economic operator carrying the legal duty, or the party that observed an event; and the kind of evidence, if any, that typically supports the claim. A publication band beneath the matrix records that assembled information passes through governance, validation and evidence checks before publication, and that publication does not transfer authority away from the sources. The model rests on seven distinctions: passport data is not one database, it is not whatever the enterprise resource planning system holds, a source system is not automatically the system of record, data is not evidence, product data is not lifecycle event data, required information is not the source of information, and the data carrier, the product identifier and the passport data are three different things. It also separates framework level requirements under Regulation (EU) 2024/1781 from product specific requirements and from implementation choice, and states explicitly that no universal Digital Product Passport dataset exists. It consumes the product information readiness model TBF-003 for passport content without restating it, defers authority resolution to the enterprise source of truth model TBF-027, master data management model TBF-028 and golden record lifecycle TBF-029, defers governance, quality and stewardship to TBF-023, TBF-025 and TBF-026, hands validation to TBF-033 and evidence management to TBF-034, and hands large estate layering to the enterprise reference architecture TBF-030. It is written to remain usable by organisations with no enterprise systems at all, treating controlled spreadsheets, supplier documents and manual production records as legitimate origins subject to the same governance.

Table of Contents

Definition

Definition
Digital Product Passport data

The set of information published through a Digital Product Passport for a given product, batch or item, assembled from several distinct origins rather than held in one place by default. It includes identity and reference information about the product, descriptive information such as composition and materials, information about how a particular unit was produced, information contributed by suppliers, compliance and conformity information, sustainability information, and information about events that occur across the product lifecycle. Each element has an origin, an authoritative source, a responsible party, a validation status and, where a claim requires it, supporting evidence. The passport is the governed publication of that assembled information, not necessarily a new database that replaces the sources.

Three parts of that definition carry the weight.

Assembled. Passport information is gathered from places that already exist. Creating a passport is usually an exercise in collection, reconciliation and governance rather than invention.

Governed. Assembly alone produces a pile of values of unknown reliability. What makes it a passport is that someone has decided which value is correct, who is accountable for it, and what supports it.

Publication. The passport is a published view intended for a defined audience. That is a different thing from the internal records it draws on, which continue to exist, continue to change, and are not usually published in raw form.

Why Passport Data Confuses People

The word “data” flattens everything. A product name, a percentage of recycled content, a test result, a certificate, a shipment record and a repair log are all called data, but they behave completely differently. Some are stable for years. Some change per batch. Some are legal attestations by third parties. Some do not exist until an event happens.

People picture one database. The mental image of a passport is a single record, so the assumed implementation is a single table someone fills in. The reality is a set of pointers into information owned by different teams, different systems and different companies.

Enterprise vocabulary arrives too early. Discussions jump to ERP, PIM, PLM and MES before anyone has agreed what information is needed. Those are categories of software, and they are useful shorthand inside large companies, but they are not the definition of the problem and they are not a prerequisite for solving it.

Requirement and source get merged. “We need recycled content” and “recycled content lives in the supplier declaration folder” are answers to different questions. Merging them hides the fact that one requirement may be satisfied by several possible sources, with different reliability.

Evidence is assumed to be the same thing as the value. A number in a field and a document supporting that number are related but separate. A passport can show a value that no one can substantiate. That is a governance failure, not a data-entry failure.

Tip

Before choosing any system, write two lists on separate pages. Page one: the information the passport has to show. Page two: every place that information could come from. Do not draw lines between them yet. Most programmes that start with one merged list end up designing a database instead of understanding their information.

Seven Distinctions That Prevent Most Mistakes

These seven separations resolve the majority of early confusion. Each one is a pair of things that are routinely treated as identical and are not.

Passport data is not one database. The information is normally distributed across systems, documents and organisations. A passport platform may store a published copy, but that copy is downstream of sources that remain authoritative in their own right.

Passport data is not whatever is in the ERP. An ERP system, meaning the system a company uses to run transactions such as purchasing, inventory and finance, holds a specific slice of product information. It typically knows a product exists, what it costs and how it moves. It usually does not know the fibre composition, the durability test result, or the recycled content of a component.

A source system is not automatically the system of record. A value can appear in five systems. Only one of them should be the designated authority for it, and that designation is a governance decision, not an accident of which system happens to display it most prominently. This is examined in depth in What Is a System of Record?.

Data is not evidence. “Recycled content is 30%” is a claim. A supplier declaration, a certificate, or a test report is potential evidence supporting that claim. The passport may publish the claim; the organisation must be able to substantiate it.

Product data is not lifecycle event data. “This model is made of 60% recycled polyester” describes a design. “This unit was repaired on 14 March” describes something that happened to one item. The first is stable and shared across many units. The second is specific, time-stamped and only exists after the fact.

Required information is not the source of information. The applicable rules determine what must be shown. They do not determine which of your systems supplies it. Two companies with identical legal obligations may draw the same attribute from entirely different places.

The data carrier, the product identifier and the passport data are three different things. The data carrier is the physical thing that is scanned, such as a QR code. The product identifier is the code that uniquely names the product, batch or item. The passport data is the information that is reached by using them. A correct carrier printed on a product with no governed information behind it is a label, not a passport.

Common Mistake

Buying a passport platform and then asking what to put in it. The platform is the publication and governance layer. It cannot tell you which of your suppliers actually knows the recycled content of a component, and it cannot invent a test result that was never produced.

The Passport Data Origin Model

The Passport Data Origin Model is a tieback educational model. No EU instrument defines it. It exists to keep two questions apart while showing how they connect.

The model is a matrix, not a flow. Down the left are the categories of information a passport may need. Across each row are three further columns: where that category typically originates, who is authoritative for it, and what kind of evidence, if any, typically supports it. Reading a single row answers a complete question: this information, from these origins, governed by this authority, supported by this evidence, published in the passport.

Reading down a column answers a different and equally important question: which parts of the passport depend on suppliers, which depend on production systems, and which depend on records that will not exist until the product is in use.

The rows are categories, not a mandatory dataset. A given product may need three of them or nine. The origins are categories too, deliberately described by what they do rather than by product names, so that the model applies to a company with one spreadsheet and to a company with forty systems.

What the Passport Needs

The ten sections that follow describe each row of the model. Read them as a vocabulary of possible content, not as a specification. No product needs all ten, and the applicable rules for a product group decide which ones matter and in what detail.

Product Identity and Reference Data

This is the information that says which product this is. A model name, a manufacturer, a product category, a model number, a unique product identifier, and where relevant a batch number or a serial number.

It is the least glamorous category and the one that fails most often, because it is assumed to be solved. Most organisations discover that the “same” product has three names, two article numbers and an inconsistent category depending on which department is asked.

Reference data is a related idea: the shared lists that give the values meaning. Units of measurement, country codes, material names, product category codes. If one system records a mass in grams and another in kilograms without saying so, the passport will publish a number that is wrong by a factor of a thousand.

This category is normally the most stable, changes rarely, and is the natural foundation for everything else. It is examined in detail in What Is Product Master Data?.

Composition and Materials

What the product is made of. Materials, substances of interest, component structure, and where relevant proportions such as fibre percentages or recycled content.

Two things make this category harder than identity data. First, much of it is not known by the company selling the product: it is known by the company that supplied the component or the fabric. Second, it may be recorded as a design intent rather than as a measured fact. A specification saying a fabric should be 60% recycled polyester is a requirement placed on a supplier. It is not, by itself, proof of what was delivered.

The structure that lists what goes into a product is commonly called a bill of materials. In a large organisation it usually lives in a product lifecycle management system, meaning the system where designs and specifications are developed and versioned. In a small organisation it may be a spreadsheet. The governance question is the same in both: which version is current, and who is allowed to change it.

Manufacturing and Production Data

Information about how a particular batch or unit was actually made: the production site, the production date, the batch identity, process parameters where relevant, and quality control results.

This is the first category that is genuinely per-unit or per-batch rather than per-model. It is also where the difference between the design and the reality shows up. Two batches of the same model may have been made in different factories from different supplier lots, which means their passports may legitimately carry different values for the same attribute.

Large manufacturers often capture this in a manufacturing execution system, meaning software that records what happens on the production line. Smaller manufacturers, and companies that outsource production entirely, usually receive it as production records from the site that did the work.

Tip

If a value can differ between two batches of the same model, it belongs to the batch, not to the product. Deciding this early prevents the single most expensive rework in passport programmes: discovering after launch that a per-model field should have been per-batch.

Supplier-Provided Data

Information that originates outside the organisation publishing the passport. Component specifications, material content, substance information, environmental figures, certificates and attestations relating to supplied items.

This is usually the largest gap in a first passport programme, for a simple reason: the information was never requested before, because nothing depended on it. Suppliers vary enormously in what they hold, how quickly they can provide it, and how reliable it is. Some will answer with a laboratory report. Some will answer with an email.

Two governance points matter more than the collection mechanism. First, a supplier response is a statement by the supplier, and its authority rests with them. Second, the organisation publishing the passport is normally the one answerable for the published claim, which is why supplier data needs validation rather than direct pass-through. Preparing suppliers is a discipline in its own right and is covered in How to Prepare Suppliers for Digital Product Passports.

Compliance and Conformity Information

Information relating to the product’s regulatory status: applicable legislation, conformity assessment outcomes, declarations of conformity, marking information, and references to technical documentation.

This category is different in kind from the others. It is not a description of the product. It is a statement about the product’s legal position, made by a party who carries a legal duty. That party is the authority for it, and the underlying records normally sit in a compliance or regulatory function rather than in a product data system.

The relationship between passports and conformity assessment is set out in How Conformity Assessment Works for Digital Product Passports, and legal responsibility is examined in Who Is Legally Responsible for a Digital Product Passport?.

Certificates, Declarations and Supporting Evidence

Documents issued by identifiable parties that support claims: certificates from certification bodies, test reports from laboratories, supplier declarations, and inspection results.

The critical property of this category is that the document is not the claim. A certificate has a scope, an issue date, an expiry date, an issuing body and a subject. A certificate that covers a different facility, a different material grade or an expired period does not support the claim being made, even though it is a genuine certificate. Managing this properly is the subject of How to Manage Evidence for Digital Product Passports.

Sustainability and Environmental Information

Environmental characteristics of the product: recycled content, durability, repairability, environmental footprint figures, and similar measures where they apply.

This category has a distinctive risk. The values look like simple numbers but they are the output of a method. A carbon figure calculated with one set of boundaries and assumptions is not comparable with a figure calculated with another, and publishing it without the method is publishing an unfalsifiable number. The method, the boundary, the reference period and who performed the calculation are part of the information, not metadata about it.

Sustainability data is also the category most likely to be sourced from outside: from suppliers, from environmental data providers, or from a study performed by a consultancy. Its authority therefore depends on who produced it and how, which is why the model does not assign a single owner to this row.

Lifecycle and Event Data

Information about things that happened to a specific product or batch after it was made: shipment, receipt, transformation, sale, repair, return, or treatment at end of life.

Event data has three properties that distinguish it sharply from product data. It is time-stamped. It is observed by a party, who may not be the manufacturer. And it accumulates: a product does not have a single event record, it has a growing history.

That accumulation raises questions the other categories do not: how long the history is retained, who can see which parts of it, and whether it is published in the passport at all or simply available to authorised parties on request. Event data is often the largest volume in a passport programme and the least likely to be needed in full by every audience.

Repair and Service Information

Where it applies, this covers the information that supports keeping a product in use: repair instructions, spare part identification and availability, service history, and diagnostic information.

The authority splits neatly here, which makes it a useful example. Instructions and part identification come from the manufacturer, who designed the product. Records of work actually performed come from whoever performed it, which may be an authorised service network, an independent repairer, or the owner. A passport can carry both, and they are not interchangeable.

This category is not universal. It is relevant where the product is repairable and where the applicable rules or commercial purpose make the information worth publishing.

End-of-Life and Circularity Information

Where it applies, this covers what should happen to the product when it is no longer used: disassembly guidance, material separation information, hazardous substance handling, take-back arrangements, and records of treatment where they exist.

The same split applies. Guidance is authored by the manufacturer in advance. Outcomes are recorded by the operator who actually handled the product, often years later and often in a different country. Most passport programmes publish the guidance long before any outcome data exists, which is a normal and acceptable state.

Where the Information Comes From

The origins below are described by function, not by product. An organisation may have all of them, some of them, or a spreadsheet that plays several of these roles at once. None of them is required in order to produce a passport.

Product lifecycle management, commonly abbreviated to PLM. Where designs, specifications, component structures and engineering changes are developed and versioned. Typically authoritative for composition and specification.

Enterprise resource planning, commonly abbreviated to ERP. Where the commercial and operational transactions happen: purchasing, inventory, production orders, finance. Typically authoritative for commercial identity, units and supplier relationships, and often mistakenly assumed to know more about the product than it does.

Product information management, commonly abbreviated to PIM. Where customer-facing product descriptions, attributes and media are curated for publication to channels. Typically authoritative for descriptive and marketing attributes, and frequently confused with a source of compliance truth.

Manufacturing execution systems and production records. Where production is recorded as it happens. Typically authoritative for batch identity, production site and date, and process results.

Supplier systems and supplier submissions. Portals, questionnaires, structured file exchanges and plain documents. Authoritative in the sense that the supplier is the origin of the statement, but requiring validation before publication.

Compliance and evidence repositories. Where declarations, technical documentation and regulatory records are held. Typically authoritative for the product’s regulatory position.

Laboratory, testing and certification sources. Where measurements and attestations are produced by parties whose independence is part of their value. Authoritative for the specific scope they tested or certified, and no wider.

Traceability and event systems. Where movements and transformations are recorded across organisations. Authoritative for what was observed, by whoever observed it.

Service and repair systems. Where work performed on individual items is recorded.

Manually maintained and externally supplied records. Spreadsheets, controlled documents, emailed declarations and scanned certificates. These are legitimate origins. They carry higher risk of version confusion, which is a reason to control them, not a reason to dismiss them.

The differences between the three most-confused categories are set out in ERP vs PIM vs PLM, and how information moves between organisations is covered in How Enterprise Systems Support Digital Product Passports.

Common Mistake

Treating the system that displays a value most conveniently as the system that owns it. Convenience is a user-interface property. Authority is a governance decision. The two coincide by luck, not by design.

If Several Systems Disagree, Which One Wins?

This is the question that separates a data collection exercise from a passport programme, and it arrives the moment two systems show different values for the same attribute.

The answer is never “the newest one” or “the one we happened to query”. It is a decision made in advance, recorded, and applied consistently: for this attribute, this source is authoritative, this person is accountable, and disagreements are resolved this way.

That decision is the subject of an established body of practice, and this article deliberately does not restate it. Four articles cover it directly:

The only point this model adds is the one it makes structurally: authority is a separate column from origin. A value can originate from a supplier email and still have a properly designated authority, and a value can originate from an expensive system and have none.

Data Is Not Evidence

A claim is a statement the passport makes. Evidence is what supports it. They travel together and they are not the same thing.

Example
One claim, several possible forms of evidence

Claim published in the passport: recycled content is 30%.

Possible supporting evidence, depending on the context and the applicable rules:

  • a declaration from the material supplier stating the recycled content of the material supplied;
  • a certificate issued by a certification body covering the material or the supply chain;
  • a test result from a laboratory analysing the material;
  • production and purchasing records demonstrating what was actually input into the batch.

None of these is universally sufficient. Which is appropriate depends on the claim, the product, the applicable requirements and the level of assurance needed. A declaration that covers a different material grade, or a certificate that expired before the batch was produced, supports nothing at all regardless of how official it looks.

The practical consequence is that every published claim should have a known evidence position, and “none required” is a legitimate position when it has been decided rather than assumed. The mechanics of checking values are covered in How to Validate Digital Product Passport Data, and the mechanics of holding the supporting documents are covered in How to Manage Evidence for Digital Product Passports.

Best Practice

Record the evidence position alongside the value, not in a separate folder: what supports this, who issued it, what scope it covers, when it expires, and who accepted it. An organisation that can answer those five questions for every published claim is in control of its passport. One that cannot is publishing hope.

What the Law Actually Fixes

Three levels need to stay distinct, because conflating them is how programmes end up building against requirements that do not apply to them.

Framework-level requirements. Regulation (EU) 2024/1781, the Ecodesign for Sustainable Products Regulation, establishes the Digital Product Passport as a framework: that passports exist, that they are connected to products through a data carrier and a unique product identifier, that information is made available to defined actors, and that requirements will be set for particular products. The framework does not publish one universal dataset for all products.

Product-specific requirements. What a specific product must actually carry is determined by the measures adopted for that product group under the framework, or by other legislation applying to that product. Regulation (EU) 2023/1542 on batteries is a separate instrument with its own passport requirements, which illustrates that passport obligations do not arrive from a single place. This article does not speculate about which requirements will apply to which product groups or when; that question is tracked in When Will Digital Product Passports Become Mandatory?.

Implementation choices. Which system supplies an attribute, how supplier data is collected, where evidence is stored, and what software is used are decisions belonging to the organisation. They carry no legal force in themselves. Two compliant companies can make entirely different choices.

Common Mistake

Building an internal “DPP data model” from a generic list found online and treating it as the legal requirement. Generic lists are useful as a starting vocabulary. They are not the applicable rules for a product, and they usually mix framework concepts, product-specific requirements from unrelated sectors, and one vendor’s preferences.

Practical Example: Tracing a Passport Backwards

A useful exercise is to take a small number of attributes from a finished passport and walk each one backwards through the model: from the published information, to the authoritative source, to the original contributor, to the validation and evidence, and back to publication.

Example
A cotton and polyester T-shirt, four attributes traced backwards

Attribute 1: product model name and identifier.

Passport information: the model name, the manufacturer and a unique product identifier. Authoritative source: the brand’s product master record. Original contributor: the brand’s own product team, when the style was created. Validation and evidence: internal control only; no external evidence is involved. Publication: stable across every unit of the style.

Attribute 2: fibre composition, 60% cotton and 40% recycled polyester.

Passport information: the composition percentages. Authoritative source: the specification held by the brand, reconciled against what the mill actually supplied. Original contributor: the fabric mill, which is a supplier the brand may not even buy from directly if the garment factory sources the fabric. Validation and evidence: a supplier declaration for the material, potentially supported by a certificate or a test report where the recycled claim requires it. Publication: may differ between production runs if the fabric source changed.

Attribute 3: country of manufacture and production batch.

Passport information: where and when this batch was made. Authoritative source: the production records of the garment factory. Original contributor: the factory, which is a separate legal entity from the brand in most cases. Validation and evidence: batch and quality records held by the factory. Publication: differs per batch by definition, and cannot be a per-model value.

Attribute 4: care and repair information.

Passport information: how to wash, and how to repair or have the item repaired. Authoritative source: the brand’s technical and product documentation. Original contributor: the brand’s product team, informed by the mill’s material guidance. Validation and evidence: internal review; the mill’s guidance where the care instruction depends on the fabric. Publication: stable, but updated if guidance changes.

What the example shows. One simple garment, four attributes, and already four different sources across three organisations, with two attributes that vary per batch and one that depends on evidence from a company the brand may have no direct contract with. Nothing about this is exotic. It is the normal shape of passport data, and it is why “which system will hold the passport” is the wrong first question.

Small Organisations Without Enterprise Systems

A small manufacturer reading the previous sections may reasonably conclude that a passport requires a software estate it does not have and cannot afford. It does not.

None of PLM, ERP, PIM or MES is a legal prerequisite. They are ways of organising information at scale. The same information can legitimately originate from:

  • spreadsheets, provided there is one controlled current version rather than seven emailed copies;
  • accounting or inventory software, which most businesses already run;
  • supplier documents, including declarations and specifications received by email;
  • certificates and test reports held as files, provided their scope and validity are tracked;
  • controlled manual records, such as a production log kept per batch;
  • purpose-built passport software, which can supply the governance and publication layer without replacing any of the above.

What does not change is the governance. Whatever the tools, someone must be able to say which value is current, who is responsible for it, what supports it, and when it was last checked. A small organisation often does this better than a large one, because the answer is one person rather than a committee, and the sources number five rather than fifty.

Best Practice

For a small organisation, a single controlled spreadsheet with named owners per attribute, a folder of supplier documents named by scope and expiry, and a fixed review date is a defensible foundation. Add software when the manual effort becomes the constraint, not before. Buying a system does not create governance; it only enforces the governance you already decided.

Large Organisations With Fragmented Data

Larger organisations face the mirror image of the problem. Almost none of the information is missing. Nearly all of it exists somewhere, several times, in incompatible forms, owned by people who have never met.

The characteristic symptoms are consistent: the same attribute in four systems with three values; a definition that means something different in each region; supplier information held in a procurement folder that the compliance team cannot see; a product hierarchy that changed in one system and not in the others; and a genuine inability to say which figure is correct without convening a meeting.

The work here is not collection. It is reconciliation, designation of authority, and the operating model to keep it stable as products and suppliers change. That is exactly the territory of the Enterprise Systems & Data Architecture pillar, and in particular Building an Enterprise Digital Product Passport Architecture, which sets out how the layers fit together once the information itself is understood.

The important thing for a reader in a large organisation is to resist the instinct to solve this by building one more database. Another store of copied values with no designated authority makes the problem measurably worse, because it adds a fifth version that looks official.

How This Model Relates to the Others

This model is deliberately narrow. It answers where passport information comes from and who is authoritative for it. It does not replace the frameworks that handle the neighbouring questions.

FrameworkArticleWhat it covers that this one does not
TBF-003, The Product Information Readiness ModelWhat Information Does a Digital Product Passport Contain?The content of a passport and how ready each category typically is
TBF-020, The Product Data Foundation ModelWhat Is Product Master Data?The foundational product data layer itself
TBF-021, The Enterprise Product Data LandscapeERP vs PIM vs PLMWhat each class of enterprise system is actually for
TBF-022, The Enterprise Integration ModelHow Enterprise Systems Support Digital Product PassportsHow data moves between systems and organisations
TBF-023, The Trusted Product Data Governance FrameworkWhat Is Product Data Governance?Decision rights, policy and accountability
TBF-025, The Trusted Product Data Quality ModelWhat Is Product Data Quality?Measuring and improving the fitness of the data
TBF-026, The Product Data Stewardship ModelWhat Is Product Data Stewardship?The people and operating rhythm that maintain it
TBF-027, The Enterprise Source of Truth ModelWhat Is a System of Record?How authority over an attribute is designated
TBF-028, The Enterprise Master Data Management ModelWhat Is Master Data Management?The discipline of mastering shared data
TBF-029, The Golden Record LifecycleWhat Is a Golden Record?Producing one reconciled version from many
TBF-030, The Enterprise DPP Reference ArchitectureBuilding an Enterprise Digital Product Passport ArchitectureThe full architectural layering for large estates
TBF-033, The DPP Data Validation Control ModelHow to Validate Digital Product Passport DataChecking values before publication
TBF-034, The DPP Evidence LifecycleHow to Manage Evidence for Digital Product PassportsManaging supporting documents over time

Read positionally: TBF-003 says what the passport contains, this model says where it comes from, TBF-027 through TBF-029 decide which version wins, TBF-033 and TBF-034 decide whether it can be trusted, and TBF-030 arranges the whole thing for a large estate.

Common Mistakes

Assuming the ERP already has it. The transaction system knows what was bought, made and sold. It rarely knows fibre percentages, test results or environmental figures.

Starting a new master database as step one. Copying values into a new store without designating authority adds a version rather than resolving one.

Treating supplier answers as verified facts. A supplier statement is an origin with an owner. It is not automatically validated, and the publisher usually carries the answerability.

Publishing a per-batch value as a per-model value. The most expensive modelling error in passport programmes, because it is normally discovered after data has been published.

Storing evidence without scope and expiry. A folder of certificates that cannot be matched to a claim, a facility and a validity period is a filing exercise, not evidence management.

Publishing an environmental figure without its method. A number produced by an undisclosed methodology cannot be defended, compared or corrected.

Waiting for perfect data before starting. Categories mature at different rates. Identity data can be in good order long before supplier composition data is, and the sequencing is a normal part of a programme rather than a failure.

Frequently Asked Questions

What data goes in a Digital Product Passport?
It depends on the product and the rules that apply to it. The categories a passport can carry are product identity and reference data, composition and materials, manufacturing and production data, supplier-provided data, compliance and conformity information, certificates and declarations, sustainability and environmental information, lifecycle and event data, and where relevant repair and end-of-life information.

Is there one standard list of DPP data fields for all products?
No. Regulation (EU) 2024/1781 establishes the framework, and what a specific product must carry is determined by the requirements applying to that product group. Generic field lists circulating online are useful vocabulary, not applicable law.

Where does DPP data come from?
From several places at once: internal product and production records, supplier submissions, testing and certification organisations, compliance records, lifecycle participants such as logistics and service partners, and controlled manual records. One passport commonly draws on several organisations.

Does a Digital Product Passport need a new database?
Not necessarily. The passport is a governed publication of information assembled from authoritative sources. Many programmes publish from existing sources rather than replacing them, although a publication store is usually needed for the published version.

Can I create a DPP without an ERP, PIM or PLM?
Yes. Those systems organise information at scale, but they are not a legal prerequisite. Spreadsheets, accounting or inventory software, supplier documents, certificates and controlled manual records are legitimate origins provided the governance is real.

What is the difference between DPP data and evidence?
The data is the claim the passport publishes. The evidence is what supports that claim, such as a supplier declaration, certificate or test report. A claim can be published without evidence, and that is precisely the risk worth managing.

Who owns Digital Product Passport data?
Different parties originate different parts of it, and origin is not the same as authority or responsibility. The economic operator carrying the legal duty is normally answerable for the published passport, even where a supplier originated a value.

What is product master data?
The core, relatively stable information identifying and describing a product, shared across systems and processes. It is the foundation the rest of the passport hangs from.

What if two systems hold different values for the same attribute?
Designate one as authoritative for that attribute in advance, record the decision, and resolve disagreements through that designation rather than case by case.

Does supplier data need to be verified?
Supplier data should be validated before publication in proportion to the claim it supports. What counts as sufficient depends on the claim, the product and the applicable requirements.

Is lifecycle event data part of the passport?
It can be. Event data differs from product data in that it is time-stamped, observed by a party and accumulates over time, so whether and how much of it is published is a design and access decision.

Do small companies need enterprise software for DPP compliance?
No. The governance principle is identical regardless of the tools. A controlled spreadsheet with named owners and a tracked document folder is a defensible starting point.

Key Takeaways

Key Takeaways
  • What the passport needs and where the information comes from are two separate questions. Answering them together is the most common early mistake, and it produces database projects instead of information programmes. - A passport is a governed publication of information assembled from distributed sources. It is not, by default, a new master database, and building one without designating authority makes fragmentation worse. - There is no universal DPP dataset. The framework regulation establishes the passport; product-specific requirements determine what a given product must carry; everything else is an implementation choice. - Data is not evidence. A recycled content figure is a claim; a supplier declaration, certificate or test report is potential support for it, and no single form of evidence is universally sufficient. - Product data and lifecycle event data behave differently. One describes a design and is shared across units; the other is time-stamped, observed by a party and accumulates after the product exists. - Origin, authority, responsibility, validation and publication are five different concepts. A supplier can originate a value while the publisher remains answerable for it. - Small organisations do not need PLM, ERP, PIM or MES to hold defensible passport information. Large organisations usually have the information already and struggle instead with fragmentation, conflicting versions and unclear ownership. - The data carrier, the product identifier and the passport data are three different things. A QR code with no governed information behind it is a label.

References

About This Article

About This Article
Last Reviewed
2026-08-09
Next Scheduled Review
2027-08-09
Article Version
1.0

tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve.