EPU Disclosure and Digital Product Passport Architecture

1. Core principle

EPU is not the Digital Product Passport.

The EPU and its Product Graph provide the governed product intelligence foundation. A DPP is a controlled disclosure projection over that foundation according to applicable product, jurisdiction, framework, audience and effective-date requirements.

EPU
 │
 ├── product identity
 ├── product graph
 ├── evidence
 ├── lifecycle
 ├── sustainability results
 └── assurance
        │
        ▼
 Disclosure Profile
        │
        ├── DPP
        ├── regulator view
        ├── customer disclosure
        ├── recycler view
        ├── verifier view
        └── public / marketing view

2. Disclosure profile

A disclosure profile should govern at least:

• framework or regulatory basis;
• jurisdiction;
• product category;
• audience/recipient class;
• effective period;
• required and optional fields;
• evidence requirements;
• assurance requirements;
• confidentiality/access policy;
• presentation and machine-readable serialization rules;
• disclosure version.

Pergamum Pulse can eventually provide authoritative regulatory requirement lineage for these profiles.

3. One graph, multiple views

The same EPU can support multiple authorized views without duplicating product identity or creating separate uncontrolled datasets.

EPU Product Graph
      │
      ├── consumer view
      ├── recycler view
      ├── customs/regulator view
      ├── verifier/auditor view
      ├── supplier contribution view
      ├── manufacturer internal view
      └── machine/API view

Access policy must be enforced at query and disclosure time so confidential supply-chain or commercial data is not exposed merely because it is connected to the EPU.

4. Data carrier and resolver

A QR code, NFC carrier or other physical data carrier should not be treated as the EPU itself.

Physical product
      │
      ▼
Data carrier (QR / NFC / other)
      │
      ▼
Resolver / interoperable identifier
      │
      ▼
EPU or product-instance resolution
      │
      ▼
Access + disclosure policy
      │
      ├── DPP
      ├── repair information
      ├── recycling information
      ├── compliance information
      └── APIs / other services

Where established standards such as GTIN and GS1 Digital Link are applicable, ZAYAZ should interoperate with them rather than invent a competing public identification mechanism.

5. Product instance context

The resolver may identify only the product definition or may include batch/lot or serialized-item context where required.

EPU
 ├── product-level disclosure
 ├── batch-specific disclosure
 └── serialized-item disclosure

This permits a stable product identity while supporting more granular provenance and lifecycle information when regulation or business value requires it.

6. Disclosure readiness

ZAYAZ should be able to evaluate readiness for a disclosure profile before publication.

Disclosure requirement set
        ↓
traverse EPU Product Graph
        ↓
resolve required values/evidence
        ↓
validate authority + quality + TrustGate
        ↓
identify missing requirements
        ↓
trigger source/supplier workflows
        ↓
re-evaluate
        ↓
publish authorized disclosure

The result can expose readiness, missing data, evidence quality and blocking issues without changing the EPU identity.

7. Separation of sustainability facts and marketing claims

Public marketing content and compliance badges must be derived from governed claims and evidence rather than becoming authoritative product facts themselves.

A marketing statement should be traceable to the underlying result, evidence, method and assurance state that permits the claim.

This supports consistent disclosure across DPP, websites, product labels, customer documentation and other channels while reducing unsupported or stale sustainability claims.