Knowledge BaseEnterprise Systems & Data Architecture

How Enterprise Systems Support Digital Product Passports

Executive Summary

A Digital Product Passport looks like a publishing problem and behaves like an integration problem. The visible output is a page a customer can reach by scanning a code. The work behind it is the assembly of attributes that already exist, in different systems, under different owners, at different levels of quality, and with different rhythms of change.

No single enterprise system can produce a passport on its own. ERP holds identity, packaging and commercial reality. PLM holds composition, specifications and engineering change. PIM holds descriptions, translations and media. MES holds what was actually produced, in which batch, on which line. Supplier systems hold the declarations and evidence that the organisation does not generate itself. A passport requires a coherent selection from all five.

The layer that makes this workable is the integration layer: the place where attributes are retrieved from owning systems, mapped to a common product model, validated, enriched with provenance, and made available for publication. Its defining responsibility is that it must transport and transform, never invent. When an integration layer starts holding values that exist nowhere upstream, it has quietly become a sixth system of record and the organisation has lost the lineage it needs to defend published claims.

This article sets out The Enterprise Integration Model, which orders these components into three tiers: contributing systems, the integration layer, and the passport. It then distinguishes systems of record, which own truth and change slowly under governance, from systems of engagement, which present that truth to people and change quickly. A passport is a system of engagement built on systems of record, and most implementation failures come from confusing the two.

Everything here is functional rather than vendor specific. The tiers describe responsibilities, not products. Organisations legitimately combine several of these responsibilities into fewer platforms, and that is fine, provided each responsibility is consciously assigned rather than assumed.

FrameworkTBF-022
The Enterprise Integration Model

Places an integration layer between source systems and the passport so publication draws from authoritative data.

Table of Contents

Definition

Definition
Enterprise Support for Digital Product Passports

Enterprise support for Digital Product Passports is the coordinated contribution of an organisation’s operational systems, ERP, PLM, PIM, MES, quality systems and supplier data sources, to the assembly, validation and publication of trusted product information. It is delivered through an integration layer that retrieves attributes from their owning systems, maps them to a common product model, validates them against publication rules and records their provenance, so that the passport presents governed information rather than newly authored claims.

Three consequences follow from that definition, and they shape every design decision in this article.

Assembly, not authorship. The passport is the last step in a chain that begins with systems that already exist. Its job is selection, formatting and presentation, which is the principle established in What is Product Master Data?.

Many sources, one model. Attributes arrive with different names, units, granularities and languages. Someone must reconcile them into a single product model before publication, and that work belongs in the integration layer rather than in the publishing template.

Provenance is part of the payload. For a published claim to be defensible, the organisation must be able to state which system supplied it, when, and on whose authority. Provenance captured at integration time is cheap; provenance reconstructed after a challenge is expensive and sometimes impossible.

The one sentence version

Enterprise systems hold the truth, the integration layer assembles it, and the passport publishes it. Nothing new should be born in the last two steps.

The Enterprise Integration Model

Most passport programmes begin by asking which system to connect first. That question produces point-to-point integrations chosen by convenience, which then become permanent. The better starting question is what each tier is responsible for.

The Enterprise Integration Model answers it. Five contributing systems supply attributes. One integration layer assembles them. One publication produces the passport. The model’s structural claim is that the contributing systems must not know about the passport at all: they publish their attributes to the integration layer under their own governance, and the integration layer adapts. When source systems start carrying passport-specific fields and passport-specific logic, the organisation has coupled its operational estate to a publication format it does not control.

Tier 1, contributing systems
ERP
Commercial and logistics truth

Supplies product identity and trade codes, units of measure, packaging hierarchy, weights and dimensions as handled, supplier links, market and channel scope, and lifecycle status.

Responsible for: correctness of the operational record.

PLM
Engineering truth

Supplies bill of materials, materials and substances, recycled content by component, specifications and test methods, repairability and spare part structure, and the revision in force.

Responsible for: the product as designed, under change control.

PIM
Descriptive truth

Supplies commercial names, descriptions, translations and locale variants, imagery and documents for display, and channel-specific presentation attributes.

Responsible for: language quality and media governance.

MES
Production truth

Supplies what was actually made: batch and lot identity, production site and line, date of manufacture, as-built deviations from the design, and in-process quality results.

Responsible for: the link between a design and a physical unit.

Supplier Systems
External truth

Supply component declarations, substance and material data, recycled content evidence, certificates and their validity, and origin information the organisation cannot generate itself.

Responsible for: attested data, with an accountable sender.

All five contribute, none publishes directly
Tier 2, integration layer
Integration Layer
Assembly and assurance
  • Retrieve attributes from the owning system, on a defined trigger or schedule.
  • Resolve identity so every attribute attaches to one governed product.
  • Map names, units, languages and granularity to one common product model.
  • Validate completeness, format and business rules before anything is publishable.
  • Record provenance: source system, timestamp, version and responsible owner.
  • Detect change upstream and raise the need to re-publish.
  • Enforce disclosure rules so sensitive attributes never reach a public audience.

Must not: author attribute values, hold the only copy of a product fact, or apply undocumented business logic that changes a published figure.

Assembled, validated, attributed
Tier 3, publication
Digital Product Passport
Governed presentation

Selects the audience-appropriate subset, renders it for people and machines, snapshots it with a version, and binds it to a persistent identifier reachable from a

data carrier

.

Responsible for: accessibility, audience scoping, immutability of what was published, and the accuracy of the link back to source.

Contributing systems know nothing about the passport. The integration layer knows about both. The passport knows only the assembled model.

Enterprise Architecture

A passport programme is an architectural intervention whether or not it is treated as one. Three architectural decisions determine most of its cost.

Where the product model lives. There must be one canonical representation of a product that all contributing systems map into. If that model exists only inside the publishing tool, every future consumer, a retailer feed, a regulator submission, a marketplace, will require its own integration. If it exists in the integration layer, those consumers are additional outputs rather than additional projects.

How systems are coupled. Direct calls from the publishing tool into five operational systems create five dependencies with five availability profiles and five change calendars. An intermediating layer decouples them, so an ERP upgrade does not take the passport estate offline.

Where identity is resolved. Identity resolution, deciding that the PLM part, the ERP item, the PIM product and the supplier’s component reference all describe the same thing, must happen once, in one place, before publication. Distributing this decision across integrations guarantees eventual contradiction.

Two further considerations are frequently underestimated. Timing matters because these systems have different rhythms: engineering changes are discrete and governed, production data is continuous, supplier declarations arrive irregularly and expire. Environment parity matters because passport content is externally visible, so the ability to assemble and inspect a passport in a non-production environment is a prerequisite for safe change, not a nicety.

Example
Why the intermediating layer earns its cost

An organisation publishes passports by calling PLM and ERP directly from its publishing tool. A planned ERP upgrade changes a field name. Publishing fails silently for eleven days, and the failure is discovered by a retailer, not internally. The same change against an integration layer would have broken one mapping in one place, in a test environment, with a validation error rather than a public gap.

Systems of Record

A system of record owns the authoritative value of an attribute. It is where the value is created, changed under governance, and audited.

The characteristics are consistent. Changes are deliberate and traceable to a person and a reason. There is an approval path for material changes. History is retained. Other systems reference the value rather than re-entering it. And the owner is a business function, not the platform team.

For passports the relevant systems of record are ERP for commercial and logistics attributes, PLM for the engineering definition, quality systems for conformity evidence, MES for as-built and batch facts, and supplier systems for attested external data. Where an MDM function exists, it does not displace these: it reconciles identity and shared definitions across them.

Three rules make systems of record usable by a passport programme.

Read, do not fork. The integration layer reads from the system of record on a defined trigger. It does not maintain an editable copy that drifts.

Version, do not overwrite. When an attribute changes, the previous value and its effective dates must remain retrievable, because a passport published last quarter must remain explicable.

Expose meaning, not just values. A number without a definition and a unit is not usable evidence. The system of record should supply, or the integration layer should attach, the definition that makes the value interpretable.

Common Mistake
Treating a report or extract as a system of record

Scheduled extracts and reporting tables are convenient sources because they are already flattened. They are also derived, frequently filtered, and rarely governed. Publishing from an extract means publishing from an artefact nobody owns.

Systems of Engagement

A system of engagement presents information to people. It optimises for accessibility, speed, language and experience, and it changes far more often than a system of record.

A Digital Product Passport is a system of engagement. So are the customer-facing web presence, the retailer portal, the service and repair application, and the recycler-facing view. They share three properties: they are read-mostly, they are audience-specific, and they are disposable in the sense that their presentation can be redesigned without touching the underlying truth.

Confusing the two categories produces the two most common architectural failures in passport programmes. The first is authoring in the engagement layer, where a value is typed into the publication tool because the source system lacks the field. The second is hardening the engagement layer into a record, where the passport becomes the only place a certain attribute exists, so it can never be redesigned or replaced.

The passport does own some things legitimately, and it is worth being precise about them: the disclosure rules for each audience, the rendering and language of the published artefact, the published snapshot and its version history, and the binding between the artefact and the identifier on the product. All of those are presentation concerns. None of them is a product fact.

Best Practice
Make the passport reproducible from source

A useful design test: if the publication environment were rebuilt from empty, could every current passport be regenerated from the contributing systems alone? If the answer is no, the engagement layer is holding records it should not hold, and that gap is the programme’s real risk register.

Integration

Integration is where the model becomes an implementation. Six responsibilities matter, in roughly this order.

1. Identity resolution. Every incoming attribute must attach to one governed product identity, at the correct level: model, variant, batch or individual item. Publishing a batch-level attribute against a model identifier is not a rounding error, it is an unverifiable claim.

2. Mapping to a common model. Source names, units, code lists and languages are normalised into the canonical product model. Reference data, units of measure, country codes, material taxonomies, should come from controlled lists rather than from whatever each system happens to use.

3. Validation. Completeness, format, range, cross-field consistency and regulatory rules are checked before anything becomes publishable. Validation belongs here rather than in the publishing template, so the same rules protect every downstream consumer.

4. Provenance. Each attribute carries its source system, extraction timestamp, source version and responsible owner. This is the single highest-value, lowest-cost feature in the whole architecture and it is routinely deferred.

5. Change detection and re-publication. Upstream change must produce a signal: an engineering change, a certificate approaching expiry, a supplier declaration superseded, a new production batch. The integration layer decides whether the change is material and raises re-publication accordingly.

6. Disclosure control. Sensitive attributes, costs, supplier identities, formulations, must be filtered by audience before they leave the integration layer, not hidden by the presentation template. A field that never reaches the publication tier cannot be exposed by a template error.

On patterns, three notes without vendor specificity. Batch extraction suits attributes that change rarely and is usually where programmes should start. Event-driven updates suit high-frequency production and logistics data. On-demand retrieval suits volatile values, but is a poor fit for passports, which are snapshots by design and must not depend on a live upstream call to render.

Finally, integration must be observable. Failed retrievals, stale attributes, validation rejections and unpublished material changes all need to be visible on a dashboard that someone owns. A silent integration is indistinguishable from a correct one until an external party finds the difference.

Example
One attribute, end to end

Recycled content for a component. PLM supplies the bill of materials structure. A supplier system supplies the declared recycled percentage with a certificate reference and expiry. The integration layer resolves the component to the governed product, converts the declaration into the canonical unit, validates that the certificate is current, computes the product-level figure using a documented rule, records provenance for both inputs, and marks the attribute publishable. The passport then shows one number, and the organisation can explain every step behind it in under a minute.

Benefits

Defensible claims. Provenance captured at integration time turns a regulatory challenge into a lookup rather than an investigation.

Lower change cost. One mapping per attribute in one layer, instead of the same transformation repeated in every downstream consumer.

Resilience. Operational system upgrades and outages are absorbed by the integration layer rather than surfacing as public gaps in published content.

Reuse beyond compliance. The same assembled product model serves retailer feeds, marketplace listings, service applications and regulator submissions, so the passport investment is not single-purpose.

Consistency across audiences. Consumers, repairers, recyclers and market surveillance authorities see views of the same governed data, which removes the contradictions external parties otherwise find.

Faster onboarding of new products. Once the mappings exist, publishing an additional product is a data completeness exercise rather than a project.

Clear accountability. When every attribute has a source system and an owner, quality problems are routed to the function that can actually fix them.

Common Mistakes

Common Mistake
Point-to-point integrations chosen by convenience

Connecting the publishing tool straight into whichever system has the friendliest API creates dependencies that are never unwound, and it scatters transformation logic across connectors nobody documents.

Common Mistake
Letting the integration layer author values

A default, a fallback or a hardcoded constant introduced to unblock a launch becomes a published claim with no upstream source. It will be discovered during an audit, not before.

Common Mistake
Publishing without provenance

Without source, timestamp and version on each attribute, the organisation can show what it published but not why it believed it. Retrofitting provenance across an established estate is substantially harder than building it in.

Common Mistake
Ignoring MES and treating all products as identical

Design-level data describes what should have been made. Where obligations attach to batches or units, as-built and production data is required, and programmes that omit MES discover this only when a batch-level claim is challenged.

Common Mistake
Treating supplier data as a spreadsheet exercise

Supplier declarations expire, change and vary in reliability. Collecting them once by email produces a snapshot that silently ages. They need an intake process, validity tracking and an accountable sender.

Common Mistake
No re-publication trigger

Passports are snapshots, so without a defined trigger for material upstream change they gradually become historical documents presented as current information.

Common Mistake
Unmonitored pipelines

Integration failures that produce stale rather than missing content are invisible without monitoring. Staleness is the failure mode most likely to reach an external audience undetected.

Frequently Asked Questions

Do we need a dedicated integration platform?
No. You need the integration responsibilities to be assigned and implemented somewhere deliberate. A smaller organisation may meet them with scheduled jobs and a governed staging model, provided mapping, validation and provenance are genuinely present.

Should the passport call source systems live at scan time?
Generally no. Passports are published snapshots, and a live dependency makes external availability contingent on internal systems. Assemble and publish in advance, and re-publish on material change.

Where should the canonical product model live?
In the integration layer, not in the publishing tool. That is what allows other consumers to reuse the same assembled data without new integrations.

How do supplier systems fit if suppliers have no systems?
Through a structured intake, a portal, a defined template or a data exchange, that produces validated records with an accountable sender and an expiry date, rather than unstructured documents.

What about quality systems and event data?
Quality systems supply conformity evidence and belong alongside the five contributing systems. Event data, typically shared using EPCIS, describes what happened to identified objects and is consumed selectively where lifecycle claims require it.

Who owns the integration layer?
Operationally IT or a data platform function, but each attribute mapping should have a named business owner. The layer owns transport and assurance, never the meaning of the data.

How do we start if the estate is fragmented?
Begin with one product family and the attributes you are actually obliged to publish, build the mappings and provenance properly for those, and expand. Breadth before depth produces a wide, unverifiable dataset.

How do we know it is working?
Monitor four things: retrieval success, attribute staleness, validation rejection rates, and unpublished material changes. If those four are visible and owned, the architecture is under control.

Key Takeaways

Key Takeaways

Definitions of record for the terms used above live in the glossary.

References

About This Article

About This Article
Last Reviewed
2026-08-08
Next Scheduled Review
2027-08-08
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.