Knowledge BaseEnterprise Systems & Data Architecture

How to Build a Trusted Product Data Foundation

Executive Summary

Organisations rarely fail at Digital Product Passports because the passport itself is difficult. They fail because the product information the passport is supposed to present does not yet exist in a state fit for publication. It is spread across systems, held at different levels of accuracy, owned by nobody in particular, and refreshed by whoever happens to notice that it is wrong.

A trusted product data foundation is the capability that fixes this, and it is built in stages. No organisation moves from spreadsheets to automated, governed, continuously improving product data in a single programme. It progresses, and the progression is predictable enough to plan against.

This article sets out The Product Data Maturity Model, six levels in sequence. Level 1, Data Collection, establishes that the data exists somewhere identifiable. Level 2, Data Quality, makes its condition measurable. Level 3, Governance, gives it owners, definitions and rules. Level 4, Integration, connects the authoritative sources so values stop being copied by hand. Level 5, Automation, removes the manual effort from validation and publication. Level 6, Continuous Improvement, turns the foundation into something that gets better on its own evidence rather than decaying.

The model is diagnostic as well as prescriptive. Most organisations beginning a passport programme sit between Level 1 and Level 2, and most difficulties encountered mid-programme are the result of attempting work that belongs two levels above where the organisation actually is. Integrating ungoverned data, or automating unmeasured data, produces faster versions of existing problems.

Everything here is vendor neutral. The levels describe organisational capability, not products, and they apply equally to a manufacturer with two hundred products and one with two hundred thousand. The difference is the degree of formality required, not the sequence.

FrameworkTBF-024
The Product Data Maturity Model

Grades product data capability across six levels, from collection to continuous improvement, per attribute domain.

Table of Contents

Definition

Definition
Trusted Product Data Foundation

A trusted product data foundation is the combined set of sources, definitions, quality controls, accountabilities, integrations and operating routines through which an organisation can state a fact about a product, show where the fact came from, show when it was last verified, and reproduce that answer consistently at scale. It is the prerequisite for publishing a Digital Product Passport that will survive external scrutiny.

Three distinctions matter, because the phrase is often used loosely.

A foundation is a capability, not a repository. Consolidating everything into one system does not create trust. A single database of unverified values is still unverified, merely centralised. What creates trust is knowing the provenance and the currency of each value.

A foundation is built incrementally, not procured. Every level of the maturity model can be started with the systems an organisation already owns. Tools accelerate the later levels substantially, but they do not allow a level to be skipped.

A foundation is measured by what it can prove, not by what it contains. The practical test is whether the organisation can take one published attribute and, within a day, name its owner, its authoritative source, its last verification date and the change history behind it.

The scope question, answered early

A foundation does not mean all product data. It means the attributes that carry consequence: everything a Digital Product Passport will publish, everything a regulator may ask about, and everything a customer decision depends on. Scoping broadly at the start is the most common reason programmes never reach Level 3.

Why Foundations Matter

The case for a foundation is not abstract. Five specific pressures make it the determining factor in whether a passport programme succeeds.

Publication removes tolerance for approximation. Internally, an imprecise value is absorbed by people who know the context. Published under an ESPR delegated act, it becomes a claim by an economic operator, presented without context to customers, recyclers, retailers and market surveillance authorities.

Obligations arrive in waves, not once. Each new delegated act or market brings additional attributes. Organisations without a foundation repeat the entire data-gathering exercise every time, at full cost. Organisations with one extend an existing capability.

Volume defeats manual work. A programme can be delivered by hand for a hundred products. At ten thousand, manual collation is not slow, it is impossible, and the failure mode is silent: the data is published, but nobody verified most of it.

Much of the data is not yours. Material composition, recycled content, certificates and origin originate with suppliers. Receiving that reliably needs specifications, validity tracking and exception handling, which are foundation capabilities rather than passport features.

Data ages. A passport is durable, and the facts behind it are not. Without a foundation that tracks verification dates and propagates upstream change, a compliant publication quietly becomes an inaccurate public statement.

Example
The two-hundred-product trap

A manufacturer completes a pilot covering two hundred products in four months, assembling data through workshops, spreadsheets and direct outreach to engineers. The result is accurate and the pilot is judged a success. Scaling to twelve thousand products is then estimated by multiplying the effort, which produces an infeasible number. Nothing went wrong in the pilot except that it built an output rather than a capability: no owners were assigned, no definitions written, no sources declared. The second phase starts from zero, at scale.

Best Practice
Build the capability while delivering the obligation

Pilots are valuable when each manual step taken is also recorded as a definition, an owner or a rule. The question at the end of every pilot task should be: what did we just learn that we never have to work out again, and where is it now written down?

The Product Data Maturity Model

Maturity models fail when they describe aspiration rather than sequence. The Product Data Maturity Model is ordered by dependency: each level makes the next one achievable, and attempting a level before its predecessor produces work that must later be redone.

The most common and most expensive error is jumping from Level 1 to Level 4. Integration is visible, technically satisfying and easy to fund. Applied to data that has never been measured or governed, it distributes unreliable values across the estate at machine speed, and it does so with the authority that automation confers.

Six levels, in dependency orderEach level makes the next achievableLevels cannot be skipped, only accelerated
L1
Data CollectionExistence

The organisation knows which product attributes it needs, where each one currently lives, and who to ask for it. Values are gathered, often manually, into a known location. The objective is not correctness yet, it is visibility.

Reached when: an attribute register exists and every required attribute has a named source.

L2
Data QualityMeasurement

The condition of the collected data is measured against agreed dimensions: completeness, accuracy, consistency, timeliness, validity and uniqueness. Defects become specific and countable rather than a general sense that the data is poor.

Reached when: quality is reported per attribute and defects are assignable to a person.

L3
GovernanceAccountability

Ownership, definitions, policies, stewardship and lifecycle rules are established, so measured defects have a route to resolution and agreed meanings stop drifting between functions. This is where data stops being a project artefact and becomes managed.

Reached when: every published attribute has one owner, one definition and one authoritative source.

L4
IntegrationConnection

Authoritative sources are connected so values flow rather than being re-keyed. Identifiers are reconciled across systems, transformations are documented, and lineage from source to publication is retained.

Reached when: no published attribute depends on a manual copy between systems.

L5
AutomationScale

Validation, enrichment, approval routing, publication and re-publication run without routine human intervention. People handle exceptions and judgement; the system handles repetition. Automation is only safe once rules are governed and sources are connected.

Reached when: adding a product to the passport estate requires no bespoke effort.

L6
Continuous ImprovementDurability

The foundation improves from its own evidence. Defect patterns drive rule changes, supplier performance drives specification changes, external corrections drive verification cycles, and new obligations are absorbed as extensions rather than as new programmes.

Reached when: quality trends improve without a programme running to make them improve.

Maturity is assessed per attribute domain, not for the organisation as a whole. Most organisations are at different levels for commercial, technical, regulatory and sustainability data at the same time.

Two properties of the model are worth stating explicitly.

Maturity is not uniform. An organisation is frequently at Level 4 for commercial attributes, because commerce funded that work years ago, and at Level 1 for sustainability data, because nobody previously needed it. Assessing a single organisational level hides the gap that matters.

Levels regress. A foundation left unstaffed after a launch does not hold its position. Owners change roles, suppliers change, definitions stop matching the product range, and an organisation that reached Level 4 finds itself operating at Level 2 with Level 4 infrastructure, which is the most dangerous combination because the automation continues confidently.

Assessing Maturity

Assessment should take days, not months, and should produce a level per attribute domain rather than a single score. Six questions, asked of a representative sample of attributes, are sufficient.

Do we know where this value comes from? If the answer is a person rather than a system, the domain is at Level 1 at best.

Do we know how good it is? If quality is described qualitatively, the domain is below Level 2. Measured means a number, per attribute, produced repeatably.

Do we know who owns it? A function is not an owner. If no individual is accountable for the value being right, the domain is below Level 3.

Does it move without a human? If any published value is copied, exported or re-keyed between systems, the domain is below Level 4, regardless of how much integration exists elsewhere.

Can we add a thousand products without a project? If onboarding requires bespoke effort per product, the domain is below Level 5.

Is it getting better on its own? If quality only improves while a programme is funded, the domain is below Level 6.

Example
A realistic assessment result

A mid-sized manufacturer assesses four domains. Commercial attributes such as descriptions and packaging dimensions sit at Level 4, because a commerce programme integrated them years ago. Technical specifications sit at Level 3, governed but still manually transferred. Regulatory attributes sit at Level 2, measured but unowned. Material composition and recycled content sit at Level 1, because they are held in supplier correspondence. The passport programme is therefore constrained by the material data, not by the average, and the plan should say so.

Best Practice
Assess against published attributes only

Assess the attributes that will appear in a passport, plus those a regulator can reasonably ask about. Assessing the whole product data estate produces a longer report and a slower decision, and it dilutes attention away from the attributes that carry legal consequence.

Improving Maturity

Improvement is a sequence of narrow, completed steps rather than a transformation. The following progression works because each step produces something the next step needs.

From Level 1 to Level 2: measure what you already collected. Take the attribute register, define what good means for each attribute, and produce a first quality report. Expect the initial numbers to be uncomfortable, and resist the impulse to improve the data before measuring it, because unmeasured improvement cannot be demonstrated.

From Level 2 to Level 3: assign, define, and write it down. Name one accountable owner per attribute, agree one definition, declare one authoritative source, and appoint stewards with allocated time. This step is organisational rather than technical, and it is the step most often deferred and most often responsible for later failure. The layered detail is set out in what is product data governance.

From Level 3 to Level 4: connect the authoritative sources. Integrate in order of consequence, not in order of technical convenience. Reconcile product identifiers first, because integration without a reliable key produces confident mismatches. Retain lineage, so a published value can be traced back to the record it came from.

From Level 4 to Level 5: automate the rules, not the judgement. Automate validation, routing, publication and re-publication on change. Keep humans on exceptions, on new attribute definitions and on anything where being wrong has regulatory consequence. Automation applied to a governed rule set is leverage; applied to an ungoverned one it is amplification.

From Level 5 to Level 6: close the loop. Feed defect patterns back into rules, supplier performance back into specifications, and external corrections back into verification cycles. Fund the foundation as a standing operating cost rather than as a project, because a foundation without an owner regresses.

One domain at a time

Moving a single attribute domain from Level 1 to Level 3 delivers more usable capability than moving every domain from Level 1 to Level 2. Depth in the domain that blocks publication beats uniform shallow progress.

Best Practice
Sequence by consequence, not by difficulty

Order the work by what a passport must publish and what a regulator can ask about. Attributes with legal consequence deserve Level 3 governance before attributes with commercial convenience reach Level 4 integration.

Benefits

Obligations become extensions. Each new delegated act, market or product category is absorbed by adding attributes to an existing capability rather than by starting again.

Publication becomes defensible. Provenance, verification dates and change history mean a challenged claim is answered with evidence rather than with reconstruction.

Scale stops being a cost driver. Once onboarding is automated over governed sources, the marginal cost of the ten-thousandth product approaches the cost of the hundredth.

Effort moves from collation to exceptions. Skilled people stop assembling spreadsheets and start resolving the cases that genuinely need judgement.

Suppliers improve measurably. Specified requirements, formats and validity periods change what suppliers return, because most supplier data problems are specification problems rather than willingness problems.

The investment serves more than compliance. The same governed, integrated product data supports commerce, service, sustainability reporting and product traceability, so the cost is not carried by one obligation.

Risk becomes visible before it is external. Quality measurement surfaces defects internally, which is materially cheaper than a retailer, an auditor or a market surveillance authority surfacing them publicly.

Common Mistakes

Common Mistake
Integrating before governing

Connecting systems that hold undefined, unowned values distributes the ambiguity faster and lends it the authority of an automated pipeline. Integration should follow ownership, not precede it.

Common Mistake
Automating unmeasured data

Automation multiplies whatever the rules encode. Without quality measurement there is no way to detect that the rules are encoding a systematic error until it appears in public.

Common Mistake
Treating maturity as a single organisational score

A headline level hides the domain that actually blocks publication. Assess and report per attribute domain, and plan against the weakest domain in scope.

Common Mistake
Scoping the foundation as all product data

Attempting to govern everything produces a multi-year programme that delivers nothing publishable. Scope to published and regulator-relevant attributes, then extend.

Common Mistake
Delivering a pilot instead of a capability

A manual pilot that produces correct data but no owners, definitions or sources leaves the organisation at the same maturity level it started at, with a deadline now closer.

Common Mistake
Funding the foundation as a project

Projects end. Foundations that end regress, and regression is invisible until an external party finds an error. Fund the operating routine, not only the build.

Common Mistake
Excluding suppliers from the maturity plan

Supplier-sourced attributes frequently sit two levels below internal ones. A plan that assesses only internal systems will forecast a readiness date it cannot meet.

Common Mistake
Buying maturity

Platforms accelerate Levels 4 and 5 considerably and can support Levels 2 and 3. None of them assign an owner, agree a definition or decide what a value means. Those remain organisational decisions.

Frequently Asked Questions

How long does it take to build a foundation?
For a scoped set of published attributes, reaching Level 3 typically takes months rather than years, because the work is largely organisational. Levels 4 and 5 depend on the estate and on integration complexity. Level 6 is a change in how the capability is funded and staffed, not a delivery date.

Can we skip a level if we buy the right platform?
No. Tooling compresses the effort at each level, particularly Levels 4 and 5, but a platform cannot assign accountability or agree a definition. Skipping Level 3 in particular tends to surface later as automated publication of disputed values.

Where should an organisation with nothing start?
With an attribute register: the attributes the passport must publish, where each currently lives, and who to ask. That single artefact is Level 1, and it makes every subsequent step assessable.

Does this apply to small organisations?
Yes, with less formality. One person may be owner and steward for several domains, and the register may be a spreadsheet. The sequence is identical; the ceremony is not.

How does this relate to product data governance?
Governance is Level 3 of this model, described in depth in its own article. The maturity model places governance in sequence and explains what must exist before it and what it unlocks after it.

What if a regulatory deadline arrives before we reach Level 4?
Publish from the governed subset and accept manual effort for the remainder, while recording every manual step as a future rule. That is a deliberate trade rather than a failure, provided the capability is being built alongside the output.

How do we measure progress to a board?
Report level per attribute domain, the number of published attributes with a named owner and authoritative source, quality trend per dimension, and the proportion of onboarding that requires bespoke effort. Those four measures describe the foundation without describing the technology.

Can maturity go backwards?
Routinely. Owners move on, suppliers change, definitions stop matching the range. Regression is usually detected externally, which is why Level 6 exists as a level rather than as an aspiration.

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.