# How We Know: Sources, Status and Evidence for Digital Product Passport Requirements

Source: https://activatedigital.ai/knowledge/digital-product-passport/methodology
Last verified: 1 September 2026
Summary: How ActivateDigital distinguishes EU law, adopted future rules, official development, adjacent law and uncertainty in Digital Product Passport research.

## In 60 seconds

ActivateDigital separates **what the law requires**, **what has been adopted but applies later**, **what regulators are developing**, **what is required under other law** and **what current evidence does not yet establish**. That separation is necessary because DPP information changes at different speeds and because a Commission study, a Working Plan, an adopted Regulation and a vendor checklist do not have the same legal weight.

- Enacted EU legislation in the Official Journal or EUR-Lex sits at the top of the source hierarchy. Vendor blogs are not regulatory authority.
- A Working Plan date is not a deadline. A compliance date needs an adopted legal basis and the applicable application provisions.
- A Commission or JRC study is not binding law. The May 2026 textile DPP study is not the final textile delegated act.
- Not established does not mean No. The evidence has not reached the threshold to state the claim with greater certainty.
- Battery access rights: Article 77(9) set **18 August 2026**. That statutory deadline has passed and the Commission currently signals Q4 2026 delivery.
This page explains the **regulatory evidence method** used for the Digital Product Passport Observatory. It is separate from **product evidence**: how a business proves that a particular product contains 80% cotton, has a given test result or was made at a particular facility. For product evidence, use [Passport Evidence: How We Know, and What a Blank Means](https://activatedigital.ai/knowledge/evidence). For all categories, use [Digital Product Passport Requirements by Product Category](https://activatedigital.ai/knowledge/digital-product-passport). For how the engine decides product values, use [the product truth methodology behind the engine](https://activatedigital.ai/methodology).

## Regulatory evidence versus product evidence

| Question | Regulatory evidence | Product evidence |
|---|---|---|
| **What are we trying to prove?** | What the law, official plan or regulatory development currently says. | Whether a specific fact about a specific product is substantiated. |
| **Typical sources** | EU Regulations, delegated/implementing acts, Commission pages, Working Plans, official studies, standards decisions. | Supplier declarations, laboratory reports, certificates, technical files, ERP/PIM records, measurements. |
| **Typical failure** | Treating a study or vendor interpretation as law. | Publishing a product value that the underlying evidence does not support. |
| **Canonical ActivateDigital destination** | This methodology and the Observatory claim/source layer. | [Our evidence pages](https://activatedigital.ai/knowledge/evidence). |

The word **evidence** applies to both, but they are not the same workflow.

## Two labels, not one

A source can be official without the claim inside it being an applicable product requirement. So two things are labelled separately on this site: **what kind of source is being read**, and **what status the claim inside it has reached**.

A Working Plan can be official and still be indicative. A study by the Joint Research Centre can be official, detailed and still preparatory. A harmonised standard can carry legal effect for the technical requirements it covers without deciding whether a product group needs a passport at all. An adopted product act can be binding while a particular requirement inside it applies only later.

That separation is what stops "the EU published this" from becoming "my product must do this now". The stage-by-stage version is at [how a DPP requirement becomes applicable](https://activatedigital.ai/knowledge/regulation/how-dpp-requirements-take-effect).

Status attaches to a **claim**, not to a page and not to a product. One page can carry an applicable framework rule, an indicative Commission date, a proposed measure and product-specific requirements that are still not established.

## The source hierarchy

For material regulatory claims, ActivateDigital uses the strongest available source in this order.

### 1. Enacted EU legislation / Official Journal / EUR-Lex

This is the primary basis for claims such as:

- a passport is legally required
- a law applies from a fixed date
- a mandatory field appears in an Annex
- access or granularity is specified in adopted law.
Where the exact Article or Annex is known, the legal provision is preferred over a generic landing page.

### 2. Adopted delegated or implementing acts

These can add the product-specific or technical rules that a parent Regulation leaves to the Commission.

An adopted implementing act is different from a roadmap saying an act is planned.

### 3. European Commission implementation material

Official Commission pages, Registry material and implementation guidance are used to explain:

- current operational status
- implementation timelines
- Registry availability
- guidance on how adopted provisions are being prepared or applied.
Where Commission shorthand conflicts with the exact legal scope, the legislation remains the controlling source for the legal claim.

### 4. Official institutional guidance and Working Plans

A Working Plan can establish that a product group is prioritised and indicate expected timing.

It does **not** make every proposed field mandatory and does not turn an adoption target into a compliance date.

### 5. Official studies and consultations

These are valuable for understanding direction.

The May 2026 textile DPP study, for example, explores production sites, origin, circularity and other information territories. It is strong evidence of official development. It is not the final textile [delegated act](https://activatedigital.ai/knowledge/regulation/what-a-delegated-act-decides).

### 6. Official standards bodies / harmonised-standard decisions

Standards claims are checked against the relevant standards decision and standards bodies.

A standard can be important or harmonised without making a vendor-specific implementation technology universally mandatory.

### 7. Credible secondary sources

Used only where needed for explanation or discovery.

They do not override primary law for a mandatory legal claim.

### Why vendor blogs are not regulatory authority

Vendor content can be useful for:

- finding terminology
- seeing implementation patterns
- identifying common market questions
- discovering a primary source to verify.
It is not sufficient authority for claims such as:

- “every DPP must use GTIN”
- “textile factory data is already mandatory”
- “all DPPs are item-level”
- “Q4 2027 is the textile compliance deadline”.
Those claims have to survive a primary-source check.

## The authority and status matrix

The hierarchy above answers what kind of source is being read. This matrix says what each class of source can and cannot establish on its own, and how the claim inside it is usually labelled.

| Source / authority class | What it can establish | What it cannot establish by itself | Typical status treatment |
|---|---|---|---|
| Law / adopted act | A binding framework or product rule, within its own scope and dates | That every provision applies to every product immediately | The status of the claim itself, which may be applicable now, adopted but applying later or awaiting national implementation |
| Product-specific rule | The data, actor, carrier, granularity, access, date or procedure actually specified for that product regime | A universal passport rule for other product groups | The actual status and product scope of that regime |
| Official Commission guidance | The Commission's current explanation of implementation or interpretation | Obligations beyond the underlying law | Guidance does not set the lifecycle status; the underlying claim keeps its own |
| Working Plan / preparatory | Priority, direction, planned timing and evidence of policy development | A current product mandate or a final field list | Usually indicative, or in official development |
| Official study, including JRC work | Evidence, methodology, options and recommendations used in policy development | A business requirement unless it is adopted into law | Usually in official development, for the policy claim it supports |
| Harmonised standard | Presumption of conformity for the requirements it covers, where the legal conditions for that effect are met | Product-group passport scope, product dates or a required field list | Technical conformity effect is recorded separately from the product rule's status |
| Credible secondary source | Discovery, context or corroboration | The evidential basis for a legal obligation | Never stronger than the primary source it reports |

### The public claim statuses

The statuses used across the regulation pages on this site, and on the [EU Product Regulation Action Radar](https://activatedigital.ai/knowledge/regulation/what-applies-today), are APPLICABLE NOW, ADOPTED - APPLIES LATER, TRANSPOSITION / NATIONAL IMPLEMENTATION, IMPLEMENTING MEASURE PENDING, DELEGATED MEASURE PENDING, PROPOSED, IN OFFICIAL DEVELOPMENT, INDICATIVE and NOT ESTABLISHED.

PROPOSED and IN OFFICIAL DEVELOPMENT are not interchangeable. A formal proposal that has not been adopted is not the same position as preparatory work with no proposal on the table, and collapsing the two loses the difference a reader needs.

### Two labels that are not lifecycle statuses

**Required under other law** is a requirement basis: it records that the fact or action is already required by a different instrument, rather than by the passport rule being discussed. Textile fibre composition under Regulation (EU) No 1007/2011 is required under other law while the final textile passport treatment remains future. It says where the duty comes from, not how far the passport rule has travelled.

**Not applicable** is a scope outcome: the regime or field does not meaningfully apply in the context. Food is expressly outside the scope of the Ecodesign for Sustainable Products Regulation. That is an answer about scope, not a stage in a rule's life.

A single badge cannot answer three questions at once. Where a claim is recorded in a structured way, source class, claim status and requirement basis stay in separate fields, alongside instrument, provision, scope, condition, effective date, last verified and freshness trigger.

This page explains how authority and status are classified. What currently applies, what has changed and what a business should do about it belong to the [Action Radar](https://activatedigital.ai/knowledge/regulation/what-applies-today), and the stages a requirement passes through belong to [how a DPP requirement becomes applicable](https://activatedigital.ai/knowledge/regulation/how-dpp-requirements-take-effect).

## The public status taxonomy

The Observatory uses controlled public states.

### Required now

The relevant legal requirement currently applies.

### Adopted, applies later

The requirement is in adopted law, but its application date has not arrived.

Example: the Battery Passport is adopted and applies from [18 February 2027](https://activatedigital.ai/knowledge/digital-product-passport/timeline) for covered battery categories.

### Proposed / draft

An official legislative or regulatory draft exists but is not final law.

### In official development

There is a Commission plan, official study, preparatory process or other strong institutional development signal, but the final requirement is not settled.

Example: textile DPP product-specific rules at the 1 September 2026 verification point.

### Required under other law

The information is already legally required under a different regulatory regime, but is not established as DPP content in the context being discussed.

Example: textile [fibre composition](https://activatedigital.ai/knowledge/fields/fibre-composition) under Regulation (EU) No 1007/2011 while final textile DPP treatment remains future.

### Not established

Current evidence does not establish the claim.

**Not established does not mean No.**

It means the evidence has not reached the threshold needed to state the claim as law or official development with greater certainty.

### Not applicable

The regime or field does not meaningfully apply in the context.

Example: food is expressly outside ESPR product scope.

## Evidence and claim states, and qualifiers

Below a formal regulatory status sit two claim states, and beside every status sits a separate set of qualifiers. They do different jobs.

### Evidence suggests, not established

There is meaningful evidence pointing in a direction, but not enough to call the claim a settled requirement.

### Industry claim, not verified

The claim appears in market or vendor content but has not been verified against sufficient primary or official evidence.

These two labels stop a plausible statement from quietly becoming law through repetition.

### Qualifiers are separate from status

A claim can be legally adopted and still need a qualifier, because status and qualifier answer different questions: the status says what the claim has become, and the qualifier says under what condition it holds. The controlled qualifiers are **conditional**, **optional**, **mixed**, **restricted**, **implementation pending** and **indicative date**.

Read together they carry the cases a single label would flatten. The Battery Passport is **Adopted, applies later**, with some data and access detail **implementation pending**. A Q4 2027 textile delegated act is **In official development** with an **indicative date**. Battery legitimate-interest information is an adopted architecture with **restricted** access.

A qualifier is never a status and a status is never a qualifier. **Indicative date** in particular is a qualifier and nothing else: it says a date is not fixed, and it never becomes a lifecycle state in its own right.

## What counts as law, what a study is and what a Working Plan date is

A Regulation, Directive, Decision or formally adopted delegated/implementing act has legal status according to the EU legal framework and its own provisions.

A Commission web page can explain that law. A study can support future policy. A Working Plan can set priorities.

Neither becomes enacted law merely because it is official.

So every material claim is worded to match its evidence class:

- **“Regulation X requires…”** for adopted law
- **“The law is adopted and applies from…”** for future application
- **“The Commission currently plans…”** for an official plan
- **“Official preparatory work considers…”** for studies
- **“Current evidence does not establish…”** for unresolved claims.

### Is a Commission study a requirement?

No.

A Commission/JRC study can be high-quality official evidence and still not be binding law.

For textiles, the May 2026 study is the kind of evidence worth using for **WATCH** decisions. It should not be transformed into a final mandatory field list.

### Is a Working Plan date a deadline?

No.

The ESPR Working Plan indicates regulatory priorities and expected timing for product measures.

A planned delegated-act date is a date for a future regulatory decision. A compliance date needs an adopted legal basis and the applicable transition/application provisions.

So the Observatory timeline labels every material date by type.

See [Digital Product Passport Timeline: What Applies When?](https://activatedigital.ai/knowledge/digital-product-passport/timeline).

## What is adjacent law?

Adjacent law is existing regulation that requires useful product information but is **not itself proof that the same information is DPP content**.

Examples include:

- textile fibre-composition law
- tyre-label/product-database rules
- food information and traceability
- cosmetics PIF/notification requirements
- GPSR product identity
- REACH substance obligations.
Adjacent law matters because businesses can often structure the data now. The Observatory labels it **Required under other law** rather than upgrading it to DPP status.

## How conflicts are handled

Sources can disagree or appear to point to different dates.

The method is:

- preserve both claims
- compare legal authority
- compare publication/currentness
- identify whether the difference is a true contradiction, a scope difference or an implementation delay
- state the current best interpretation
- keep the conflict visible where it remains consequential.

### Example: Battery access rights

Battery Regulation Article 77(9) set **18 August 2026** as the date by which the Commission should adopt the detailed legitimate-interest implementing act.

The Commission's current DPP roadmap instead shows **Q4 2026**.

The Observatory does not silently replace the statutory date with the roadmap date. It records that the statutory deadline has passed and that the Commission currently signals Q4 2026 delivery.

## What "Last verified" means, and when a page is rechecked

It means the material, time-sensitive claims on the page were checked against the relevant current primary or official sources on that date.

It is not a decorative publication date.

A page should be reverified when a trigger occurs, for example:

- a delegated or implementing act is adopted
- a fixed application date arrives or changes
- the Commission changes its implementation roadmap
- a new standards decision is published
- Registry guidance changes
- a product-specific field, access or granularity rule becomes final.

### How often is the information updated?

Update cadence follows the nature of the resource.

### Event-driven

Timeline, category status, access, [granularity](https://activatedigital.ai/knowledge/guides/granularity) and factory/origin references should be reviewed when a material regulatory event occurs.

### Living

Identifiers and readiness need review when standards, product-specific rules or important implementation guidance changes.

### Periodic

The methodology itself changes less frequently, but should be reviewed when source hierarchy, public status language or governance policy changes.

A monthly rewrite is not a substitute for event-driven evidence review.

### What happens when a source changes?

The system should record:

- prior public position
- new evidence
- source and date
- affected claims/resources
- whether the change is material
- whether a settled shared claim requires a controlled update rather than a silent one.
If the new source only clarifies an implementation detail without changing the shared claim, it can be logged without rewriting the core truth.

If it overturns a frozen shared fact, it needs an explicit evidence-update record rather than silent divergence.

## What our freshness labels mean

A source can be authoritative and still change. So a current page needs to show not just what source it uses, but which version or source state was checked and what event would force another review.

**Last verified** is the date a human review checked the relevant source state for the page. It is not automatically the same as `dateModified`.

**Primary source** is the strongest authority used for the page's central current claim. A page can still cite other official, standards or operational sources for different claims.

**Source version** is the exact version or publication identifier of a genuinely versioned dependency, such as a user guide or a standard. It is kept separate from the host webpage's own update date, because those two values move independently and often disagree.

**What changed** is a short note, and only where a material source change altered the page's current answer, interpretation or workflow.

**What we're watching** is the named event that would require the page to be checked again: publication of a delegated act, a new Official Journal standards decision, a version change in an operational guide. Not "regulation may change", which is true of everything and tells you nothing.

Where a page cannot supply one of these honestly, the field is absent rather than filled. An empty label that looks answered is worse than no label.

## The public/private method boundary

ActivateDigital should be transparent about:

- source hierarchy
- legal status language
- how uncertainty is handled
- why a source is considered stronger
- last-verified dates
- material change history.
It does **not** need to expose proprietary internal extraction, scoring, reconciliation or research-orchestration machinery.

Public trust comes from reproducible claims and visible primary sources, not from publishing every internal workflow detail.

## Short language, precise destination

Not every user-facing surface needs to carry the full title and status of an EU act. Short-form product and marketing language can be simpler when the underlying meaning is defensible.

The control is the route beneath it: the shorthand should resolve to a canonical Knowledge page, that page should say what is and is not established, and the evidence supporting it should be named and current.

So a compact readiness phrase can exist on a product surface while the Knowledge owner carries the legal status, scope and source qualification. Simplification is not authority. Traceability is the control.

## The two vocabularies, and what they each answer

This page covers two vocabularies that answer different questions. Collapsing them into one ladder is the most common way a reader is misled about this site, so they are declared here together and never presented as a single scale.

- **Legal status** answers what law or rule exists and what formal status it has reached. It is the taxonomy set out above.
- **Deployment and evidence maturity** answers how strongly a claimed capability or practice is demonstrated. Its four values are **NOW**, **EMERGING**, **POSSIBLE** and **NOT_SUPPORTED**.
A thing can be legally required and not demonstrated. A thing can be demonstrated and not legally required. Wherever the maturity values appear on any page on this site, they grade deployment and evidence rather than law, and the page carrying them says so.

Two universal rules travel with the maturity vocabulary, and they are our own evidence discipline rather than a cited external rule:

- **A standard is not deployment.** A published standard establishes that a method exists and can be referred to. It does not establish that anybody has implemented it.
- **A pilot is not established practice.** A demonstration establishes that something was done once, under conditions its authors chose. It does not establish that it works at scale, or for anybody else.
Specialist pages elsewhere on this site use this vocabulary and summarise these two rules to their own reader intent, and they link here. They do not cover either. Where a page carries a maturity table, that table grades deployment rather than law, and it is not deleted or converted into a legal-status table to make a page look tidier.

## Direct answers

### What sources does ActivateDigital use?

Primary EU legislation first, then adopted delegated/implementing acts, Commission implementation material, official guidance/Working Plans, official studies and standards sources.

### What does “Not established” mean?

Current evidence does not establish the claim. It is not a definitive No.

### Why not use vendor blogs as authority?

They can be helpful secondary material, but they are not sufficient proof of a mandatory legal requirement.

### What does “Last verified” mean?

The material time-sensitive regulatory claims were checked against current primary/official evidence on that date.

### What happens when sources conflict?

The conflict is preserved, authority and timing are compared and the current best interpretation is stated without hiding unresolved tension.

## Living references

Three maintained reference pages sit across this methodology: the change log records material source movement, the claims audit checks recurring claims and the glossary keeps names and aliases consistent. None of them replaces the substantive canonical article.

- [material DPP source changes](https://activatedigital.ai/knowledge/status/dpp-regulatory-change-log)
- [check a recurring DPP claim](https://activatedigital.ai/knowledge/status/dpp-claims-audit)
- [DPP and product-data glossary](https://activatedigital.ai/knowledge/glossary)

## Keep exploring

The questions this page usually raises next.

- [Evidence behind thisRelated KnowledgeHow should evidence provenance and blanks be handled?Natural deeper or practical continuation.→](https://activatedigital.ai/knowledge/evidence)
- [Broader questionPassport coreWhere is this status model applied across categories?→](https://activatedigital.ai/knowledge/digital-product-passport)
- [CompareCross-category referenceHow are planned and indicative dates labelled?→](https://activatedigital.ai/knowledge/digital-product-passport/timeline)

## Primary sources and governance anchors

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) EU law
- [JRC/Product Bureau, Study in support of the Digital Product Passport for textiles](https://susproc.jrc.ec.europa.eu/product-bureau/sites/default/files/2026-05/Textiles_DPP_20260513.pdf) Official study
- [Regulation (EU) 2023/1542 concerning batteries and waste batteries](https://eur-lex.europa.eu/eli/reg/2023/1542/oj) EU law
- [European Commission, Textile apparel and the Digital Product Passport](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/textile-apparel_en) European Commission
- [Regulation (EU) No 1007/2011 on textile fibre names and labelling](https://eur-lex.europa.eu/eli/reg/2011/1007/oj) EU law
- [ESPR and Energy Labelling Working Plan 2025–2030, COM(2025) 187 final](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52025DC0187) Official guidance
- [European Commission, Digital Product Passport implementation timeline:](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en) European Commission
*This methodology explains how regulatory claims are classified and sourced. It is not a substitute for product-specific legal advice.*