How to Validate Digital Product Passport Data

Executive Summary

A Digital Product Passport is a published statement about a product. Once it is published, the information it carries can be read by customers, recyclers, distributors, market surveillance authorities and competitors, and it may be relied upon in ways the publisher never anticipated. That places a control question at the centre of every passport programme: how does an organisation decide that a specific piece of information is acceptable and safe to publish?

The answer is not that the information exists. It is not that a trusted system produced it, and it is not that a supplier submitted it. Existence and submission are the beginning of the control process, not the end of it. Information becomes publishable by passing defined controls that are proportional to the data element, its source, its regulatory significance, its intended use, the evidence supporting it and the lifecycle state of the product it describes.

This article sets out The DPP Data Validation Control Model, a vendor neutral model that combines four governed data states, submitted, validated, accepted and publishable, with a taxonomy of thirteen validation control classes and an explicit exception and remediation route for information that fails. Its central principle is controlled progression: information moves forward only by passing a control, and never by default.

The model also fixes a vocabulary problem that causes real programme failures. Data quality, validation, verification, evidence and approval are treated as interchangeable in most organisations. They are not. Validation can confirm that a recycled content value is numeric, between zero and one hundred, correctly attributed to a product and accompanied by an evidence reference. It cannot confirm that the claim is true. Verification addresses the claim. Acceptance decides whether the organisation will use the information. Publication control decides who may see it. Collapsing those four decisions into one is how unverified claims reach public pages, and how confidential information reaches audiences it was never intended for.

Table of Contents

• Definition
• Why DPP Data Validation Matters
• Data Quality vs Validation vs Verification
• The DPP Data Validation Control Model
• State 1: Submitted
• State 2: Validated
• State 3: Accepted
• State 4: Publishable
• Rejected Data and Exception Handling
• The 13 Validation Control Classes
• Building a Validation Rule Catalogue
• Validation Severity
• Automated vs Human Validation
• Validating Internal Enterprise Data
• Validating Supplier Data
• Validating Lifecycle and Event Data
• Validating Compliance Information
• Data vs Evidence
• Validation vs Verification
• Access and Publication Validation
• Validation Across the DPP Implementation Roadmap
• Monitoring Validation in Operation
• Practical Example
• Validation Metrics
• Common Mistakes
• Frequently Asked Questions
• Key Takeaways
• Related Glossary Terms
• References

Definition

Two parts of that definition do the heavy lifting. Specific product information distinguishes validation from a general assessment of a dataset: validation is applied to a value, for a product, from a source, at a point in time. Only by passing the controls that apply establishes the default. In an uncontrolled process, information is publishable unless someone objects. In a controlled process, information is not publishable unless it has passed.

Why DPP Data Validation Matters

Because publication is an assertion, not a display. When an organisation publishes recycled content, substance information, repairability information or a compliance statement in a passport, it is making a statement about the product. The statement can be relied on by a purchaser, examined by an authority and quoted by a competitor. Information that has not passed defined controls should not become an assertion.

Because obligations attach to the publisher. As set out in Economic Operator, EU product legislation attaches duties to defined roles rather than to whoever happened to originate a value. The organisation placing the product on the market generally carries responsibility for the information it publishes, regardless of which system or supplier produced it. Validation is one of the few mechanisms that converts that responsibility into a repeatable control.

Because passport data arrives from many sources with different trust characteristics. As described in How Product Data Moves Through the Supply Chain, information moves across organisational, system and format boundaries before it reaches a passport. Each boundary is an opportunity for loss, distortion, mismatched units and stale values.

Because errors at scale are not individually visible. A passport programme may publish millions of values. Nobody reads them all. The only realistic mechanism for detecting systematic error is a rule that runs every time, which is what validation is.

Because correction after publication is expensive. A passport is expected to remain correct over a product lifetime, as explained in How Does a Digital Product Passport Work?. Withdrawing or correcting a published claim is materially harder than declining to publish it.

Because validation makes governance operational. The accountability structures described in What is Product Data Governance? remain theoretical until they are expressed as rules that actually stop something. A validation rule with an owner and a severity is governance that has been implemented.

Data Quality vs Validation vs Verification

These five terms are used interchangeably in most organisations, and the confusion has consequences. Each answers a different question.

Data quality is a property of a body of information, assessed across dimensions such as completeness, accuracy, consistency, validity, timeliness and traceability, as described in What is Product Data Quality?. It tells the organisation how good its information is.

Validation is an operation applied to a specific value at a specific moment. It tells the organisation whether that value may proceed. Quality dimensions frequently inform which validation rules are worth writing, but a quality assessment is a diagnosis and a validation rule is a control.

Verification looks past the value to the claim behind it. A recycled content figure can pass every syntactic and structural rule and still be unsupported by the documentation attached to it.

Evidence is the material that verification examines. It is a distinct object with its own lifecycle, scope and expiry, and it is not the same thing as the value it supports.

Approval is a decision, taken by an authorised party, that information may progress. It is needed where judgement or accountability is required, and it should not be imposed where a deterministic rule is sufficient.

These concepts interact constantly. They are not synonyms, and a programme that treats them as synonyms usually ends up either verifying everything, which is unaffordable, or verifying nothing, which is indefensible.

The DPP Data Validation Control Model

The model has two halves that work together.

A. Data states. Information occupies exactly one governed state at any moment: submitted, validated, accepted or publishable, plus the exception state for information that has failed a control. States are recorded, not implied, so that at any point the organisation can say what was known about a value and when.

B. Validation controls. Between each pair of states sits a control gate. Gate one applies validation controls, gate two applies acceptance controls, and gate three applies publication controls. Each gate can pass information forward, hold it with a warning or raise an exception.

The design principle is controlled progression. Information does not become publishable through the passage of time, through the absence of objection or through arrival in a particular system. It becomes publishable by passing the controls that apply to it.

Two clarifications matter before the states are described in detail. First, the model is proportional: the number and depth of controls applied to a given element should reflect its regulatory significance and risk, not a desire for uniformity. Second, the model is not sequential in calendar terms. A value may be validated in milliseconds at ingestion and accepted automatically, while another may take weeks because it requires evidence review and approval.

State 1: Submitted

Information has entered the process. It may have originated from product lifecycle management, enterprise resource planning, product information management, manufacturing execution, compliance systems, traceability and event systems, suppliers, manual processes or other authoritative sources as described in What is an Authoritative Source?.

Submitted means received. It does not mean valid, accepted, verified, trusted or publishable.

The value of naming this state explicitly is that it stops the most common architectural mistake in passport programmes: writing incoming information directly into the record that feeds publication. Once submitted information is indistinguishable from accepted information, the organisation has lost the ability to answer the only question that matters after an incident, which is what was known at the time of publication.

A submitted record should carry, at minimum, the value, the product or batch it relates to, the source, the submission timestamp, the submitting party and any evidence references provided with it. That metadata is what every later control depends on.

State 2: Validated

The information has passed the applicable validation rules. Depending on the element, those rules may cover required field presence, format, syntax, identifier structure, allowed values, ranges, units, cross field consistency, relationships, reference data, business rules, lifecycle state, regulatory rules, evidence presence and validity periods.

Two properties of this state are frequently misunderstood.

Validated is relative to the rules that exist. A value is validated against the rule set the organisation has written, not against reality. Weak rules produce validated information that is still wrong. This is why rule quality is governed, and why a high pass rate is not by itself a positive signal.

Validated is not verified. Passing a rule that says a percentage must lie between zero and one hundred says nothing about whether the percentage is correct. The distinction is developed in Validation vs Verification.

A validated record should carry the rule set version applied, the outcome per rule, the timestamp and any warnings raised. This is what makes the state auditable rather than assumed.

State 3: Accepted

The organisation’s governed process has accepted the information for its intended use. Acceptance is a decision about use, and it may depend on source authority, validation result, evidence, verification, stewardship, approval, exception resolution and risk level.

Acceptance is where authority and validation combine. A value may be validated but come from a source that is not authoritative for that element, in which case the correct outcome is not acceptance but reconciliation with the authoritative source, following the source of truth principles described in What is a System of Record?.

Not every element requires manual approval. For deterministic, low risk elements from authoritative sources, acceptance can and should be automatic once validation passes. Human approval should be reserved for material claims, ambiguous evidence, conflicting sources, regulatory interpretation and exception resolution. A process that requires a person to approve every value does not produce better information, it produces a queue, and queues produce approvals given without attention.

The stewardship roles described in What is Product Data Stewardship? are the natural home for acceptance decisions that do require judgement, because acceptance is an ownership act rather than a technical one.

State 4: Publishable

The information is approved for inclusion in a defined publication context. This is the state most often missing from passport implementations, and its absence is the reason confidential information sometimes appears in public passport views.

Publishability may depend on access classification, confidentiality, regulatory scope, audience, product lifecycle state, jurisdiction, effective date, evidence validity and version. The same accepted value may be publishable to an authority, publishable to a defined economic operator and not publishable to the general public.

Accepted enterprise information is not necessarily publishable passport information. An accepted supplier cost, an accepted internal formulation detail or an accepted site identifier may all be correct, validated, accepted and entirely unsuitable for public disclosure. Publishability is therefore evaluated per audience and per publication context, not once per value.

Because publication context varies, publishable is better modelled as a set of permissions attached to a value than as a single flag. The Access and Publication Validation section develops this.

Rejected Data and Exception Handling

Information that fails an applicable control must not silently progress, and it must not silently disappear. Silent progression publishes error. Silent disappearance produces gaps that nobody owns, which is the more common failure and the harder one to detect.

The explicit route is:

1. Validation failure. A control returns a failure at the applicable severity.
2. Exception. A record is created describing the value, the product, the source, the rule and the outcome.
3. Owner. The exception is assigned to a named owner: a supplier contact, a data steward, a system owner or a compliance owner.
4. Remediation. The issue is corrected. This may be automatic normalisation, supplier resubmission, steward correction, evidence replacement or escalation.
5. Revalidation. The corrected information is validated again from the appropriate earlier state, not waved through because someone worked on it.
6. Accept or reject. The information is accepted, or it is permanently rejected with the reason recorded.

Failures fall into recognisable categories, and the category should determine the route:

• Automatically correctable. Unit normalisation, case standardisation, known code mappings. These should be corrected deterministically and recorded, never left in a human queue.
• Supplier remediated. Missing values, expired certificates, wrong product linkage. These belong to the supplier process described in How to Prepare Suppliers for Digital Product Passports.
• Steward remediated. Internal inconsistencies, reference data gaps, mapping errors.
• Escalated. Conflicting authoritative sources, regulatory interpretation, material claims that cannot be substantiated.
• Permanently rejected. Information that cannot be substantiated or is out of scope. Rejection is a legitimate outcome and should be recorded as one.

The 13 Validation Control Classes

The following taxonomy is a practical implementation vocabulary, not a regulatory classification. It exists so that rules can be designed, reviewed and discussed consistently.

1. Completeness. Is required information present? Required is contextual: required for the product category, for the market, for the lifecycle state or for a specific publication context. Absence of an optional element is not a failure.

2. Format and syntax. Does the value conform to the expected structure, data type, encoding, decimal representation, date format or unit representation? Format failures are the most common and the most automatable class.

3. Identifier. Is the identifier structurally valid, correctly attributed and appropriate for the level being described? An identifier that is valid but points at a model rather than a batch is a control failure even though the check digit is correct. Identifier concepts are described in Product Identifier.

4. Reference data. Does the value correspond to an approved classification, code list, controlled vocabulary or unit of measure? This class turns free text into governed values and is where most downstream consistency is won or lost.

5. Range and domain. Is the value within permitted or plausible boundaries? Percentages between zero and one hundred, masses greater than zero, dates not in the future where that is impossible. Plausibility ranges catch a substantial share of transcription error.

6. Cross field consistency. Do related values agree? Component masses that exceed product mass, a recycled content percentage with no material specified, a date of manufacture after a date of placing on the market.

7. Cross system consistency. Does the value conflict with authoritative information held elsewhere? This class depends on knowing which system is authoritative for which element, which is precisely the discipline described in What is Product Master Data?.

8. Business rule. Does the information satisfy defined organisational rules? Approved supplier lists, internal naming standards, mandatory attribute sets for a product family, permitted material declarations.

9. Regulatory rule. Does the information satisfy an applicable legal requirement where one exists and is defined? These rules should cite their legal source, and they should be written only where the requirement is actually determinate, which for many product groups it is not yet.

10. Lifecycle rule. Is the information appropriate for the product’s current lifecycle state? A disposal instruction on a product not yet placed on the market, or a production attribute changed after production closed, are lifecycle failures rather than format failures. See Product Lifecycle.

11. Evidence rule. Where evidence is required, is appropriate supporting evidence present, linked to the correct product scope and currently valid? This class checks the presence and integrity of evidence. It does not judge whether the evidence substantiates the claim, which is verification.

12. Temporal and validity rule. Is the information currently valid? Effective dates, expiry dates, superseded versions, and values whose validity is bounded by a production period.

13. Access and publication rule. May this information be exposed to the intended audience in the intended context? This class is evaluated at the publication gate and is developed in Access and Publication Validation.

Not every element requires all thirteen controls. A marketing description may need completeness and format. A substance declaration may need eleven of them. Validation should be rule driven and proportional, and the proportionality decision belongs to governance rather than to engineering convenience.

Building a Validation Rule Catalogue

Rules that exist only in code are invisible to the people accountable for them. A validation rule catalogue makes the rule set an artefact that compliance, data governance and technology can review together.

For each material rule, the following fields are useful in practice:

This is implementation practice, not a legally prescribed format. No regulation requires a rule catalogue in this shape.

Three governance properties make the catalogue worth maintaining. Rules are versioned, so a validation result can be interpreted against the rules in force at the time. Rules have owners, so a disputed rule has an addressee. Rules have review dates, so rules written against draft requirements are revisited when those requirements are finalised, rather than silently hardening into permanent controls.

Validation Severity

Not all failures should have identical consequences. Treating every failure as fatal produces a programme that cannot publish. Treating none as fatal produces a programme that publishes anything.

Three illustrative levels are sufficient for most implementations:

Blocking. Information cannot progress toward publication. Appropriate for missing mandatory regulatory elements, invalid product identifiers, expired evidence supporting a material claim and values that contradict an authoritative source.

Warning. Information may progress under defined conditions but requires attention. Appropriate for plausibility ranges, non preferred reference values, approaching expiry dates and completeness gaps in optional but desirable elements.

Informational. The issue is recorded but does not prevent progression. Appropriate for stylistic or enrichment observations that are useful in aggregate.

These are implementation examples, not regulatory classifications.

Severity must itself be governed, for three reasons. Severity is a business decision, not a technical one, because it determines what the organisation is prepared to publish. Severity drift is the most common way controls weaken, since the fastest way to clear a blocked publication queue is to downgrade a rule, and that change is often invisible. Severity determines cost, because blocking rules create remediation work and warnings create monitoring work.

A practical control is to require that any change of severity from blocking to warning is recorded with a reason and an owner, and reviewed. That single discipline prevents most silent erosion of a validation programme.

Automated vs Human Validation

Automation and stewardship are complements, and the design question is which decisions belong where.

Automation is well suited to: format and syntax, completeness against a defined requirement set, ranges and plausibility bounds, identifier structure and check digits, controlled vocabularies and reference data, cross field arithmetic and consistency, duplicate detection, expiry and effective date checks, and deterministic business rules. These checks are fast, repeatable, consistent, and they scale to the volume a passport programme actually generates.

Human judgement remains necessary for: ambiguous evidence, conflicting authoritative sources, unusual exceptions that no rule anticipated, regulatory interpretation where requirements are open to reading, high risk or material claims, and approval decisions where accountability must rest with a person.

Two cautions matter.

Automation does not eliminate stewardship. It changes what stewards spend time on, moving them from checking formats to resolving genuine ambiguity, which is the work that actually requires judgement.

Artificial intelligence is not a requirement of validation. The overwhelming majority of useful validation is deterministic rule execution. Where machine assistance is used, for example in document extraction or anomaly detection, the output should be treated as submitted information subject to the same controls as any other source, not as a validated result.

Validating Internal Enterprise Data

Information from an internal system should not be considered valid simply because the system is trusted. Authority and validity are related but different properties.

A product lifecycle management system may be the authoritative source for an engineering attribute. The specific value it holds for a specific product may nevertheless be missing, outdated, incorrectly formatted for the publication context, expressed in a unit that does not match the required representation, or entirely appropriate internally and inappropriate for disclosure.

Authority answers which source decides the value of an element. Validation answers whether this particular value passes the controls. Conflating them produces the most persistent misconception in enterprise data programmes, that authoritative equals correct.

Three internal patterns deserve specific controls:

Attributes maintained for a different purpose. Values maintained for engineering, procurement or logistics were designed for those uses. Reusing them for public publication introduces meaning mismatch that only cross system consistency and business rule checks detect.

Values that are stale rather than wrong. An attribute correct at design time may have been superseded by an engineering change. Temporal rules and change triggers catch these, formats do not.

Free text where a controlled value is required. Internal systems tolerate free text far more readily than publication contexts do. Reference data controls are where this is resolved.

Validating Supplier Data

Supplier information crosses an organisational boundary, which changes both the risk profile and the remediation route. The supplier process itself is described in How to Prepare Suppliers for Digital Product Passports and is not repeated here.

What the validation model adds is proportional control. The rules applied to supplier information should reflect:

• Supplier segment, so that critical suppliers providing regulated attributes receive deeper control than suppliers whose information carries no publication dependency.
• Attribute significance, so that a substance declaration is controlled more tightly than a descriptive characteristic.
• Evidence requirement, so that claims requiring evidence are blocked when evidence is absent, out of scope or expired.
• Risk, including the consequence of publishing the value incorrectly.
• Regulatory significance, so that legally determinate elements carry blocking severity.

The exception route for supplier failures runs back to the supplier, and its effectiveness depends on the supplier knowing in advance which rules apply. Publishing the applicable rule set to suppliers, in plain language, converts a large share of validation failures into submissions that never fail in the first place.

Validating Lifecycle and Event Data

Event and lifecycle information behaves differently from attribute information. Attributes describe what a product is. Events describe what happened to it, and they arrive continuously, in sequence, often from multiple parties. The relevant background is in What is EPCIS? and Product Traceability.

Useful controls for event information include:

• Valid product or instance identifier, resolving to a known product, batch or item.
• Event timestamp, present, correctly formatted, time zone qualified and plausible relative to the current time.
• Event type, drawn from a defined vocabulary rather than free text.
• Location, resolving to a known and permitted location identifier.
• Sequence, so that an event does not precede an event it logically depends upon.
• Duplicate detection, since replayed or resent messages are routine in event pipelines.
• Impossible lifecycle transitions, such as a repair event recorded after a recorded end of life, which are logical failures rather than format failures.

EPCIS provides a widely used vocabulary and structure for this kind of information, and where it is in use it makes several of these controls straightforward. It is not universally mandatory, and the controls above apply regardless of the exchange format chosen.

Event validation also differs in remediation. An incorrect attribute can be corrected in place. An incorrect event usually cannot be edited without destroying the value of the event record, so the remediation pattern is a compensating or correcting event, with the original retained.

Validating Compliance Information

Regulatory and compliance information carries the highest publication consequence and usually depends on evidence rather than on a value alone. Controls that are frequently appropriate include:

• Applicable product scope, confirming the compliance information actually relates to the product, variant or batch being published.
• Document or evidence presence, where a claim depends on a document.
• Issuing body, where the identity of the issuer is relevant to the claim.
• Validity dates, covering issue date, expiry date and the production period being described.
• Version, so that a superseded document is not treated as current.
• Jurisdiction, since a document valid in one market may not support a claim in another.
• Product linkage, connecting the document unambiguously to the product identity it covers.

Two disciplines matter here. Do not invent universal evidence requirements. What evidence is required, and whether third party involvement is needed, depends on the applicable legislation, the product group and, for the ecodesign framework, the delegated act for that product group, as described in Delegated Act. Many product groups do not yet have final requirements.

Distinguish the categories of rule. A rule derived from Regulation (EU) 2024/1781 or a delegated act is a legal requirement. A rule derived from an industry standard is a standard. A rule the organisation imposes on itself because it is unwilling to publish unsupported claims is a business control. All three are legitimate, and they should be labelled differently in the catalogue because they have different change drivers and different consequences of failure.

Data vs Evidence

Data and evidence are different objects, and conflating them produces validation rules that cannot be satisfied.

Data is the value being published: recycled content is forty percent.

Evidence is the material that may support the claim: a test report, a supplier declaration, a certificate, a mass balance record, an audit result.

They differ in four practical ways. Lifecycle: a value changes when the product changes, while evidence expires on its own schedule. Scope: evidence covers a defined product, batch, production period or site, and its scope frequently does not match the scope of the claim it is attached to. Authority: evidence often originates from a third party whose identity matters. Publication: the value is frequently publishable while the evidence itself is not.

Evidence therefore needs its own attributes in the validation model: what it covers, who issued it, when it was issued, when it expires, what version it is, and which claims reference it. An evidence rule checks those attributes. It does not read the document and conclude that the claim is true.

Validation vs Verification

This distinction deserves its own treatment, because it is where passport programmes most often overstate what their controls achieve.

A supplier submits: recycled content 40%.

Validation may establish that:

• the field is present where it is required
• the value is numeric
• the value lies between 0 and 100
• the unit and representation are correct for the required format
• the value is attributed to a product identity the organisation recognises
• a required evidence reference exists and is linked
• the referenced evidence is currently within its validity period

Every one of those checks can pass while the claim is false.

Verification may establish that:

• the referenced documentation actually substantiates a forty percent recycled content figure
• the documentation covers the material, product and production period in question
• the methodology behind the figure is one the organisation accepts

Approval may establish that:

• the organisation accepts the claim for the intended use, given the evidence and the residual risk
• an authorised party has taken that decision and it is recorded

Publication control may establish that:

• the accepted value may appear in the passport for the intended audience, in the intended jurisdiction, at the product’s current lifecycle state, in the version being published

Four different questions, four different controls, four different owners in most organisations. A programme that runs only the first has a well formatted claim. A programme that runs all four has a defensible one.

Note also what is not being claimed here: not every claim requires third party verification. Whether independent verification is required depends on the applicable legislation and product group. What the model requires is that the organisation knows which of the four controls it has actually applied.

Access and Publication Validation

A value can be valid, and accepted, and still not publishable to every audience.

Publication control asks a different question from every preceding gate: not is this right, but may this be shown, to whom, where and when. Examples of information that may be accepted and restricted include:

• Commercially sensitive information, such as supplier identity, cost structure or precise formulation.
• Restricted technical information, such as detailed disassembly information intended for qualified handlers.
• Information intended only for authorities, provided for market surveillance rather than public display.
• Information available only to defined economic operators, such as repairers, recyclers or distributors operating under defined conditions.

The ecodesign framework anticipates exactly this differentiation: the Digital Product Passport provisions of Regulation (EU) 2024/1781 contemplate that different information may be available to different actors, with the specifics set by the delegated act for a product group. Publication control is therefore not merely an internal confidentiality preference, it is how a programme implements an access model that is expected to vary by product group and audience.

Practically, this means the publishable state is evaluated per audience and per context. The same accepted value may be publishable to an authority, publishable under conditions to a defined operator, and not publishable publicly. Modelling publishability as a single boolean is the most frequent cause of over disclosure, because it forces a binary decision on information whose access rules are inherently plural.

Access controls should also account for effective dates, since information may become publishable only when a product is placed on the market, and for lifecycle state, since some information becomes relevant only at end of life.

Validation Across the DPP Implementation Roadmap

Validation is not a phase. It is a control that is designed, built, proven and then operated across the stage gated model described in How to Build a Digital Product Passport Implementation Roadmap. It is most visible at five stages.

Stage 3, data and source assessment. Validation begins as diagnosis. Assessing sources reveals which elements are missing, inconsistent or unowned, and that assessment is what tells the programme which rules are worth writing.

Stage 6, build and integrate. Rules are implemented where they can actually run: at ingestion, in integration, in the governed store and at publication. The catalogue written earlier becomes executable here rather than being invented here.

Stage 7, validate and assure. The rule set itself is proven. This stage tests whether rules fire correctly, whether severities are right, whether exceptions route to real owners and whether the process can clear its own queue.

Stage 8, pilot and deploy. Real information meets the rules at realistic volume. Pilots are where unrealistic blocking rules and unowned exception queues are exposed, and it is far cheaper to discover them there.

Stage 9, operate, scale and improve. Validation becomes a running operational control with metrics, revalidation triggers, rule reviews and a governed change process.

Within the reference architecture set out in Building an Enterprise Digital Product Passport Architecture, validation is not a single component. It operates across the trust and governance capability, which owns the rules, the severities and the acceptance decisions, and the integration and orchestration capability, which executes many of them as information moves. Together they control what may progress into the logical passport service, which is the architectural expression of the same principle: the passport publishes governed information rather than becoming the place where governance happens.

Monitoring Validation in Operation

Validation is not a one time event, because the conditions that made a value publishable are themselves unstable. Information that was correctly published last year may not be publishable today.

Revalidation triggers worth implementing explicitly:

• Data change. A source value changes and must re enter the pipeline at the submitted state.
• Evidence expiry. A certificate or test report reaches its expiry date, which should return every dependent claim to an exception rather than leaving it published unnoticed.
• Product change. A specification, component or material change invalidates dependent claims.
• Supplier change. A change of supplier or manufacturing site invalidates supplier specific evidence and provenance.
• Regulatory change. A new delegated act or amended requirement changes which elements are required and which rules apply.
• Lifecycle state change. Information appropriate in one state may be inappropriate in another.
• Validation rule change. When a rule changes, previously validated information was validated against a different rule set, and the organisation must decide whether to revalidate the estate.

The last trigger is the one most often ignored, and it is the one with the largest blast radius. Tightening a rule without revalidating existing published information leaves a population of values that would fail today, published on the strength of a rule that no longer exists.

Practical Example

A manufacturer produces a domestic appliance. One material sustainability attribute is followed through the complete model: the recycled content of the polymer housing.

Submitted. A component supplier submits, through the agreed exchange mechanism, a record stating that the housing polymer contains forty percent recycled content, attributed to a component part number, with a reference to a supporting test report. The record is stored as submitted, with the source, the timestamp, the submitting organisation and the evidence reference. Nothing is published.

Validation controls run. In sequence:

• Format validation passes. The value is numeric with a permitted decimal representation, and the unit is expressed as a percentage in the required form.
• Range validation passes. The value lies between zero and one hundred, and within the plausibility band configured for polymer recycled content.
• Identifier and product linkage validation passes. The component part number resolves to a known component, and that component resolves to the appliance model being assembled.
• Evidence presence validation passes. The referenced test report exists, is attached, and is linked to the claim.
• Evidence validity validation passes. The report is within its stated validity period.

The information moves to validated. At this point the organisation knows the value satisfies its rules. It does not yet know the claim is supported.

An issue emerges at acceptance. During acceptance review, a steward examines the evidence and finds that the test report covers a production period that ended before the batches now being manufactured. The report is genuine, current in date, and does not clearly cover the product batch in question. This is not a validation failure, because every rule passed. It is a verification finding, raised at the acceptance gate.

The exception route runs:

• An exception is raised against the claim, with severity blocking, because a recycled content claim is material and regulated in the relevant market.
• An owner is assigned: the supplier quality contact internally, with the supplier as the remediating party.
• Supplier clarification is requested, specifying precisely what is missing, which is evidence covering the current production period.
• New evidence is supplied: an updated test report covering the current period.
• Revalidation runs from the submitted state, because the evidence reference has changed. Evidence presence and validity checks pass again, and evidence scope now matches the batch scope.
• Verification is repeated against the new evidence, and the claim is judged supported.

The information moves to accepted, with the acceptance decision, the accepting party, the evidence version and the timestamp recorded.

Publication controls run. The accepted value is then evaluated for each publication context:

• Public audience. The recycled content percentage is publishable. It is a consumer relevant sustainability characteristic with no confidentiality restriction.
• The supporting test report. Not publishable to the public audience. It identifies the component supplier and contains commercially sensitive methodology, so it is retained and made available to authorities on request.
• Component supplier identity. Not publishable publicly under the organisation’s access policy.
• Jurisdiction and effective date. The claim is published only for markets where the required format applies, and only once the product is placed on the market.

The value reaches publishable for the public passport view, while the evidence and the supplier identity remain accepted and restricted.

Note precisely which control did what. Format, range, linkage, evidence presence and evidence validity were validation. Whether the report substantiated the claim for those batches was verification. The decision to use the claim once evidence was corrected was acceptance. The decision about who may see the value, the evidence and the supplier identity was publication control. Four controls, four questions, one value.

Validation Metrics

Useful operational measures include:

• Validation pass rate. Proportion of submitted records passing all applicable rules first time.
• Blocking failure rate. Proportion of records raising at least one blocking failure.
• Warning rate. Proportion of records raising warnings, tracked separately because warnings accumulate silently.
• Failure rate by rule. Which rules fire most, which identifies both bad data and bad rules.
• Failure rate by source. Which systems and processes produce the most failures.
• Failure rate by supplier. Supplier level performance, feeding the supplier monitoring process.
• Exception backlog. Open exceptions, with ageing.
• Mean remediation time. How long an exception takes to resolve, by category and by owner.
• Revalidation rate. Proportion of the estate revalidated in a period, and why.
• Expired evidence rate. Published claims whose supporting evidence has expired, which should ideally be zero.
• Accepted to publishable conversion. How much accepted information reaches each publication context, which exposes access model behaviour.
• Recurring failure rate. Failures repeating on the same element, source or supplier, which indicates a process problem rather than a data problem.

One caution governs all of them. A high validation pass rate is not evidence of high data quality. If rules are few, weak or narrowly scoped, a pass rate approaching one hundred percent measures the weakness of the rule set rather than the strength of the information. Pass rate should always be read alongside rule coverage, which is the proportion of published elements that have any material rule at all, and alongside rule review currency.

Common Mistakes

Frequently Asked Questions

Is there a universal Digital Product Passport validation standard?
No. There is no single validation standard applicable to all products. Requirements derive from the applicable legislation, from the delegated act for a product group under the ecodesign framework where one exists, from sector legislation such as the batteries regulation, from standards where they are used, and from the organisation’s own business controls. The model in this article is a tieback educational framework for organising those requirements, not a standard.

Does every claim require third party verification?
No. Whether independent verification is required depends on the applicable legislation and the product group. Many claims are supported by supplier declarations or internal records. What matters is that the organisation knows which level of assurance it has applied to each claim, rather than assuming one level applies to all of them.

Where should validation run: at ingestion, in the data layer, or at publication?
Usually all three, with different rules at each point. Format, syntax and identifier checks belong at ingestion where feedback is fastest. Cross system consistency and business rules belong where governed information is assembled. Access, audience, jurisdiction and effective date rules belong at publication, because that is the only point where the publication context is known.

How many validation rules should a programme start with?
Fewer than most programmes expect. Start with mandatory element completeness, identifier validity, reference data conformity and evidence presence for material claims. These four classes catch a large share of the failures that would otherwise reach publication, and they are cheap to automate.

What is the difference between a rejected value and a warning?
A rejected value has failed a blocking control and cannot progress until remediated or overridden through a governed exception. A warning records a concern while allowing progression. The difference is a governed decision recorded in the rule catalogue, not a technical property of the check.

Who owns validation?
Ownership is shared and must be explicit. Data governance owns the rule catalogue and severities, compliance owns the regulatory basis of regulatory rules, data stewards own exceptions and acceptance decisions for their domains, and technology owns execution. A single accountable owner should sit above these for the rule set as a whole.

Can validation be applied retrospectively to already published passports?
Yes, and it usually must be. When rules change or evidence expires, previously published information should be revalidated and, where it now fails, corrected or withdrawn according to the organisation’s change process. Passports are expected to remain correct over a product lifetime, not only at the moment of first publication.

Does the model require a specific technology?
No. The four states, three gates and thirteen control classes describe controls, not components. They can be implemented in integration tooling, in a data quality platform, in a governed master data environment, in a passport service, or across several of these. What matters is that the states are recorded and the gates actually stop things.

Key Takeaways

Related Articles

• How to Prepare Suppliers for Digital Product Passports
• How to Manage Evidence for Digital Product Passports
• How to Operate a Digital Product Passport Programme
• How Should Organisations Prepare for Digital Product Passports?
• How to Build a Digital Product Passport Implementation Roadmap
• How to Test and Assure a Digital Product Passport
• Building an Enterprise Digital Product Passport Architecture
• What is Product Data Quality?

Related Glossary Terms

• Digital Product Passport
• Product Data Quality
• Product Data Governance
• Product Data Stewardship
• Authoritative Source
• System of Record
• Product Master Data
• Data Architecture
• Economic Operator
• Product Traceability
• Product Identifier
• Product Lifecycle
• Delegated Act

References

• Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, including the Digital Product Passport provisions, Official Journal of the European Union: https://eur-lex.europa.eu/eli/reg/2024/1781/oj
• Regulation (EU) 2023/1542 concerning batteries and waste batteries, including the battery passport and due diligence provisions, Official Journal of the European Union: https://eur-lex.europa.eu/eli/reg/2023/1542/oj
• Regulation (EU) 2019/1020 on market surveillance and compliance of products, Official Journal of the European Union: https://eur-lex.europa.eu/eli/reg/2019/1020/oj
• Regulation (EC) No 1907/2006 concerning the Registration, Evaluation, Authorisation and Restriction of Chemicals, including supply chain information duties: https://eur-lex.europa.eu/eli/reg/2006/1907/oj
• European Commission, ESPR working plan 2025 to 2030, COM(2025) 187: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025DC0187
• European Commission, The Blue Guide on the implementation of EU product rules: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0629%2804%29
• ISO 8000, data quality: https://www.iso.org/standard/81745.html
• GS1 EPCIS and Core Business Vocabulary standards: https://www.gs1.org/standards/epcis
• GS1 identification keys, including the GTIN: https://www.gs1.org/standards/id-keys
• EUR-Lex, official portal for European Union law: https://eur-lex.europa.eu

About This Article

Related Docs

• Implementation
• How to Prepare Suppliers for Digital Product Passports
• How to Build a Digital Product Passport Implementation Roadmap
• How Should Organisations Prepare for Digital Product Passports?
• Building an Enterprise Digital Product Passport Architecture
• What is Product Data Quality?
• What Information Does a Digital Product Passport Contain?
• What is EPCIS?