ActivateDigital Knowledge
Data Home
Where product facts belong, who owns them and what happens when they change
A passport is a published view of facts you already govern, not a second product master. Each fact needs a value, a scope, evidence and a time. Get those right and the passport follows from them.
- Last verified
- · 20 answers in this home
01 · How it fits together
Six questions behind every passport
Open one for the rule.
1IdentityWhat is this product, in each system?
An identifier is a namespace and a level, not just a number.
- GTIN, ERP material ID, PIM record ID and ecommerce SKU can point at the same product while describing different scopes.
- Mappings can be one-to-many, many-to-one, time-bounded or have no safe match.
2ScopeAt what level is this fact true?
The product rule sets the level. Your SKU does not.
- Under ESPR the product-specific rules can specify whether passport data refers to a model, batch or item.
- A lower-level exception to a model value needs its own reason and evidence.
3OwnerWhich system is the authority?
A destination is not automatically the authority.
- A PIM can be the controlled publishing layer without being the original authority for every fact.
- Settle a conflict on the evidence, not on which system ranks higher.
4EvidenceWhat proves the value?
Every value needs evidence for the scope and time it claims.
- Latest upload wins, supplier document wins and PIM wins are unsafe defaults.
- An unresolved conflict stays conflicted or UNKNOWN.
5ChangeWhat happens when it changes?
Not every change is the same kind of change.
- A correction is handled differently from a new sellable configuration or an identity-level change.
- Which changes create a new passport is not settled by any universal rule.
6PublishWhat does the passport show?
The passport is a view, not a second product master.
- Receiving the latest copy of a value does not make it the truth.
- The Registry registers each passport's identifier and metadata. The data itself is decentralised.
02 · The decisions
Six calls every product data team makes
03 · Your route
Start from where you are
Spreadsheets or Shopify
You hold more than you think.
ERP and PIM in place
The job is ownership, not another system.
IT and architecture
Standards, events and exchange.
Compliance and quality
From the technical file to governed facts.
See what your own product's passport would look like
Give us one product. We work out what applies and ask only what we cannot resolve.
Keep up when a date moves
Every change we record, with the date and the page it changed.
See every change04 · Everything in this home
The full map
Product data
- What Is a Data Space, and How Does Catena-X Fit DPP Architecture?
- Digital Product Passport vs Digital Twin vs Asset Administration Shell (AAS)
- What Do EPCIS Events Add to Product Master Data?
- Product Data Across EU Systems: What Can Be Reused and What Must Stay Separate
- Lot, Serial or Item: Which Identity Level Does an Operational Use Case Need?
- How Do You Preserve Material Lineage After Cutting, Splitting or Transformation?
- Which Product Facts Belong at Model, Variant and SKU Level?
- When a Product Changes, Do You Overwrite the Fact, Version the Record or Create a New Product?
- How Do Companies Exchange Product Carbon Footprint Data? PACT and Versioning
- What Is Product Data Syndication? How Product Data Becomes Retailer Feeds
- How to Organise Product Data Without a PIM: A Small-Business Operating Model
- Your Technical File Holds Compliance Evidence. Which Parts Should Become Governed Product Data?
- What Is the UN Transparency Protocol (UNTP), and How Does It Work?
- Which System Should Own Each Product Fact?