- CWA 18186 supports controlling restricted access, upload rights, supplier-manufacturer ESG data integration, and DPP information trust.
"representatives of all stakeholders who have the rights to upload information"
Validate supplier inputs before they become passport data, registry fields, public claims, restricted records, or evidence links.
Use source owner, product link, access class, data model fit, evidence quality, and approval records as the core controls.
Structured answer sets in this page tree.
Cited legal and guidance references.
Supplier data validation for an EU Digital Product Passport is the control that decides whether a supplier-provided value is complete enough, linked to the right product identifier, supported by usable evidence, and approved for the access level where it will appear. Under the ESPR, delegated acts specify passport data for product groups, and Annex III points to product identifiers, operator and facility identifiers, commodity codes, compliance documentation, instructions, manufacturer and importer information, and the passport service provider reference. The validation file should therefore connect each supplier input to the product, the source owner, the evidence, the access class, the data model field, and the release approval.
Start the intake with product identity and ownership, not with a broad sustainability claim. The supplier submission should state the product model, batch, order, or item level used by the passport; the manufacturer, importer, operator, or facility identifier it supports; the commodity code or product group context when available; and the internal data owner who can correct the value.
Treat each supplier value as a passport candidate record. It should carry a topic or vocabulary name, the claimed value, unit or Boolean value where relevant, source or criteria reference, evidence URI or document reference, assurance level, access class, approval status, and the date or version of the supplier submission.
Use this guide to define the source owner, product link, access class, evidence quality check, data model mapping, and approval record before supplier data reaches a passport.
A useful validation review separates six checks. First, confirm that the supplier is the right source owner for the value. Second, confirm the value is linked to the correct product, not a related family or marketing range. Third, confirm the evidence is usable for the claimed field. Fourth, confirm the value fits the passport data model and vocabulary. Fifth, assign the access class before publication. Sixth, record who approved the value for passport use.
Do not promote a value into the passport simply because a supplier uploaded a document. Reject or hold the value when the product link is missing, the unit does not fit the target field, the evidence does not identify the relevant product, the access class is unclear, or the supplier cannot explain the method used to create the value.
Supplier validation should decide where each accepted value can appear. Public passport data should be limited to fields approved for open access. Restricted data should be routed through roles, permissions, or authority-facing channels when the field contains commercially sensitive information, technical documentation, conformity evidence, supplier detail, or write access to the passport record.
The access class should be attached to the data field, not buried in a policy. A reviewer should be able to see whether the value is public, B2B-restricted, authority-restricted, or withheld pending a product-group delegated act, and whether the data carrier, resolver, portal, and backup copy use the same classification.
Every supplier input should end with an approval outcome that can be reviewed later. The approval record should identify the accepted value, rejected value, or held value; the data model field; the source owner; the product link; the evidence reference; the access class; the reviewer; and the reason for the outcome.
Use versioning for changes. If a supplier revises a value, changes a calculation method, replaces evidence, or changes the affected product scope, the passport team should keep the prior version, review the new evidence, and approve the updated value before it changes a public or restricted passport view.
Most DPP supplier-data failures are traceability failures. The passport value may be plausible, but the evidence does not prove the value for the exact product, the source owner is unclear, the access class is missing, or the field does not fit the target data model.
A stronger implementation keeps rejected and held records visible to the passport team. That prevents weak supplier data from re-entering the workflow through a later portal upload, manual spreadsheet change, or public claim review.
"representatives of all stakeholders who have the rights to upload information"
"claimed values as a metric"
"draw up the required technical documentation"