EPU Identity and Product Instance Model

1. Core identity decision

EPU should normally represent the governed commercially and technically distinct product definition closest to the variant, SKU or trade-item level.

Family, model, variant, batch and serialized unit are not automatically equivalent identity classes.

Product Family
     │
     ▼
Product Definition / Model
     │
     ▼
Product Variant / Trade Item  <── EPU by default
     │
     ├── Production Run
     │      └── Batch / Lot
     │
     └── Serialized Physical Item

2. Product family

A product family groups related products and supports portfolio analysis, inheritance and navigation. A family is not an EPU by default because it may aggregate multiple commercially or technically distinct products.

3. Product definition / model

A model can represent a stable technical design above individual variants. Depending on the product domain, a model may be separately governed, but it should not automatically receive EPU semantics when the actual sustainability object is the variant or trade item.

4. Product variant / trade item

This is the default EPU level.

An EPU should represent a distinct product definition whose composition, technical specification, regulatory treatment or commercial identity is sufficiently stable to act as the anchor for product sustainability intelligence.

5. Production instances

Production runs, batches and lots are manifestations of an EPU, not new EPUs by default.

They can carry actual production facts such as:

• production date and time;
• manufacturing location;
• applicable BOM and recipe versions;
• actual supplier/material batches;
• measured energy and process activity;
• quality records;
• lot-specific recycled content;
• lot-specific evidence;
• batch-specific footprint results where required.

6. Serialized physical items

A serialized item is a physical instance derived from an EPU, optionally through a batch or lot.

EPU
 ↓
Batch / Lot
 ↓
Serialized Physical Item

Serialized instances should be lightweight so ZAYAZ can support very high volumes without duplicating the full product dossier for every physical item.

Item-level events can include repair, refurbishment, component replacement, transfer, reuse and end-of-life events.

7. Identity versus versioning

A new calculation, evidence item or sustainability result does not create a new EPU.

Likely same-EPU changes include:

• new PCF or PEF result;
• new emission factor or dataset;
• improved supplier evidence;
• new verifier;
• new certificate;
• new production batch;
• new DPP disclosure version;
• revised end-of-life guidance.

Changes that can affect product identity include:

• a new trade item representing a materially distinct product;
• material technical specification changes;
• regulated composition changes;
• new size/capacity/configuration sold as a distinct product;
• successor/replacement products;
• changes that trigger a new external trade-item identity under applicable identification rules.

Supplier changes, factory changes, packaging changes, colour changes, firmware revisions, BOM revisions, recipe changes and recycled-content changes require governed identity policy rather than universal hard-coded rules.

8. Product Identity Change Event

ZAYAZ should eventually evaluate significant changes through a governed Product Identity Change Event.

Product change
     ↓
Product Identity Change Event
     ↓
Identity Policy Resolver
     │
     ├── no identity impact
     ├── state/version change
     ├── manual review
     └── new EPU required

The decision must retain policy version, evidence, decision rationale and provenance.

9. External aliases

EPU is a canonical ZAYAZ identity and must not replace established external identifiers.

EPU
 ├── GTIN
 ├── SKU
 ├── manufacturer part number
 ├── ERP material/item ID
 ├── PLM ID
 ├── PIM ID
 ├── supplier product ID
 ├── customer product ID
 ├── DPP/external identifier
 └── other aliases

Alias records should support source system, owning/issuing party, validity period, authority, provenance and resolution status.

Classification codes such as CN, HS or product taxonomy codes are classifications, not identity aliases unless a specific external system uses them as identifiers.

10. Source Product Identity Resolution

An ERP, PLM or PIM product record is a source product identity candidate. It does not automatically become an EPU.

Source Product Candidate
        ↓
identifier normalization
        ↓
alias matching
        ↓
product characteristic comparison
        ↓
relationship/context checks
        ↓
resolution confidence
        ↓
┌────────────────────────────┐
│ resolve to existing EPU    │
│ candidate match / review   │
│ ambiguous / human review   │
│ create new EPU             │
└────────────────────────────┘

The Product Identity Resolver should automate high-confidence cases and preserve the evidence behind every resolution decision.