---
title: "Multi-Component DPPs: An E-Bike Walkthrough"
description: "How a composite product references separately-passported components via standard GS1 Digital Link and EPCIS aggregation"
canonical_url: "https://openepcis.io/docs/digital-product-passport/multi-component-example"
last_updated: "2026-07-02T20:32:00.056Z"
---

## Overview

Complex products — e-bikes, EVs, industrial equipment — are made of parts that each have their own regulatory profile. A battery falls under EU 2023/1542, an electronic motor controller under WEEE and ESPR, a leather saddle potentially under ESPR plus EUDR. Trying to cram every datum into one monolithic passport quickly turns the document into a kitchen sink no audience actually wants.

The cleaner pattern: **each component is itself an identified, resolvable product.** The composite product just *references* its components by their Digital Link URLs. Consumers, recyclers, regulators and customs officers each follow the link they care about and land on a focused passport.

> **Status of this pattern.** Component linking is an active topic in CIRPASS-2 and adjacent specs. There is no canonical OpenEPCIS property like `dpp:hasPart` yet — the worked example below uses **EPCIS Aggregation events** to express the parent ↔ child relationship, which is part of the published EPCIS 2.0 spec and works today without inventing vocabulary.

## The e-bike, by regulation

<table>
<thead>
  <tr>
    <th>
      Component
    </th>
    
    <th>
      Primary regulation
    </th>
    
    <th>
      DPP module that fits
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Frame
    </td>
    
    <td>
      ESPR 2024/1781
    </td>
    
    <td>
      DPP core
    </td>
  </tr>
  
  <tr>
    <td>
      Battery pack
    </td>
    
    <td>
      EU 2023/1542
    </td>
    
    <td>
      Battery DPP
    </td>
  </tr>
  
  <tr>
    <td>
      Motor + controller
    </td>
    
    <td>
      ESPR + WEEE
    </td>
    
    <td>
      Electronics DPP
    </td>
  </tr>
  
  <tr>
    <td>
      Leather saddle
    </td>
    
    <td>
      ESPR (+ EUDR for the leather)
    </td>
    
    <td>
      Textile + EUDR
    </td>
  </tr>
  
  <tr>
    <td>
      Tires
    </td>
    
    <td>
      Future ESPR delegated act
    </td>
    
    <td>
      DPP core
    </td>
  </tr>
</tbody>
</table>

Each row is an independently-identifiable product with its own GTIN, its own serial, its own resolver entry, and its own passport.

## Pattern: composite product references components

The composite product gets one Digital Link URL. Its passport carries a small list of component URLs — each one resolves on its own to a focused passport built from the right DPP module. Conceptually:

<diagram-image alt="An e-bike passport linking its component passports" src="/diagrams/dpp-multi-component-ebike">



</diagram-image>

The e-bike's own JSON-LD only needs the composite-level data: brand, model, dimensions, headline circularity claims, plus a list of component URLs. Each component URL is the canonical Digital Link of *that* component's passport — no embedding, no duplication.

## Expressing the composition: EPCIS AggregationEvent

EPCIS 2.0 already models "X is made of Y, Z, …" as an **AggregationEvent**: a `parentID` plus a list of `childEPCs`. This is the no-invention way to make the parent ↔ child relationship machine-readable today.

```json
{
  "@context": ["https://ref.gs1.org/standards/epcis/epcis-context.jsonld"],
  "type": "EPCISDocument",
  "schemaVersion": "2.0",
  "epcisBody": {
    "eventList": [{
      "type": "AggregationEvent",
      "eventTime": "2025-01-25T14:00:00Z",
      "eventTimeZoneOffset": "+01:00",
      "action": "ADD",
      "bizStep": "assembling",
      "disposition": "active",
      "parentID": "https://id.gs1.org/01/09521234000010/21/EBIKE-2025-001",
      "childEPCs": [
        "https://id.gs1.org/01/09521234000027/21/BAT-EBIKE-001",
        "https://id.gs1.org/01/09521234000034/21/MOTOR-001",
        "https://id.gs1.org/01/09521234000041/21/SADDLE-001",
        "https://id.gs1.org/01/09521234000058/21/FRAME-001"
      ],
      "readPoint": { "id": "https://id.gs1.org/414/9521234000010" }
    }]
  }
}
```

When the e-bike is later disassembled (a component being replaced under warranty, a recycler stripping it for materials) the inverse is the same shape with `action: "DELETE"` — the components survive the parent, they just stop being aggregated to it. The history is queryable per-serial through the EPCIS query API.

## What clients see at resolution time

- **Consumer** scans the e-bike → the resolver returns the composite passport (brand, model, recycling instructions, links to component passports). They can drill into the battery for State-of-Health, or the saddle for material composition.
- **Authorised recycler** scans the same e-bike with credentials → same composite passport, plus access-controlled fields (full BOM, hazardous-substance disclosures, disassembly sequence).
- **Customs officer** scanning the saddle directly → leather + EUDR passport, EUIS reference, plot-of-origin coordinates, due-diligence statement.
- **Battery technician** scanning the battery directly → battery passport with the latest SoH event from the EPCIS query, no need to go via the e-bike.

The same Digital Link primitives (`Accept`, `?linkType=`, access tier) that drive single-product resolution drive component-level resolution. See [DPP Resolution Flow](/docs/digital-product-passport/dpp-resolution-flow) for the end-to-end picture.

## Why this pattern is worth the effort

- **Regulatory clarity** — each component lines up to one regulator, not five.
- **Independent lifecycle** — replacing a battery just publishes a new component passport and an aggregation update; the e-bike's main passport doesn't churn.
- **Audience-appropriate payloads** — a consumer-grade UI never has to hide WEEE codes; a recycler API never has to skim past the marketing description.
- **Circular economy** — recovered components keep their full history (events, certifications, hazard data) as they're re-aggregated into a new product.

## What's left to standardise

Today there is no single agreed JSON-LD predicate to say "this composite passport references these component passports" — different specs (CIRPASS-2 bridges, Catena-X industry-core, sector-specific drafts) propose different shapes. Until that lands, the EPCIS AggregationEvent shown above is the safest published way to express the relationship, and OpenEPCIS will follow whichever CIRPASS-2 / GS1 outcome becomes the standard.

## Next steps

- [DPP Resolution Flow](/docs/digital-product-passport/dpp-resolution-flow)
- [Battery DPP](/docs/digital-product-passport/battery-dpp)
- [Electronics DPP](/docs/digital-product-passport/electronics)
- [Textile DPP](/docs/digital-product-passport/textile)
- [EUDR](/docs/digital-product-passport/eudr)