Packaging data readiness: PPWR is not a universal product passport

The reassuring part of the analysis is that most of the data a business would need under either instrument is data a well-run business should have anyway. The value of building it does not depend on which requirement ultimately applies.

A bill of materials is the foundation: what a pack is made from, component by component, including coatings, adhesives, layers and any minor components that a simple material description omits. This is the same information the classification exercise needs, and it is the information that is most often missing or out of date.

Stable identifiers come next. A pack, and each of its components, should be identifiable by an identifier that persists across versions so that a record can be traced to what it describes. Without stable identifiers, records accumulate without being reliably linked to the thing they describe.

Supplier records matter because composition is established through the supply chain. Recording which supplier provided which component, and when the composition was last confirmed, is what allows a change in supply to be recognised as a change in the pack.

Version history is the fourth. A pack that has been modified has a history, and knowing what changed and when is what allows a business to answer a question about a product sold last year. A single current specification cannot answer questions about the past.

The instinct when a data requirement appears is to buy a system. The instinct is usually premature, and it leads to a platform implemented before anyone has decided who owns which data and how it is maintained.

Modular data ownership means that each piece of data has a named owner — the function or role responsible for its accuracy and currency — before any system is selected. Composition data is owned by whoever manages the supply relationship; identifiers are owned by whoever manages the product master; version history is owned by whoever manages product change. Naming these owners is a management decision, not a technical one, and it is the decision that determines whether a system will work when it is installed.

The reason to do this first is that software implements a data model. If the data model is undecided, the software will impose one, and the imposed model will reflect the vendor's assumptions rather than the business's structure. Migrating away from that later is more expensive than deciding it first.

It is also worth being clear about what the data does and does not establish. A clean bill of materials, stable identifiers and a version history make a business able to answer questions about its packaging accurately and quickly. They do not establish that any particular product requires any particular artefact, because that depends on which requirements apply to that product — which is a question of the instruments, their scope and the product's own characteristics, and not a question that a data model can answer.

The distinction runs both ways. A business that has built good data has not, by doing so, established that a passport obligation attaches to any of its products. And a business that has not built the data cannot establish its position either, because it cannot describe its own packaging accurately. The useful position is to build the data and to keep the applicability question open until it can be settled from the sources.

Keeping the two instruments distinct is not just a technical nicety. It is what prevents a data programme from being scoped around a requirement that may not apply, and it is what keeps the investment useful regardless of how each instrument develops.

The packaging regulation addresses packaging, and the ESPR framework operates through product-specific rules made under it. A business that reads the second as a general obligation on every pack will scope its data programme to produce a passport-style record for every product in its range. That is a large commitment, and if the obligation does not in fact attach generally, the effort has been spent on artefacts rather than on data. The artefacts may be useful; they are not the thing that was needed.

A business that reads the first as covering everything the second addresses has a different problem. It may conclude that its data obligations are settled by the packaging requirements alone, and under-build the underlying data — the composition, the identifiers, the version history — that any requirement would need.

The resolution is to build the underlying data, which is useful on its own merits, and to treat the specific artefacts as things that attach when a requirement places them on a defined product. That way the investment is robust: whatever a specific instrument turns out to require, the business can produce it, because it knows what its packaging is made of and can trace a product's history.

The practical starting point is composition data for the products that matter most, which is the same starting point as the classification exercise discussed elsewhere in this library — and for the same reason. Composition is the input to classification, to design, to footprint work and to any data requirement, and it is the information most commonly missing or out of date.

The first pass need not cover the whole range. Covering the largest products, or those in the categories most likely to attract a requirement, establishes the method and produces a template that can be extended. The second pass extends it. What matters more than coverage in the first pass is accuracy and the assignment of ownership, because data without an owner decays and data that is wrong is worse than data that is absent.

From there, the sequence is identifiers, supplier records and version history — each reinforcing the others. Identifiers make records traceable; supplier records make composition verifiable; version history makes the past answerable. Built in that order, each step makes the next more useful.

Nothing here states that any packaging product requires a digital product passport, or that any requirement applies to any product. The ESPR framework and its product-specific rules, and the packaging regulation, each apply according to their own scope and their own current text.

Where a business needs to establish its position, the questions to answer are which instruments apply to the products it places on the market, what those instruments require of those products, and from when. Those are questions about the instruments as they currently stand, and they should be settled against the source rather than by inference from a general framework or from the way the two are discussed together.

This article's contribution is to keep the two apart and to identify the data that is worth building either way — which is the part of the preparation that does not depend on the answer.