> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # Building an Enterprise Digital Product Passport Architecture > A vendor neutral reference architecture for Digital Product Passports: seven layers from source systems to consumers, the cross-cutting capabilities that span them, and how master, lifecycle and evidence data flow without turning the passport into a new master database. ## Executive Summary The preceding articles in this pillar each explain one enterprise capability required to manage trusted product information: master data, the roles of ERP, PIM and PLM, enterprise integration, governance, maturity, quality, stewardship, systems of record, [master data management](/docs/knowledge-base/glossary/master-data-management) and Golden Records. Individually they are well understood. The difficulty organisations run into is not understanding any one of them, it is assembling them into something that can actually publish a [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) and keep it correct for years. This capstone article sets out **The Enterprise Digital Product Passport Reference Architecture**, a seven layer logical model running from source systems, through identity and authority, trust and governance, integration and orchestration, the passport service itself, and access and discovery, to the consumers who read the result. It also describes the capabilities that cut across every layer, such as security, privacy, auditability and regulatory change management, and the three distinct information flows the architecture has to carry: master and reference data, lifecycle and event data, and compliance and evidence data. One principle runs through the whole model. **A Digital Product Passport should not become a new enterprise master database.** It should consume, validate, assemble and publish trusted information from governed enterprise sources, preserving [authoritative source](/docs/knowledge-base/glossary/authoritative-source) ownership, attribute-level authority, governance, stewardship, traceability, evidence, lifecycle updates and controlled publication. Nothing in European product legislation requires an organisation to physically consolidate all product information into a single system, and programmes that attempt it usually discover they have built a second, unreconciled version of the truth. The architecture is deliberately logical rather than technical. It says what capabilities are required and how they relate, not which systems, products or deployment patterns should provide them. Federated, centralised and hybrid implementations of the same logical model are all legitimate, and the article explains the trade-offs rather than declaring a winner. Framework TBF-030 The Enterprise Digital Product Passport Reference Architecture Synthesises the enterprise data capabilities of TBF-020 to TBF-029 into a seven layer reference architecture, from source systems through identity and authority, trust and governance, integration and orchestration, the logical passport service and access and discovery to consumers, with cross-cutting capabilities and three distinct information flows, so a passport consumes and publishes governed information instead of becoming a new master database. ## Table of Contents * [Definition](#definition) * [Why Digital Product Passport Architecture Matters](#why-digital-product-passport-architecture-matters) * [The Enterprise Digital Product Passport Reference Architecture](#the-enterprise-digital-product-passport-reference-architecture) * [Architectural Principles](#architectural-principles) * [Layer 1: Source Systems](#layer-1-source-systems) * [Layer 2: Identity and Authority](#layer-2-identity-and-authority) * [Layer 3: Trust and Governance](#layer-3-trust-and-governance) * [Layer 4: Integration and Orchestration](#layer-4-integration-and-orchestration) * [Layer 5: Digital Product Passport Service](#layer-5-digital-product-passport-service) * [Layer 6: Access and Discovery](#layer-6-access-and-discovery) * [Layer 7: Consumers](#layer-7-consumers) * [Cross-Cutting Capabilities](#cross-cutting-capabilities) * [Master and Reference Data](#master-and-reference-data) * [Lifecycle and Event Data](#lifecycle-and-event-data) * [Compliance and Evidence Data](#compliance-and-evidence-data) * [How Information Moves Through the Architecture](#how-information-moves-through-the-architecture) * [Where the Digital Product Passport Should Sit](#where-the-digital-product-passport-should-sit) * [What the Digital Product Passport Should Not Become](#what-the-digital-product-passport-should-not-become) * [Architecture Patterns](#architecture-patterns) * [Architecture Anti-Patterns](#architecture-anti-patterns) * [Practical Enterprise Example](#practical-enterprise-example) * [Implementation Sequence](#implementation-sequence) * [Benefits](#benefits) * [Common Mistakes](#common-mistakes) * [Frequently Asked Questions](#frequently-asked-questions) * [Key Takeaways](#key-takeaways) * [Related Articles](#related-articles) * [Related Glossary Terms](#related-glossary-terms) * [References](#references) ## Definition An enterprise Digital Product Passport architecture is the arrangement of enterprise capabilities that allows an organisation to identify a product, determine which sources are authoritative for each item of information about it, govern and validate that information, assemble it into a publishable representation, publish it under control, make it discoverable through an identifier and data carrier, and keep it correct across the product lifecycle. It is a logical architecture: it defines required capabilities and their relationships, not a mandatory set of systems or a particular technical implementation. Three qualifications matter immediately. **It is an architecture, not an application.** The capabilities described here may be delivered by one system, by several existing enterprise systems working together, by external infrastructure, or by a combination. Two organisations can implement the same logical architecture with entirely different technology and both be correct. **It is enterprise architecture, not compliance tooling.** A passport draws on the same product information used for planning, sourcing, sales, service and reporting. Treating it as an isolated compliance application detaches it from the governance that makes the underlying information trustworthy, which is precisely the governance a regulator will ask about. **It is not a data consolidation programme.** The architecture assumes information stays where it is authoritatively managed and is assembled for publication. Consolidation is a possible tactic in specific places, not the goal. ## Why Digital Product Passport Architecture Matters Most passport programmes fail for architectural reasons rather than regulatory ones. The regulation is knowable; the information is scattered. **Because the obligation is continuous, not one-off.** A published passport is a standing representation that must remain accurate as products are revised, suppliers change, certificates expire and units move through repair, resale and recycling. A one-time data extraction cannot satisfy a continuing obligation, and a spreadsheet driven first release almost always becomes the constraint on the second. **Because information originates in many places.** As set out in [How Enterprise Systems Support Digital Product Passports](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports), specifications, commercial attributes, manufacturing records, supplier declarations and conformity evidence sit in different systems, owned by different functions, on different update cycles. The architecture exists to make that acceptable rather than to eliminate it. **Because publication removes tolerance for internal disagreement.** Internally, two systems holding two weights is an irritation. Published to market surveillance authorities, recyclers and consumers, it is a defect with a public audit trail. **Because scope will widen.** Requirements arrive product category by product category through delegated acts, as explained in [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts). An architecture built around one product family and one set of attributes tends to be rebuilt when the second arrives. **Because evidence must be producible.** Regulated claims must be defensible on request. That is an architectural property, expressed through lineage, provenance and audit trails, and it cannot be retrofitted convincingly after publication. > **Tip** > > A useful test of architectural readiness: choose one attribute already published somewhere in your > organisation and ask which system is authoritative for it, which rule selected the published > value, what evidence supports it, who owns it, and how a change reaches the published > representation. If any answer is missing, that gap is architectural rather than technical. ## The Enterprise Digital Product Passport Reference Architecture The reference architecture is a tieback educational model, not an external standard. It describes seven logical layers and the capabilities that span them. Layers are read as responsibility boundaries: each layer depends on the one below it and must not silently assume the duties of another. tieback Framework The Enterprise Digital Product Passport Reference Architecture Seven logical layers, the capabilities that cut across all of them, and the three information flows the architecture must carry. * L7 Consumers Who reads the published representation, and under which access rules * Consumers * Business partners * Repairers * Recyclers * Market surveillance * Regulators * Internal teams * Authorised systems * L6 Access and discovery How a physical product is connected to its published information * Product identifier * Data carrier * QR code * GS1 Digital Link * Resolver * APIs * L5 Digital Product Passport service Logical capability: assembles, versions, publishes and audits the representation * Passport assembly * Identity binding * Data access rules * Version and lifecycle * Publication * Resolution * Auditability * L4 Integration and orchestration Moves and coordinates information without owning it * APIs * Events * Integration services * Transformation * Validation rules * Workflow and exceptions * Publication orchestration * L3 Trust and governance Establishes whether information may be trusted and used * Data governance * Stewardship * Data quality * Validation * Evidence * Lineage and provenance * Access controls * L2 Identity and authority Establishes which product this is and which source speaks for each attribute * Product identification * Attribute-level authority * Systems of record * Identity resolution * MDM where appropriate * Golden Record where appropriate * L1 Source systems Remain authoritative for different information domains * PLM * ERP * PIM * MES * Supplier systems * Compliance and evidence * Traceability and events Cross-cutting Spans every layer. Not a box in the stack, and not something a single team owns. * Security * Privacy * Governance * Auditability * Monitoring * Lifecycle management * Regulatory change management - Master and reference data Relatively stable: identifiers, attributes, manufacturer information, materials, classification. Changes by controlled revision. - Lifecycle and event data Created as the product moves: manufactured, shipped, received, serviced, repaired, reused, recycled. Appends rather than overwrites. - Compliance and evidence data Demonstrates status: certificates, test evidence, declarations, technical documentation, verification status. Expires and must be revalidated. Read upward: information originates in source systems and is resolved, governed, orchestrated, assembled and published before it reaches a consumer. Authority does not travel with it. A system that publishes an attribute does not thereby become authoritative for it. This model is the synthesis layer for the pillar. It does not restate the earlier frameworks; it positions them. | Framework | What it contributes to the architecture | | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | [TBF-020 Product Data Foundation Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data) | Defines the master data that Layer 1 and Layer 2 depend on | | [TBF-021 Enterprise Product Data Landscape](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm) | Explains what each source system in Layer 1 owns and does not own | | [TBF-022 Enterprise Integration Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports) | Supplies the internal structure of Layer 4 | | [TBF-023 Trusted Product Data Governance Framework](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance) | Supplies the governance content of Layer 3 and part of the cross-cutting rail | | [TBF-024 Product Data Maturity Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation) | Judges whether an organisation can operate the architecture yet | | [TBF-025 Trusted Product Data Quality Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-quality) | Defines the quality dimensions Layer 3 validates against | | [TBF-026 Product Data Stewardship Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship) | Allocates the human responsibilities Layer 3 and Layer 4 exceptions depend on | | [TBF-027 Enterprise Source of Truth Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record) | Determines attribute-level authority in Layer 2 | | [TBF-028 Enterprise Master Data Management Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-master-data-management) | Describes the optional coordination capability in Layer 2 | | [TBF-029 Golden Record Lifecycle](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-golden-record) | Describes the optional resolved representation produced within Layer 2 | The reference architecture adds what none of those frameworks provides on its own: the assembly, publication and access path that turns governed internal information into an externally addressable passport, and the boundaries that keep each capability in its place. ## Architectural Principles Ten principles govern the model. They are stated as constraints because that is how they earn their keep during design reviews. #### Preserve authoritative sources Information stays where it is authoritatively managed. The architecture reads from designated sources rather than migrating ownership into a publication layer. #### Separate data ownership from data publication The team that owns an attribute is rarely the team that publishes it. Ownership determines correctness; publication determines exposure. Conflating them produces uncontrolled edits at the point of publication. #### Govern attributes, not merely systems Authority is assigned per attribute. "PLM owns the product" is too coarse to be operable, and it is the assumption behind most unresolvable source conflicts. #### Validate before publishing Validation belongs before the publication boundary. Publishing first and correcting later converts a data quality issue into a regulatory and reputational one. #### Maintain provenance and evidence Every published value should be able to state its source, the rule that selected it, and the evidence supporting it. Provenance is a design requirement, not a reporting feature. #### Design for lifecycle change Products are revised, suppliers change, certificates expire and units are repaired and recycled. The architecture must handle change as normal operation rather than as an exception. #### Separate identity, access and information The identifier says which product this is. The data carrier and resolver say how to reach the information. The passport is the information. Collapsing these three is the most common architectural error in the field. #### Avoid unnecessary data duplication Copy only what publication genuinely requires, and record why each copy exists. Every additional copy is a future reconciliation obligation. #### Use standards where appropriate Standards solve identification, encoding and exchange problems well. No single standard supplies governance, quality or evidence, and no standard should be assumed mandatory unless the applicable legislation makes it so. #### Treat the passport as enterprise information architecture A passport programme run as an isolated compliance application detaches from the governance that makes its content defensible, and typically has to be re-founded at the second product category. ## Layer 1: Source Systems Layer 1 is where product information is actually created and maintained. Representative sources include product lifecycle management for design, structure and specification, enterprise resource planning for commercial and operational attributes, product information management for customer facing content, manufacturing execution systems for production records, supplier systems for supplier originated declarations, compliance and evidence repositories for certificates and test results, and traceability or event systems for movements and lifecycle events. The essential architectural statement about this layer is that **different systems can remain authoritative for different information domains, permanently**. There is no requirement, regulatory or architectural, to make one of them authoritative for everything. [ERP vs PIM vs PLM](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm) sets out what each system is genuinely good at owning; the reference architecture simply takes that division as given. Two practical consequences follow. First, source systems are read by the architecture, not rewritten by it: a passport programme that starts editing PLM records to satisfy a publication format has inverted the dependency. Second, sources have very different change characteristics, and Layer 4 must accommodate that rather than assume a common cadence. ## Layer 2: Identity and Authority Layer 2 answers two questions before any information is assembled: which product is this, and which source speaks for each attribute of it. **Product identification** establishes a stable, unambiguous identity, as explained in [What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier). Identity may exist at several granularities, typically model, batch and individual item, and the architecture must be explicit about which level a passport addresses. **Attribute-level authority** assigns each attribute to a designated source, following [TBF-027](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record). This is the single highest value artefact in the whole architecture and the one most often skipped. **Identity resolution** reconciles the different internal codes the same product carries across systems. Attribute reconciliation is meaningless until identity is resolved. **Master data management** and **Golden Records** appear in this layer as *possible* capabilities. They are appropriate when the same entity is described in multiple systems and the description is consumed externally at scale. They are not mandatory architectural components, and an organisation with a single authoritative product source and clean identity may implement the reference architecture without either. See [What is Master Data Management?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-master-data-management) and [What is a Golden Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-golden-record) for when each is justified. #### Treating MDM as a prerequisite Programmes frequently stall for a year waiting for an enterprise MDM implementation before starting passport work. Attribute-level authority, documented and agreed, delivers most of the architectural benefit and can be produced in weeks. MDM industrialises that agreement; it does not substitute for making it. ## Layer 3: Trust and Governance Layer 3 determines whether information may be trusted and used. It contains data governance, stewardship, data quality, validation, evidence, lineage and provenance, and access controls. **Governance** sets the policies, decision rights and escalation paths, as described in [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance). **Stewardship** provides the people who operate them, per [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship). **Quality** supplies the dimensions against which candidate values are tested, per [What is Product Data Quality?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-quality): completeness, accuracy, consistency, validity, timeliness and traceability. **Validation** is the executable expression of those dimensions, applied to specific attributes with specific rules. **Evidence** links claims to the documents and test results that support them. **Lineage and provenance** record where each value came from and how it was transformed. **Access controls** belong here rather than only at the publication boundary, because different audiences are entitled to different information. A repairer, a recycler and a market surveillance authority may legitimately see different views of the same product, and the rules governing that should be defined where trust is established, then enforced at Layers 5 and 6. #### Make validation refuse, not warn A validation layer that emits warnings while allowing publication is a reporting tool, not a control. Define which failures block publication, which suppress an individual attribute, and which merely raise a stewardship task, and implement all three outcomes. ## Layer 4: Integration and Orchestration Layer 4 moves and coordinates information. It contains APIs, events, integration services, transformation, validation rules, workflow and exception handling, and publication orchestration. Its internal design is the subject of [How Enterprise Systems Support Digital Product Passports](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports). The defining constraint of this layer is that **integration is not ownership**. The integration layer sees every attribute and is therefore constantly tempted to become the place where values are "fixed". Once that happens the organisation has an undocumented second [system of record](/docs/knowledge-base/glossary/system-of-record), invisible to the governance in Layer 3. Four capabilities deserve emphasis: * **Transformation** converts source representations into the publication model. It must be declarative and inspectable, because a transformation is part of the provenance chain. * **Validation rules** execute the Layer 3 policy at the point of movement, so failures are caught before assembly rather than after publication. * **Workflow and exception handling** routes what cannot be resolved automatically to a named steward. An architecture with no exception path silently publishes its worst data. * **Publication orchestration** decides when a change is released, in what sequence, and with what approval. It is the difference between a controlled release and a live edit. ## Layer 5: Digital Product Passport Service Layer 5 is the logical passport capability. It provides passport assembly, product identity binding, data access rules, version and lifecycle management, publication, resolution and auditability. The word **logical** is doing real work. This capability may be delivered by one application, by several services, by existing enterprise capabilities, by external infrastructure, or by a combination. Nothing in the architecture implies a single physical "passport database", and organisations should resist reading one into the diagram. * **Passport assembly** composes the publishable representation from governed inputs according to the applicable requirements for that product category. * **Identity binding** ties the representation to a specific product identity at a specific granularity. * **Data access rules** determine which audience sees which elements. * **Version and lifecycle management** maintains the sequence of published states, so that what was visible at a given moment can be reconstructed. * **Publication** is the controlled act of making a version externally available. * **Resolution** connects an incoming request for an identifier to the correct published representation. * **Auditability** records what was published, when, by whom, from which inputs. [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work) describes the same sequence from the outside in, from the reader's perspective. > **Tip** > > Version management is where retrofitting hurts most. If published states are overwritten rather > than versioned, the organisation cannot later answer what a passport said on the date a unit was > sold. That question is entirely foreseeable and very difficult to answer after the fact. ## Layer 6: Access and Discovery Layer 6 connects the physical product to its published information. It contains the product identifier, the data carrier, QR codes and GS1 Digital Link where appropriate, resolver capability and APIs. The distinction this layer must preserve is fundamental: | Concept | What it is | What it is not | | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------- | | [Identifier](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier) | The name of the product identity, such as a [GTIN](/docs/knowledge-base/standards-and-technology/what-is-a-gtin) | Not a location, and not the information | | [Data carrier](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier) | The physical means of conveying the identifier, such as a QR code or RFID tag | Not the identity, and not the passport | | [GS1 Digital Link](/docs/knowledge-base/standards-and-technology/what-is-gs1-digital-link) | A web addressing syntax that expresses identifiers as resolvable URIs | Not the data, and not a mandate | | Passport | The governed information itself | Not the carrier, and not the identifier | [QR Codes vs GS1 Digital Link](/docs/knowledge-base/standards-and-technology/qr-codes-vs-gs1-digital-link) covers the encoding question in detail, and [What is GS1?](/docs/knowledge-base/standards-and-technology/what-is-gs1) covers the standards body. The architectural point is only that these are four separable concerns, and that a design which fuses them cannot later change its carrier, its identifier scheme or its presentation independently. Resolver capability translates an incoming identifier into the correct representation for the requesting audience. APIs serve the same content to systems rather than people, and are frequently the channel that matters most for business partners, recyclers and authorities operating at scale. ## Layer 7: Consumers Layer 7 is who the architecture ultimately serves: consumers, business partners, repairers, recyclers, market surveillance authorities, regulators, internal enterprise teams, and other authorised systems. Consumers are not a uniform audience, and this is an architectural fact rather than a presentation detail. A consumer typically needs comprehensible summary information. A repairer needs part and procedure detail. A recycler needs material and substance information at the point of disassembly. A market surveillance authority needs traceable evidence and the ability to verify claims. Internal teams need to see the same published state that external audiences see, which is more often missing than one might expect. Because entitlement differs by audience, the access rules defined in Layer 3 and enforced in Layers 5 and 6 are the mechanism that makes a single governed representation serve all of them without publishing everything to everyone. ## Cross-Cutting Capabilities Some capabilities span the entire architecture and should not be forced into a single layer. **Security** applies to source access, integration transport, published endpoints and administrative functions alike. **Privacy** matters wherever product information can be linked to individuals, for example through registration, service history or resale. **Governance** sets policy at Layer 3 but is exercised everywhere, including over integration changes and publication approvals. **Auditability** must hold across the whole path, because an audit trail that stops at the integration boundary cannot explain a published value. **Monitoring** covers data freshness, validation failure rates, resolution availability and access patterns. **Lifecycle management** applies to products, identities, evidence and published versions simultaneously. **Regulatory change management** tracks how obligations evolve through delegated acts and product-specific legislation, and turns those changes into requirement updates rather than emergencies. #### Assigning cross-cutting capabilities to one team's box When auditability is made the responsibility of the passport service alone, the audit trail begins at assembly and the organisation cannot show where a value came from. Cross-cutting capabilities need an owner, but their implementation is distributed by definition. ## Master and Reference Data Master and reference data is the relatively stable description of the product: identifiers, product attributes, manufacturer information, materials and classification. It is the subject of [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data). Its governance pattern is **controlled revision**. Values change infrequently, changes are deliberate, and each change should be attributable and approved. In publication terms this flow is usually the easiest to handle and the one organisations model first, which is precisely why the other two flows are so often underestimated. Reference data, meaning the shared code lists, units, classifications and taxonomies that give attribute values meaning, deserves separate attention. Uncontrolled reference data quietly breaks comparability between products, and comparability is much of the point of a passport. ## Lifecycle and Event Data Lifecycle and event data is created as the product moves: manufactured, shipped, received, serviced, repaired, reused, recycled. Its structure and semantics are the subject of [What is EPCIS?](/docs/knowledge-base/standards-and-technology/what-is-epcis), and its movement across organisational boundaries is described in [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain). Its governance pattern is **append, not overwrite**. An event that happened remains true; later events add to the history rather than replacing it. Three architectural consequences follow: * Volume is much higher than master data, so publication is usually selective rather than complete. * Identity granularity matters more, because events attach to items or batches rather than models. * Much of it originates outside the organisation, so trust depends on the arrangements with the party that reported it. Event data is also where the temptation to publish everything is strongest and least justified. The architectural question is not what events exist, but which of them a defined audience is entitled to see and needs. ## Compliance and Evidence Data Compliance and evidence data demonstrates regulatory or conformity status: certificates, test evidence, declarations, technical documentation and verification status. [Conformity assessment](/docs/knowledge-base/glossary/conformity-assessment) is the process that produces much of it. Its governance pattern is **validity with expiry**. Unlike master data, evidence is not simply current or superseded; it is valid until a date, for a defined scope, issued by a defined party. That makes three requirements architectural rather than optional: expiry handling, scope checking, and the ability to suppress a dependent claim when its supporting evidence lapses. Evidence is also the flow most likely to arrive from suppliers, in inconsistent formats, at inconvenient times. Programmes routinely underestimate the stewardship effort this creates. #### Why the three flows cannot share one pattern A recycled content figure is master data, revised deliberately when a specification changes. The test report supporting it is evidence, valid until a stated date. The record of the unit being refurbished in year four is an event, appended and never amended. A single "update the passport" process that treats all three identically will either overwrite history, ignore expiry, or both. ## How Information Moves Through the Architecture Reading the model as a path clarifies the responsibility boundaries. 1. Information is created and maintained in Layer 1 source systems, each authoritative for its own domain. 2. Layer 2 establishes product identity, resolves competing internal identities, and determines which source is authoritative for each attribute. 3. Layer 3 applies governance, quality rules, validation and evidence checks, and records lineage, determining whether a value may be used at all. 4. Layer 4 moves and transforms information, executes the validation rules at the point of movement, routes exceptions to stewards, and orchestrates release. 5. Layer 5 assembles the publishable representation, binds it to a product identity, applies access rules, versions it, publishes it and records the audit trail. 6. Layer 6 makes the published representation discoverable through an identifier, a data carrier and resolution, or directly through APIs. 7. Layer 7 consumers read what they are entitled to read. Two directional rules keep the model honest. **Authority does not travel with data**: a system downstream of the authoritative source never becomes authoritative by virtue of holding a copy. And **corrections travel upward, not downward**: a wrong published value is corrected in the authoritative source and republished, never edited at the publication layer. ## Where the Digital Product Passport Should Sit The passport service sits above integration and below access. That position is deliberate. It sits **above the integration layer** because it should receive validated, governed information rather than raw extracts, and because it should not be responsible for reaching into source systems itself. It sits **below access and discovery** because identifiers, carriers and resolution are separable concerns that should be changeable without redesigning assembly. It sits **within the enterprise information architecture**, not beside it. The information a passport publishes is the same information that supports planning, sourcing, service and reporting. Where an organisation builds a parallel compliance data set, the two versions diverge, usually within a year, and the published one is the one with an external audience. #### Define the publication boundary explicitly Draw a line in your architecture and name it: on one side, governed enterprise information; on the other, the published representation. Every crossing should be validated, versioned, attributable and auditable. Most passport architecture problems are, on inspection, an undefined boundary. ## What the Digital Product Passport Should Not Become The passport should not become a new enterprise master database. That means it should not be the place where product data is corrected, where attributes are authored, where missing information is invented, or where teams go to look up an internal value. Each of those behaviours makes it authoritative by accident: an unowned, ungoverned, unstewarded source of record that nevertheless shapes external claims. It should also not become the only copy of anything. If the sole record of a value is inside the publication layer, its provenance cannot be established and its correctness cannot be defended. Finally, it should not absorb the responsibilities of other layers. A passport service that performs its own identity resolution, its own data quality remediation and its own supplier chasing is not an architecture; it is the previous spreadsheet, hosted. ## Architecture Patterns The same logical architecture can be implemented in materially different ways. Three patterns dominate, and each is legitimate. **Federated.** Information remains distributed in its source systems and is assembled when required, at request time or shortly before publication. Strengths: minimal duplication, values are as current as their sources, ownership stays unambiguous. Trade-offs: publication depends on source availability and performance, latency is harder to control, historical reconstruction requires deliberate versioning, and every source must be able to answer reliably at the moment it is asked. **Centralised.** Selected passport information is assembled into a dedicated governed repository from which publication is served. Strengths: predictable performance and availability, straightforward versioning and audit, resilience to source outages, and a natural place to enforce publication controls. Trade-offs: it creates a copy, and every copy must be reconciled, refreshed and governed. Without discipline this pattern degrades directly into the anti-pattern of a second master database. **Hybrid.** Master information, event information and evidence remain distributed while a controlled passport service maintains the publishable representation, typically caching what must be served reliably while resolving volatile or high volume information on demand. Strengths: it matches the three information flows to appropriate treatment. Trade-offs: it is the most complex to design and the most demanding of clear boundaries, because the rules about what is cached and for how long become part of the compliance story. No pattern is universally superior. The determining factors are usually the availability characteristics of source systems, the volume and volatility of event data, the number of product categories in scope, and the organisation's position on the [Product Data Maturity Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation). ## Architecture Anti-Patterns Each of the following is common, and each fails in a predictable way. #### The DPP becomes another master database Attributes are authored and corrected inside the publication layer because it is convenient. Within months it holds values that exist nowhere else, with no owner, no steward and no lineage. The organisation now has two versions of product truth and the ungoverned one is the public one. #### Copy everything into the passport Every available attribute is replicated on the assumption that more is safer. The result is a large surface of unvalidated, unowned data, higher reconciliation cost, and greater exposure when any of it is wrong. Publication scope should follow requirement and entitlement, not availability. #### The QR code is the passport A carrier is treated as the deliverable, so the programme ends when labels are printed. Nothing behind the carrier is governed, versioned or maintainable, and changing the carrier later requires reprinting rather than reconfiguration. The carrier conveys an identifier; the passport is the governed information. #### The PIM is automatically the passport Product information management holds customer facing content and is therefore assumed to hold passport content. It rarely holds engineering specifications, manufacturing records or conformity evidence, and it was not designed to carry evidence validity or lifecycle events. It is a contributor to Layer 1, not a replacement for Layer 5. #### The ERP owns all product information Because ERP is enterprise-wide, it is assumed to be authoritative for everything. In practice it is authoritative for commercial and operational attributes and a poor home for specifications, content and evidence. Assigning authority by system size rather than by attribute is the root of most unresolvable conflicts. #### Integration means ownership The integration layer becomes the place where values are corrected, because it sees everything and can change anything. This creates an undocumented system of record invisible to governance, and corrections stop flowing back to the sources that will simply reassert the old value. #### Newest value wins Recency is adopted as the universal survivorship rule because it requires no analysis. It systematically privileges the most frequently updated system over the most authoritative one, and it can overwrite a verified, evidence backed value with an unverified one. Survivorship belongs per attribute, as set out in [TBF-029](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-golden-record). #### One source of truth means one physical database A sound principle about authority is read as an instruction to consolidate. The resulting multi-year migration delays the passport programme and, because sources keep operating during it, usually produces one more copy rather than one fewer. #### Governance can be added later Delivery proceeds first, with governance planned for a later phase. By then the publication path has hard-coded assumptions about which values are trustworthy, no lineage was captured, and retrofitting provenance to already published claims is close to impossible. #### Once published, passport data is static Publication is treated as completion. In reality specifications are revised, certificates expire, suppliers change and units are repaired and recycled. Without lifecycle updates and versioning, a passport becomes progressively less accurate while remaining publicly visible. ## Practical Enterprise Example Consider a manufacturer of a commercial refrigeration unit sold across the European Union. The product is assembled from purchased components including a compressor, an electronic controller and an insulated cabinet. **1. Product identification.** The unit is identified at model level for its general description and at individual item level through a serial number, because service history and refrigerant handling attach to individual units. The model level identifier is a [GTIN](/docs/knowledge-base/standards-and-technology/what-is-a-gtin); the item level identity extends it with a serial number. **2. Authoritative source determination.** The team produces an attribute-level authority map before any integration is built. Dimensions, materials and the bill of materials are authoritative in PLM. Commercial descriptions, packaging and logistics attributes are authoritative in ERP. Customer facing descriptions and imagery are authoritative in PIM. Refrigerant type and charge are authoritative in PLM but verified against supplier declarations. Energy performance figures are authoritative in the compliance repository, because the value is only meaningful with its test evidence. Build date, line and component lot are authoritative in the manufacturing system. Component substance declarations are authoritative in the supplier's submission, held in the evidence repository. **3. Validation.** Rules are defined per attribute: refrigerant charge must be present and within a plausible range; energy class must reference a test report that is currently valid; component substance declarations must cover every component present in the published bill of materials at the relevant revision. **4. Governance.** Each attribute group has a named owner and a named steward. The escalation path is defined: a failed evidence check blocks publication of the dependent claim, a missing supplier declaration raises a stewardship task with a deadline, a conflict between two designated sources goes to the product data council. **5. Integration.** PLM and ERP are read on a scheduled basis, since their change cadence is low. Manufacturing events arrive as they occur. Supplier declarations arrive through a submission process and are validated on receipt rather than at publication time, which is what makes deadlines enforceable. **6. Exception handling.** One compressor supplier submits a substance declaration covering a superseded component revision. Validation detects the scope mismatch, the claim that depends on it is withheld rather than published with the old evidence, and a task is raised against the supplier manager. The rest of the passport publishes normally. **7. Passport assembly.** The service composes the representation for this product category: identification, manufacturer information, materials and substances, energy performance with its evidence reference, repair and spare part information, and end of life handling guidance. Attributes that failed validation are marked unavailable rather than defaulted. **8. Publication.** Version 1.0 is published with an approval record showing who released it, from which source states, and when. **9. Access through identifier and data carrier.** A carrier on the unit conveys the identifier. Resolution returns the consumer view by default. A recycler authenticating as such receives additional material and disassembly detail. A market surveillance authority receives the evidence references and the audit trail. The carrier changed nothing about the information; it only conveyed the identity. **10. Lifecycle update.** In year three the controller is replaced by a revised part. PLM records the engineering change, the supplier submits a new declaration, validation passes, and version 1.1 is published. Version 1.0 remains reconstructable, so what was published when a given unit was sold can still be shown. In year six a unit is refurbished and the event is appended to that item's history without altering the model level description. **11. Regulatory access.** An authority queries a specific serial number. Resolution returns the version applicable to that unit, the evidence supporting the energy claim, the lineage showing which system supplied each value, and the publication audit trail. No part of that answer required someone to assemble a file by hand. The architecture did not eliminate the organisation's complexity. It made the complexity governable, and it made a specific external answer defensible. ## Implementation Sequence The sequence below is deliberately not "select and buy a passport platform". Technology selection is a consequence of the first six steps, not a substitute for them. #### Determine regulatory and product scope Establish which products are in scope, under which legislation, and on what timeline. Obligations arrive category by category through delegated acts, so scope is a moving object that must be tracked rather than assumed. See [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport). #### Identify required information Translate the obligations into a concrete attribute list, including granularity and evidence requirements. [What Information Does a Digital Product Passport Contain?](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain) provides the starting structure. #### Map authoritative sources Assign every required attribute to a designated source at attribute level. Expect this exercise to surface disagreements that have been latent for years; that is its value. #### Assess data quality Measure the required attributes against completeness, accuracy, consistency, validity, timeliness and traceability. Assess only what is in scope: enterprise-wide quality programmes rarely finish. #### Establish ownership and stewardship Name owners and stewards for each attribute group and give them explicit decision rights and escalation paths. Unowned attributes do not improve. #### Define validation and evidence requirements Specify, per attribute, what must be true before publication, what evidence is required, what happens on failure, and how expiry is handled. #### Design integration Design how information moves, at what cadence, with what transformation and what exception routing. Match the mechanism to the flow: scheduled for master data, event driven for lifecycle data, submission and validation for evidence. #### Define the passport publication model Decide the architecture pattern, the granularity of published identity, the versioning model, the access rules per audience, and the approval process for release. #### Implement access and discovery Choose identifier scheme, carrier and resolution approach, keeping them separable so each can change independently. #### Test lifecycle updates and exceptions Rehearse the cases that break programmes: an engineering change, an expiring certificate, a supplier substitution, a withdrawn declaration, a repair event, a correction to an already published value. #### Establish monitoring and continuous governance Monitor freshness, validation failures, evidence expiry, resolution availability and access patterns, and review the rules themselves as products, suppliers and obligations change. Use [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports) and the [Product Data Maturity Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation) to judge readiness and pace. ## Benefits A coherent architecture pays back in ways that extend well beyond the immediate obligation. * **Defensible publication.** Every published value has a source, a rule, an owner and evidence, which is what makes a regulatory enquiry a retrieval exercise rather than an investigation. * **Reusability across categories.** The second product category costs a fraction of the first, because identity, governance, integration and publication already exist. * **Reduced duplication.** Preserving authoritative sources avoids creating copies that must be reconciled indefinitely. * **Faster correction.** Corrections applied at source propagate everywhere, instead of being patched in one channel and forgotten in the others. * **Operational value beyond compliance.** The same governed information improves service, spare parts, sourcing decisions and sustainability reporting. * **Lower regulatory change cost.** When requirements evolve, the change lands in requirement mapping and validation rules rather than in bespoke extraction code. * **Clearer accountability.** Attribute-level authority ends the recurring argument about which system is right. ## Common Mistakes * **Starting with technology selection.** Choosing a platform before mapping authoritative sources guarantees that the platform's data model becomes the architecture by default. * **Treating the passport as a compliance project.** Detached from enterprise information architecture, it is rebuilt at the second product category. * **Skipping attribute-level authority.** System level ownership statements are too coarse to resolve real conflicts and quietly push the decision into integration code. * **Deferring evidence handling.** Evidence has validity, scope and expiry, and retrofitting those properties after publication is painful. * **Modelling only master data.** Lifecycle events and compliance evidence have different governance patterns and are not served by the master data pipeline. * **Publishing everything available.** Scope should follow requirement and entitlement; surplus publication is surplus exposure. * **Ignoring granularity.** Model, batch and item level identity are different, and a design that blurs them cannot support item level service or recycling information later. * **No exception path.** Without one, the architecture publishes its least reliable data silently. * **Assuming a specific standard is mandatory.** Standards are mechanisms; the legislation states the outcome required. Assuming an adoption obligation that does not exist distorts the design. * **Treating publication as the end.** It is the start of a maintenance obligation measured in years. ## Frequently Asked Questions #### Does a Digital Product Passport require a new system? Not necessarily. The architecture describes required capabilities, and organisations meet them with different combinations of existing systems, new services and external infrastructure. What is not optional is that the capabilities exist somewhere and have owners. #### Do we need MDM or a Golden Record before we start? No. Both are useful capabilities in Layer 2 where the same entity is described in multiple systems at scale, but neither is a mandatory component. Documented attribute-level authority is the actual prerequisite. #### Should we centralise all product data first? Almost never. Consolidation programmes are long, and the passport obligation does not require them. The architecture is designed to work with distributed authoritative sources. #### Which architecture pattern should we choose? It depends on source system availability, event data volume, the number of categories in scope and organisational maturity. Federated minimises duplication, centralised maximises predictability, hybrid matches treatment to each information flow at the cost of complexity. #### Is GS1 Digital Link mandatory? No. It is a widely used mechanism for expressing identifiers as resolvable web addresses, and it is frequently a sensible choice, but a general obligation to adopt it should not be assumed. Requirements about identification and access come from the applicable legislation and its delegated acts. #### Where should validation happen? Policy is defined in Layer 3 and executed in Layer 4 at the point of movement, with a final gate before publication in Layer 5. What matters most is that it happens before the publication boundary, not after it. #### How do we handle information we do not hold? Mark it unresolved and manage it as a stewardship task with a named owner and a deadline. Never populate a required attribute with a plausible default; suppression is nearly always safer than a guess. #### Who owns this architecture internally? In practice it needs a single accountable owner, usually in enterprise or data architecture, with governance shared across product, compliance, supply chain and IT. Sole ownership by a compliance function tends to detach it from the enterprise information estate. #### How does this relate to product-specific legislation? The architecture is category neutral. Specific attributes, evidence expectations and timing come from the applicable legislation and its delegated acts, and land in requirement mapping and validation rules rather than in the architecture itself. ESPR establishes the framework for Digital Product Passports, including provisions on data carriers, unique identifiers, access rights and data availability. It sets the outcomes that must be achieved. It does not prescribe an enterprise architecture, mandate particular systems, or require product information to be physically consolidated. Which attributes must be published, at what granularity, and with what evidence, is determined by the delegated act applicable to a given product group. Other instruments, notably Regulation (EU) 2023/1542 on batteries, set their own passport requirements on their own timelines. ## Key Takeaways ## Related Articles * [How Enterprise Systems Support Digital Product Passports](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports) * [What is a Golden Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-golden-record) * [What is Master Data Management (MDM)?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-master-data-management) * [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports) * [How to Validate Digital Product Passport Data](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data) * [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap) * [How to Build a Trusted Product Data Foundation](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation) * [What is a System of Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record) ## Related Glossary Terms * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [Product Data](/docs/knowledge-base/glossary/product-data) * [Product Identifier](/docs/knowledge-base/glossary/product-identifier) * [Data Carrier](/docs/knowledge-base/glossary/data-carrier) * [GS1](/docs/knowledge-base/glossary/gs1) * [GS1 Digital Link](/docs/knowledge-base/glossary/gs1-digital-link) * [QR Code](/docs/knowledge-base/glossary/qr-code) * [Product Lifecycle](/docs/knowledge-base/glossary/product-lifecycle) * [Product Traceability](/docs/knowledge-base/glossary/product-traceability) * [Conformity Assessment](/docs/knowledge-base/glossary/conformity-assessment) * [Market Surveillance](/docs/knowledge-base/glossary/market-surveillance) * [Economic Operator](/docs/knowledge-base/glossary/economic-operator) * [Sustainability Data](/docs/knowledge-base/glossary/sustainability-data) * [Delegated Act](/docs/knowledge-base/glossary/delegated-act) * [ESPR](/docs/knowledge-base/glossary/espr) ## References * Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, including Digital Product Passport provisions, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) * Regulation (EU) 2023/1542 concerning batteries and waste batteries, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2023/1542/oj](https://eur-lex.europa.eu/eli/reg/2023/1542/oj) * Regulation (EU) 2019/1020 on market surveillance and compliance of products, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2019/1020/oj](https://eur-lex.europa.eu/eli/reg/2019/1020/oj) * European Commission, Ecodesign for Sustainable Products Regulation: [https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation\_en](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en) * EUR-Lex, official portal for European Union law: [https://eur-lex.europa.eu](https://eur-lex.europa.eu) * GS1 identification keys, including the GTIN: [https://www.gs1.org/standards/id-keys](https://www.gs1.org/standards/id-keys) * GS1 Digital Link standard: [https://www.gs1.org/standards/gs1-digital-link](https://www.gs1.org/standards/gs1-digital-link) * GS1 EPCIS and Core Business Vocabulary standard: [https://www.gs1.org/standards/epcis](https://www.gs1.org/standards/epcis) * DAMA International, the professional association for data management and publisher of the Data Management Body of Knowledge: [https://www.dama.org](https://www.dama.org) * International Organization for Standardization, ISO 8000 series on data quality and master data: [https://www.iso.org/standard/81745.html](https://www.iso.org/standard/81745.html) * International Organization for Standardization, ISO/IEC 38505 on governance of data: [https://www.iso.org/standard/56639.html](https://www.iso.org/standard/56639.html) ## 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. ## Related Docs * [What is a Golden Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-golden-record) * [What is Master Data Management (MDM)?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-master-data-management) * [What is a System of Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record) * [How Enterprise Systems Support Digital Product Passports](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports) * [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance) * [How to Build a Trusted Product Data Foundation](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation) * [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work) * [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports) * [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain)