> 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.

# How Enterprise Systems Support Digital Product Passports

> A vendor neutral explanation of how ERP, PLM, PIM, MES and supplier systems feed a Digital Product Passport through an integration layer, and what each layer is responsible for.

## 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](/docs/knowledge-base/glossary/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.

Framework TBF-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)
* [The Enterprise Integration Model](#the-enterprise-integration-model)
* [Enterprise Architecture](#enterprise-architecture)
* [Systems of Record](#systems-of-record)
* [Systems of Engagement](#systems-of-engagement)
* [Integration](#integration)
* [Benefits](#benefits)
* [Common Mistakes](#common-mistakes)
* [Frequently Asked Questions](#frequently-asked-questions)
* [Key Takeaways](#key-takeaways)
* [Related Glossary Terms](#related-glossary-terms)
* [References](#references)
* [About This Article](#about-this-article)

## Definition

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?](/docs/knowledge-base/enterprise-systems-and-data-architecture/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](/docs/knowledge-base/standards-and-technology/what-is-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.

#### 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.

#### 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.

#### 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.

#### 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](/docs/knowledge-base/glossary/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

#### 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.

#### 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.

#### 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.

#### 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.

#### 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.

#### 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.

#### 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](/docs/knowledge-base/standards-and-technology/what-is-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

## Related Articles

* [ERP vs PIM vs PLM: What's the Difference?](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm)
* [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture)
* [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data)
* [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport)
* [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work)
* [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain)
* [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports)
* [How Will Digital Product Passports Change Product Compliance?](/docs/knowledge-base/standards-and-technology/how-will-digital-product-passports-change-product-compliance)

## Related Glossary Terms

Definitions of record for the terms used above live in the
[glossary](/docs/knowledge-base/glossary/overview).

* [Product Data](/docs/knowledge-base/glossary/product-data)
* [Product Identifier](/docs/knowledge-base/glossary/product-identifier)
* [Product Lifecycle](/docs/knowledge-base/glossary/product-lifecycle)
* [Product Traceability](/docs/knowledge-base/glossary/product-traceability)
* [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport)
* [Data Carrier](/docs/knowledge-base/glossary/data-carrier)
* [GS1](/docs/knowledge-base/glossary/gs1)
* [Economic Operator](/docs/knowledge-base/glossary/economic-operator)
* [Conformity Assessment](/docs/knowledge-base/glossary/conformity-assessment)
* [Market Surveillance](/docs/knowledge-base/glossary/market-surveillance)
* [Sustainability Data](/docs/knowledge-base/glossary/sustainability-data)
* [Circular Economy](/docs/knowledge-base/glossary/circular-economy)
* [ESPR](/docs/knowledge-base/glossary/espr)
* [Delegated Act](/docs/knowledge-base/glossary/delegated-act)

## References

* 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 11179 on metadata registries:
  [https://www.iso.org/standard/78914.html](https://www.iso.org/standard/78914.html)
* International Organization for Standardization, ISO 9001 on quality management systems:
  [https://www.iso.org/standard/62085.html](https://www.iso.org/standard/62085.html)
* International Organization for Standardization: [https://www.iso.org](https://www.iso.org)
* GS1 identification keys, including the GTIN: [https://www.gs1.org/standards/id-keys](https://www.gs1.org/standards/id-keys)
* GS1 EPCIS and Core Business Vocabulary standard: [https://www.gs1.org/standards/epcis](https://www.gs1.org/standards/epcis)
* GS1 General Specifications:
  [https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications](https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications)
* GS1, the global standards organisation: [https://www.gs1.org](https://www.gs1.org)
* 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)
* 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)

## About This Article

About This Article

<dl>
  <dt>
    Last Reviewed
  </dt>

  <dd>
    2026-08-08
  </dd>

  <dt>
    Next Scheduled Review
  </dt>

  <dd>
    2027-08-08
  </dd>

  <dt>
    Article Version
  </dt>

  <dd>
    1.0
  </dd>
</dl>

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 Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data)
* [ERP vs PIM vs PLM: What's the Difference?](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm)
* [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain)
* [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports)