EU Implementers: Pass DPP Checks with JSON-LD Product Passport Schema

A product passport schema is a machine-readable JSON-LD data model that links a unique product identifier to verifiable product data and registry pointers required under EU Digital Product Passport rules. It draws its vocabulary from published standards, chiefly the UN Transparency Protocol and GS1 Digital Link, so any system in the supply chain can read the same fields the same way. Getting this structure right, not just the paperwork behind it, is what actually satisfies ESPR readiness.

TL;DR:

• Register at the product, batch, or item level using standardized identifiers like GTIN and GS1 Digital Link to ensure resolution and traceability across systems.
• Build JSON-LD context files that map internal data fields to open semantic vocabularies before collecting supplier data to facilitate interoperability.
• Use durable physical carriers such as QR codes, Data Matrix, or NFC tags tested under real wear conditions to maintain link integrity over the product lifespan.
• Separate identity data from evidentiary proof, linking claims to verifiable credentials and timestamped, immutable product records to pass audits.
• Validate data against authoritative semantic models and test sample payloads before submission to avoid rejection and keep pointers resolvable within the registry infrastructure.

• Where a Product Passport Schema Fits in DPP Architecture
• Which Standards and Formats Should You Actually Use?
• How Does the EU DPP Registry and Semantic Repository Work?
• What Identifier and Data Carrier Strategy Should You Use?
• How Do You Design a Schema for Semantic Interoperability?
• How Does This Look in a Real Implementation?
• Implementation Checklist: From Planning to a Testable Passport
• What Actually Determines Whether a Passport Schema Works
• Get Your Product Data Registry Ready With DDP Grid
• Sources
• FAQ

A schema and a registry solve different problems. The registry holds an identifier, a registration record, and a pointer to where the full data lives. The passport itself, the actual schema, holds the substance: materials, manufacturing locations, safety data, and evidence documents.

Think of the registry as a phone directory and the passport as the actual phone call. Regulators query the registry to confirm a product is registered and to find where its data lives; they read the passport to see what the product is actually made of. This split matters because it keeps sensitive commercial detail out of a centralized government database while still making it discoverable.

Schemas do the heavy lifting of turning fragmented supplier data into something a machine can parse consistently across borders. That only works if everyone draws terms from the same shared vocabulary rather than inventing their own field names. A few things a well-built schema needs to do:

• Bind every field to a term defined in a public vocabulary, not a private naming convention
• Point back to a resolvable identifier so any scanner or API can locate the record
• Separate identity data (what the product is) from evidentiary data (proof of claims)
• Stay legible to both a compliance auditor and a warehouse system pulling batch data

Without that shared semantic layer, you end up with ten suppliers describing "recycled content" ten different ways, and no auditor can reconcile any of it.

Four names come up constantly once you start building: JSON-LD, UNTP, GS1, and the CEN-CENELEC EN standards. Each plays a distinct role, and skipping one usually creates a gap the others can't cover.

JSON-LD is the format CEN-CENELEC JTC 24 recommends for DPP exchange, because it lets you attach a @context file that maps your internal field names to publicly defined terms without renaming anything in your own database. That context file is doing the real interoperability work, not the JSON syntax itself.

The UN Transparency Protocol (UNTP) publishes a JSON schema, a Core Vocabulary, and sample credential instances covering products, facilities, parties, and attestations. It's the closest thing to a ready-made starting template available today, and it's built to be lightweight rather than exhaustive.

GS1 Digital Link, paired with a GTIN, provides the resolution model connecting a physical barcode to a digital record. This is the identifier layer the ESPR technical standards registry treats as the practical default.

The EN 18216 through EN 18246 family, published under Commission Implementing Decision (EU) 2026/1736, covers data exchange protocols, carriers, storage, and APIs at a system level.

Pro Tip: Full presumption of conformity under ESPR depends on formal citation of these EN standards in the Official Journal. Track publication status directly rather than assuming a standard is enforceable the moment it's drafted.

The registry and the semantic repository are two separate systems doing two separate jobs, and confusing them is one of the most common early mistakes.

The registry stores identifiers, registration metadata, and a pointer to where your full passport record lives. It does not store your bill of materials, your supplier contracts, or your full compliance dossier. According to the regulation's own text, the registry returns a location, not a payload.

The semantic repository is the reference library. It publishes the authoritative data models, term definitions, and multilingual labels your schema is supposed to draw from, all accessible through APIs so your system can validate against them programmatically rather than by manual lookup.

Three things this structure demands from your implementation:

• Register at the granularity your product's delegated act actually specifies, whether that's model, batch, or item level
• Query the semantic repository's APIs rather than hardcoding your own copy of term definitions, which will drift out of date
• Expect automated semantic conformity checks at submission time, meaning malformed or unmapped fields get rejected before they ever reach a human reviewer

The EU's registry infrastructure went live in July 2026, but that date marks infrastructure readiness, not your product's legal deadline, which still depends on your sector's delegated act.

Your identifier strategy has to work at three levels simultaneously: the model, the batch, and, increasingly, the individual item. A GTIN identifies the model. A batch or serialized extension of the GS1 Digital Link URI identifies the specific run or unit, and each level needs to resolve cleanly to its own passport record without orphaning the level above it.

The resolution pattern itself is straightforward once set up: a GS1 Digital Link URI encoded into a carrier resolves through a resolver service to the passport URI, which then serves the JSON-LD payload. GTIN remains the common identifier GS1 Digital Link builds on across nearly every implementation currently in production.

For the physical carrier, you're choosing among a few standardized options:

• QR codes under ISO/IEC 18004, cheap to print, widely scannable, but vulnerable to wear on garments and packaging that gets handled roughly
• Data Matrix codes, denser and more durable in small print areas, common on hard goods and electronics
• NFC tags, more expensive per unit but readable without a clear line of sight and resistant to surface damage

Pro Tip: Test your chosen carrier under the product's real-world wear conditions before committing at scale. A QR code that survives a warehouse shelf often fails after eighteen months on a jacket cuff that goes through a washing machine weekly.

Most schema failures aren't caused by bad JSON. They're caused by good JSON that nobody else can interpret, because the field names only make sense inside the company that wrote them.

The fix is a two-layer architecture. The horizontal layer handles identifiers, carriers, and APIs, the plumbing that's identical whether you sell furniture or batteries. The sector layer handles the specific disclosure fields your product category actually requires. CEN-CENELEC JTC 24 stresses keeping these separate precisely because blending them is how implementations become impossible to update when a new delegated act lands.

Six practices separate a schema that survives an audit from one that doesn't:

1. Publish a JSON-LD context file mapping your internal field names to the semantic repository's official URIs, rather than renaming your database columns to match the standard.
2. Model your bill of materials down to part-to-substance level early, even if current delegated acts don't require that granularity yet, since retrofitting it later is far more expensive.
3. Treat every published passport state as immutable and timestamped. Corrections become new versions, not silent overwrites.
4. Link claims that need proof, such as recycled content percentage, to verifiable credentials rather than embedding an unverifiable text field.
5. Run schema validation against the semantic repository's published models before submission, not after rejection.
6. Test with real sample payloads, including edge cases like multi-material products or components sourced from more than one supplier.

Pro Tip: Build your JSON-LD context file before you touch a single supplier spreadsheet. Retrofitting semantic mapping onto data you've already collected in inconsistent formats takes roughly triple the time of doing it upfront.

The UNTP's Core Vocabulary treats Product, Facility, Party, and Attestation as linked entities rather than one flat record, and following that pattern is what turns a single passport into part of a genuine transparency graph auditors can trace across the supply chain.

A practical implementation starts with data ingestion, not schema theory. Brands typically import an existing product catalog from Shopify, a CSV export, or an API feed, and the system maps those fields against a standard vocabulary automatically rather than asking a compliance team to retype everything by hand.

From there, AI-assisted extraction can pull structured data out of supplier PDFs, test reports, and material certificates, flagging likely fields for a human reviewer rather than publishing anything automatically. That distinction matters for audit purposes: a suggested value and an approved value are not the same thing, and a defensible passport record needs to show which is which.

Once data clears human review, the record needs a permanent home: a stable URL, a QR code tied to the GS1 Digital Link pattern, and a connection to the registry API so the pointer stays current if the record moves. This is roughly the shape DDP Grid's platform follows for brands moving from spreadsheets to registry-ready records, covering import, supplier evidence collection, and publishing in one workflow.

Six steps take a team from a blank spreadsheet to a schema that will actually pass validation:

1. Map your product categories against your sector's delegated-act timeline so you know your real deadline, not a general assumption.
2. Standardize on GTIN plus GS1 Digital Link as your identifier and resolution model before building anything else.
3. Build JSON-LD context files that map your internal fields to the semantic repository's vocabulary.
4. Collect supplier evidence and link supporting documents and attestations to each claim that needs proof.
5. Set up permanent hosting for passport records with registry API integration so pointers stay resolvable.
6. Run validation tests against sample payloads and complete a test registration before your live submission.

DDP Grid's readiness guide walks through each of these steps in more detail for teams still scoping their first passport.

Most teams over-invest in theoretical completeness and under-invest in getting identifiers and vocabulary mapping right on the first pass. That ordering is backward. A passport with a clean identifier strategy and proper JSON-LD context mapping can absorb new delegated-act fields later; a passport built on ad hoc field names cannot be fixed without a rebuild.

The second mistake is trying to stuff full bills of materials into the registry itself. That's not what it's for, and it invites exactly the kind of rejected submission that stalls a launch. Use pointers, host the detail yourself, and design every record as immutable and timestamped so an auditor can trust what they're looking at.

— Vytautas

Building a compliant schema from scratch means wiring together JSON-LD contexts, supplier evidence workflows, and registry-ready hosting before you publish a single passport. DDP Grid does that groundwork for you: import your catalog from Shopify, CSV, or API, map fields against standard vocabularies automatically, and let AI pull data from supplier documents while a human reviewer signs off before anything goes live.

The platform is built for independent fashion brands, Shopify merchants, manufacturers, and importers who need granular passports at model, batch, or item level, not a generic compliance form. Every published record gets a permanent URL and a QR code built on the GS1 Digital Link pattern, ready to connect to registry APIs as they come online. If you're mapping supplier data by hand right now, a tool like the BabyLoveGrowth JSON-LD schema generator can help with the context file itself, but the evidence review and hosting still need a dedicated workflow.

Plans start at the Starter tier and scale up through Growth, Scale, and Monster AI depending on how many product models and team members you need. Check current pricing and start a trial to see how your existing catalog maps into a registry-ready schema.

• Digital Product Passport - European Commission
• Digital Product Passport | UN Transparency Protocol - UNECE
• Commission Implementing Decision (EU) 2026/1736
• Digital Product Passport, the cornerstone for the implementation of sustainability and circularity on the European Single Market - CEN-CENELEC

The registry stores identifiers and pointers to your data; the schema is the actual structured data model containing product details, materials, and evidence that the registry points to.

JSON-LD isn't legally mandated by name, but CEN-CENELEC JTC 24 recommends it as the exchange format best suited to the semantic interoperability ESPR requires.

QR codes follow ISO/IEC 18004, while carrier and system-level requirements more broadly fall under the EN 18216 to EN 18246 standard family.

Delegated acts set staggered deadlines: iron and steel from 2026, textiles, tyres, and aluminum from 2027, and furniture, mattresses, and ICT products from 2029.

No. DDP Grid provides product-data infrastructure, evidence management, and publishing tools to help you organize and demonstrate information; it doesn't issue legal certification or guarantee compliance.

• How to Implement a Digital Product Passport in 2026