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

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:

flowchart TD
    EBIKE["E-bike passport<br/>id.gs1.org/01/&lt;ebike-gtin&gt;/21/&lt;serial&gt;"]
    EBIKE --> BAT["Battery passport<br/>(EU 2023/1542)"]
    EBIKE --> MOT["Motor + controller passport<br/>(ESPR + WEEE)"]
    EBIKE --> SAD["Leather saddle passport<br/>(Textile + EUDR)"]
    EBIKE --> FRA["Frame passport<br/>(DPP core)"]

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.

{
  "@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 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
• Battery DPP
• Electronics DPP
• Textile DPP
• EUDR