Digital Product Passport Work Starts With a Shared Attribute Dictionary

DPP data fails when fields mean different things

A seller can collect product data for years and still lack readiness for passport-style disclosure. One team may call material composition the bill of materials. Another may use a supplier declaration. A third may use packaging copy.

The first useful document is an attribute dictionary. It defines each field, source, owner, update trigger and acceptable evidence. Without that dictionary, the business collects data that looks complete but cannot survive review.

The useful file starts with the operating record, not with a policy label. Name the product, account, route, supplier or claim that creates the exposure. Then attach the evidence that a reviewer would need if the issue appears during a platform review, border question, customer dispute or payment hold. A short file built before pressure arrives beats a long explanation written after the facts scatter across systems.

Case pattern: three material answers

A product team lists recycled plastic, sourcing stores a generic resin note and marketing uses a broad sustainability phrase. When a customer asks for detail, the seller has three answers for the same product.

The issue is not missing effort. The seller lacked a shared dictionary that tells teams which field controls public data.

The correction should not sit inside one private message. Put the decision in the shared file, name the owner and record the next trigger. That gives the next employee a way to understand why the team accepted, changed, paused or escalated the issue.

Create the dictionary before tooling

A data platform cannot fix undefined fields. Build the dictionary in a spreadsheet first and test it against ten active SKUs.

Assign owners by field. Sourcing may own supplier data, product may own material scope and support may own repair route. The dictionary should show that split.

• Define each product attribute.
• Name source system and evidence.
• Assign field owner.
• Set update trigger.
• Test against active SKUs.

Operator check

Start with one live example rather than a whole catalogue. Pull the current product page, one recent order, one customer-facing message and the internal evidence file. If those four records tell different stories, the business has a control gap that will grow during the next campaign, shipment or supplier change.

The operator should write down the exact mismatch. Avoid vague notes such as review needed. A useful note says which SKU, market, claim, document, route or account setting does not match, who owns the fix and which customer or platform promise depends on it.

Pick one SKU and ask three teams for material composition. If their answers differ, the dictionary needs work before any passport project scales.

• Choose one live SKU.
• Compare sourcing, product and marketing records.
• Write field definitions.
• Assign update owners.

Handoff note

The handoff should be readable in ten minutes. It should name the business owner, the file owner, the missing record, the accepted limit and the next review date. If the answer depends on a person remembering a call or searching a chat thread, the file is too fragile for a fast-moving marketplace operation.

Keep the handoff beside the working file. Supplier issues belong with order and supplier records. Product issues belong with listing, label, sample and complaint records. Payment or account issues belong with finance approval and access logs. The folder matters because future questions rarely arrive when the original reviewer is free to explain the history.

Add one expiry trigger. The trigger can be a product version change, new market, route change, supplier change, platform policy update, complaint pattern or certificate date. Without a trigger, teams keep citing evidence that no longer fits the live business.

Run one monthly sample while the topic remains active. The sample should test one live order, one public page and one internal record against the file. If the sample passes, record the date and leave the file alone. If it fails, fix the specific gap and note whether the same issue could affect other SKUs, suppliers, routes or accounts.

This keeps the control practical. A seller does not need a committee for every small issue. It needs a rhythm that catches drift before the drift reaches customers, platforms or border documents.

Closing note

Digital product passport work begins with field meaning, not software.

A shared dictionary turns scattered product data into evidence the business can maintain.

Reference links

• European Commission digital product passport consultation