DPP Agent docs

EN 18223 — Digital Product Passport structure and interoperability

EN 18223 answers the last practical question a passport implementer has to solve: what does the data inside the passport actually look like, and can two systems that have never seen each other's data still exchange passports without a bespoke integration?

The two things the standard has to reconcile are in tension. Brand-side systems (PIM, ERP, PLM) each have their own attribute vocabularies developed over decades. A textile brand's PIM might call fibre composition fibre_pct_polyester while a battery brand's PLM calls the same conceptual field chem.cell_polymer_percentage. Regulators, importers, retailers, recyclers and the emerging AI-agent ecosystem cannot integrate against each brand's private schema. EN 18223 sits above the private schemas and defines a canonical vocabulary every conformant passport must map into.

What EN 18223 requires

Five concrete requirements make up the standard.

1. JSON-LD is the canonical serialization

The passport is serialised as JSON-LD (JSON for Linked Data). This is a compact, human-readable JSON shape that includes a @context referring to the DPP vocabulary. A generic JSON parser can read the payload; a JSON-LD-aware reader gets the additional benefit of stable semantic anchors that make the same field unambiguous across all conformant passports.

The @context for a JTC-24-conformant passport points to a version-pinned URL published by the JTC 24 secretariat. Brands do not host their own contexts; they reference the standard one. This is what makes cross-vocabulary interoperability work in practice — the linked-data resolver de-references the context, discovers the field semantics, and normalises across schemas.

XML is permitted as an alternative serialization for legacy regulator systems, but JSON-LD is the default. A conformant resolver may refuse XML requests with 415 Unsupported Media Type if it does not maintain an XML pipeline.

2. Canonical DPP vocabulary

The standard defines a canonical vocabulary organised into namespaces. Each namespace corresponds to a coherent domain of passport data:

  • espr.pid.* — product identification (name, brand, GTIN, HS code, TARIC, country of origin)
  • espr.mfr.* — manufacturer (legal name, address, EORI)
  • espr.eo.* — economic operator (importer, distributor, marketplace)
  • espr.comp.* — composition and substances (materials, recycled content, substances of concern)
  • espr.env.* — environmental performance (carbon footprint, water use, recyclability)
  • espr.care.* — care and repair (instructions, spare parts, expected lifetime)
  • espr.cert.* — certifications (OEKO-TEX, GOTS, Nordic Swan, EU Ecolabel etc.)
  • espr.eol.* — end of life (take-back paths, disassembly, WEEE handling)
  • espr.circ.* — circularity (repair, refurbish, resale)
  • espr.journey.* — supply-chain journey (tiered supplier data, chain of custody)

Category-specific delegated acts extend these with domain namespaces (tex.* for textiles, bat.* for batteries, ict.* for information and communication technology, tyr.* for tyres, etc.). Every category-specific field must declare an equivalence to a canonical namespace field where one exists, so a reader who only knows the canonical vocabulary can still access the data at reduced fidelity.

3. Field-level metadata

Every field in the passport carries metadata in addition to its value:

  • unit — SI or explicitly declared alternate (percentage, kilogramme, litre etc.)
  • source_type — how the data was obtained (measured, calculated, supplier-declared, third-party-certified, AI-extracted)
  • evidence_url — if applicable, a link to supporting documentation (test report, certificate)
  • verified_by — if the field has been externally verified, the identity of the verifier
  • verified_at — the date of verification, so the reader can weight the field appropriately when the certification expires

Metadata is what makes the passport machine-actionable. A regulator's compliance tool can automatically distinguish a supplier-declared recycled-content claim from a Textile Exchange-verified one and treat them differently in enforcement action.

4. Cross-schema equivalence

The standard requires each canonical field to declare its equivalence to at least two adjacent vocabularies:

  • schema.org — for AI-search and general web indexing
  • GS1 — for retail and supply-chain integration

Optional equivalences are common for CIRPASS-2 (the reference profile), OpenPeppol (for e-invoicing), and category-specific vocabularies (Textile Exchange Impact Layer, IEC 62474 for electronics, ISO 15118 for e-mobility).

The equivalence declarations let a reader that knows one vocabulary translate to another without a bespoke mapping. In practice this means the same passport data can be consumed unchanged by an AI shopping agent (schema.org), a warehouse-management system (GS1), a compliance validator (CIRPASS-2) and a category-specific auditor.

5. Versioning of the schema itself

The vocabulary evolves. Fields get added when a new regulation extends disclosure requirements; fields get deprecated when a category's delegated act supersedes them. The standard requires:

  • A version-pinned @context URL that never changes semantics for a given version
  • A version stanza in every passport declaring which JTC-24 schema version it conforms to
  • A deprecation policy: deprecated fields remain readable for the full retention window of any passport that used them

This lets a 2028 reader parse a 2027 passport correctly even if the 2027 vocabulary has evolved. Non-conformant "we broke old passports because our schema is newer" behaviour is prohibited.

Common mistakes

Emitting proprietary field names. A brand's PIM exports fields with brand-internal names and the resolver serves them unchanged. Compliant validators see fields they don't recognise and mark the passport as incomplete. Fix by mapping to canonical namespaces at write time.

Missing units. A carbon footprint appears as "footprint": 42.5 without a unit. Is that kilogrammes of CO2-equivalent per unit? Per kilogramme? Per functional unit? The reader cannot tell. Fix by always emitting unit metadata.

Confusing source_type. A brand marks all data as "supplier-declared" because that's the safe legal default. Regulators reading the passport downgrade the entire disclosure as unverified even when some fields were properly measured or certified. Fix by using accurate source_type values and letting downstream tools weight them.

No cross-schema equivalences. The passport uses the canonical vocabulary but doesn't declare equivalence to schema.org or GS1. AI-search agents can't parse the semantics and consumer readers don't get useful downstream integrations. Fix by including the standard equivalence declarations in the @context.

Deprecating fields silently. The brand's PIM is upgraded and starts emitting new field names for the same conceptual data. Old passports still resolve, but readers who cached the old field names get 404s on individual attributes. Fix by supporting the aliases for the full retention window.

How DPP Agent implements EN 18223

The DPP Agent data model uses the canonical namespaces directly. Every attribute the platform ingests is mapped to a espr.* or category-specific tex.* / bat.* / ict.* key at creation time. The resolver emits JSON-LD with the version-pinned canonical @context by default, and offers ?schema=cirpass-2 to switch to the CIRPASS-2 reference profile.

Cross-schema equivalences are baked into the field catalogue: every canonical field carries equivalent_to metadata pointing to schema.org and GS1 anchors. The AI-Suggest system uses this to propose mappings from brand-private PIM attributes to canonical fields with high accuracy.

Field-level metadata is a first-class concern of the platform: source_type, evidence_url, verified_by and verified_at are captured for every field where they apply, and surfaced to consumer, regulator and recycler audiences differentially.

Practical checklist

  • Passport is serialised as JSON-LD with a version-pinned canonical @context
  • Every field uses the canonical namespace (or an explicit equivalence declaration)
  • Units are declared for every quantitative value
  • source_type is accurate rather than defensively marked as supplier-declared
  • Cross-schema equivalences (schema.org, GS1, CIRPASS-2) are present
  • Deprecated fields remain readable via aliases for the full retention window
  • Field metadata (verified_by, verified_at) is surfaced differently to different audiences

Standard reference

CEN/CENELEC JTC 24. EN 18223:2025 — Digital Product Passport — Structure and interoperability.

Companion vocabularies:

  • W3C JSON-LD 1.1
  • schema.org (2025 release)
  • GS1 Web Vocabulary
  • CIRPASS-2 reference profile (v2.1)