The DPP Data Model Guide

A Digital Product Passport is, at heart, a structured data document. What separates it from a web page is that it is machine-readable, semantically defined and versioned. This guide explains how that data is modelled.

Three layers

It helps to think in three layers:

1. Semantics — what the fields mean. EN 18223 defines terminology and the core model; JSON-LD contexts bind concepts to global identifiers.
2. Schema — the type and cardinality of each field, expressed in JSON Schema or OpenAPI.
3. Serialisation — how the data looks on the wire. The practical default is JSON-LD; AAS XML/JSON is common in industrial settings.

See the EN 18223 core data model and JSON-LD and DPP data.

Why JSON-LD?

The CIRPASS-2 reference architecture recommends JSON-LD as the default exchange format for a pragmatic reason: it is readable by an ordinary JSON client and interpretable as linked data. W3C Verifiable Credential packages are also natively JSON-LD, so signed, verifiable data sets travel in the same format. See verifiable credentials.

Modular templates

Rather than one giant schema, the model is modular: each product group inherits shared core modules (identity, operator, compliance) and adds its own (fibre composition for textiles, cell chemistry for batteries).

Sector models

• Battery Pass Data Model — canonical RDF/Turtle with generated JSON Schema, JSON payloads, OpenAPI, AAS XML, JSON-LD contexts and Java classes. Seven categories, ~107 data points.
• Catena-X CX-0143 — SAMM 2.1.0 aspect models; passports published as submodels in a decentralised Digital Twin Registry. See AAS and Catena-X.
• IDTA AAS submodel templates — Digital Nameplate, Product Carbon Footprint, Material Composition, Circularity and others.
• UNTP — Digital Product Passport, Digital Facility Record, Digital Traceability Events and Digital Conformity Credential, all as W3C VCs. See UNTP.

Versioning and integrity

Passport data changes over time: a repair is logged, a certificate is renewed, a recycled content share is updated. The reference architecture and EN 18221 require append-only versioning, not overwriting:

• Every update creates a new timestamped version.
• Updates are recorded with signed receipts.
• Older versions stay reachable, so an audit can answer "what was declared at that date?"

In practice this means the passport store has to be event-sourced or versioned. See audit trails and versioning.

Traceability events

Alongside static passport fields, supply chain events live in a separate layer. GS1's EPCIS 2.0 is the de facto answer: it records what, where, when and why as events, linked from the resolver. See EPCIS 2.0.

Practical design advice

1. Keep one canonical model and generate JSON Schema and OpenAPI from it.
2. Use language-independent codes (country, material) and translate at the presentation layer. See multilingual passports.
3. Distinguish empty from "unknown". That difference matters in an audit.
4. Carry provenance: every critical field should record which document it came from.
5. Mark the access tier in the data model, not in the presentation layer. See access rights.

Frequently asked questions