EPU Identity Change and Versioning Policy

1. Purpose

This policy defines how ZAYAZ decides whether a change to a product:

• has no EPU identity impact;
• creates a new version of the existing product definition;
• requires governed human review; or
• requires a new EPU identity.

The policy exists to prevent inconsistent identity decisions across ERP integrations, PLM imports, supplier updates, DPP workflows, lifecycle calculations and product-management interfaces.

The central rule is:

EPU identity follows the governed product definition, not the current sustainability state, data quality, supplier state, calculation result or disclosure state.

2. Decision outcomes

Every material product-change event must resolve to exactly one governed outcome.

NO_IDENTITY_IMPACT
NEW_PRODUCT_VERSION
HUMAN_REVIEW
NEW_EPU_REQUIRED

2.1 NO_IDENTITY_IMPACT

Use when the observed change does not alter the governed product definition.

Examples:

• additional evidence is received;
• a supplier declaration is renewed;
• a footprint is recalculated;
• an emission factor is updated;
• a verifier completes a review;
• a DPP disclosure is regenerated;
• a logistics route changes while the product definition remains unchanged;
• a production batch is created;
• a serialized item is manufactured.

2.2 NEW_PRODUCT_VERSION

Use when the governed product definition changes but still represents the same product identity under applicable policy.

Examples may include:

• a BOM revision that does not create a new commercial/technical identity;
• a supplier substitution that preserves the same product specification;
• an approved material substitution within tolerance;
• packaging revision where the product identity remains unchanged;
• a firmware revision that does not create a separately identified product;
• a technical-documentation update affecting current state but not product identity.

2.3 HUMAN_REVIEW

Use when automated policy cannot determine identity impact with sufficient confidence or when organizational/regulatory policy requires human approval.

Examples:

• significant formulation change with uncertain market identity consequences;
• external identifier changed without clear reason;
• multiple source systems disagree about whether two products are equivalent;
• product specification changed across several dimensions simultaneously;
• local/regulatory rules produce conflicting identity expectations.

2.4 NEW_EPU_REQUIRED

Use when the change creates a materially distinct governed product definition.

Typical triggers include:

• successor/replacement product;
• distinct trade item or SKU/variant created under applicable identification policy;
• material technical configuration change that results in a distinct product definition;
• materially different capacity, size, formulation, regulated composition or functional configuration sold/managed as a distinct product;
• an external authoritative product-identity event that clearly creates a separate product identity;
• a change that alters applicable regulatory product classification in a way that creates a distinct governed product definition.

3. Identity policy is contextual

EPU must not hard-code simplistic rules such as "new GTIN always means new EPU" or "supplier change never means new EPU".

Identity decisions may depend on:

• product category;
• jurisdiction;
• applicable identification standards;
• contractual/business rules;
• technical specification;
• regulated composition;
• commercial presentation;
• lifecycle and serviceability requirements;
• tenant policy where it does not violate canonical semantics.

The policy engine therefore evaluates a structured change event against a versioned rule profile.

4. Product Identity Change Event

Canonical event envelope:

ProductIdentityChangeEvent
├── change_event_id
├── epu_id
├── observed_at
├── effective_at
├── source_ref
├── source_system
├── prior_product_definition_version
├── proposed_product_state_ref
├── changed_dimensions[]
├── external_identifier_changes[]
├── classification_changes[]
├── composition_changes[]
├── regulatory_context_refs[]
├── evidence_refs[]
└── provenance_ref

changed_dimensions should use a governed vocabulary rather than free text.

Representative dimensions:

COMMERCIAL_IDENTITY
TECHNICAL_SPECIFICATION
DIMENSION_OR_CAPACITY
FORMULATION_OR_COMPOSITION
PACKAGING
SUPPLIER_CONFIGURATION
MANUFACTURING_LOCATION
FIRMWARE_OR_SOFTWARE
REGULATORY_CLASSIFICATION
EXTERNAL_IDENTIFIER
BRANDING
LIFECYCLE_CHARACTERISTICS
OTHER_GOVERNED_DIMENSION

5. Decision pipeline

Product change observed
        ↓
Normalize change event
        ↓
Resolve applicable identity policy profile
        ↓
Deterministic rule evaluation
        ↓
Context checks / external identifier policy
        ↓
Confidence calculation
        ↓
┌────────────────────────────────────┐
│ NO_IDENTITY_IMPACT                 │
│ NEW_PRODUCT_VERSION                │
│ HUMAN_REVIEW                       │
│ NEW_EPU_REQUIRED                   │
└────────────────────────────────────┘
        ↓
Persist immutable decision record
        ↓
Publish identity lifecycle event

AI-assisted comparison may support ambiguous cases, but authoritative decisions must be explainable and tied to governed policy/rules.

6. External identifier changes

External identifiers are evidence about identity, not identity itself.

Examples:

GTIN changed
SKU changed
ERP material number changed
PLM identifier changed
manufacturer part number changed

Each event must be evaluated in context.

Possible outcomes:

• source-system renumbering → same EPU, new alias mapping;
• commercial variant split → new EPU;
• merger/system migration → same EPU, alias migration;
• duplicate/incorrect identifier → conflict resolution;
• successor product introduction → new EPU with supersession relationship.

7. Product-definition version semantics

A product-definition version captures the effective state of the product definition without changing canonical identity.

Recommended characteristics:

• immutable once activated;
• effective-dated;
• explicit supersedes relationship;
• linked to the exact source/evidence state that caused the version;
• historical versions remain queryable;
• composition/BOM versions may change independently but must be linkable to the applicable product-definition version.

Example:

EPU-123
 ├── ProductDefinition v1  2026-01-01 → 2026-05-31
 ├── ProductDefinition v2  2026-06-01 → 2026-09-14
 └── ProductDefinition v3  2026-09-15 → current

8. EPU supersession

When a change requires a new EPU, ZAYAZ must preserve lineage between old and new identities.

EPU-A
  │
  └── superseded_by ──> EPU-B

Allowed lineage predicates should distinguish at least:

SUPERSEDED_BY
REPLACED_BY
SPLIT_INTO
MERGED_INTO
VARIANT_OF
DERIVED_FROM

The exact predicate vocabulary is governed by the Product Graph ontology.

A superseded EPU remains historically resolvable and retains all prior relationships, results, evidence and disclosures.

9. Split and merge cases

9.1 Split

One product identity may evolve into multiple distinct successor products.

EPU-A
 ├── split_into ──> EPU-B
 └── split_into ──> EPU-C

Prior history must not be copied blindly into successors. Successors reference the appropriate inherited state and provenance explicitly.

9.2 Merge

Multiple product definitions may be consolidated into one canonical successor.

EPU-A ──┐
        ├── merged_into ──> EPU-C
EPU-B ──┘

The merge must preserve source identity history and must not erase prior distinctions.

10. Supplier and manufacturer changes

Supplier/manufacturer relationships are graph relationships, not identity attributes.

A supplier or manufacturer change therefore normally creates:

• ended prior relationship edge;
• new effective-dated relationship edge;
• potentially a new product-definition/BOM version where the underlying product definition changed;
• a new EPU only if the change creates a materially distinct product identity under policy.

Example:

EPU-123
  ├── supplied_component_by ECO-A  valid_to: 2026-06-30
  └── supplied_component_by ECO-B  valid_from: 2026-07-01

11. Manufacturing-location changes

Production location is primarily production context, not identity.

A product produced at multiple sites can therefore remain the same EPU while calculations and DPP disclosures use site-specific production context.

New EPU creation is considered only where location materially creates a separately governed/commercially distinct product identity.

12. Composition and formulation changes

Composition changes require special care because they can alter regulatory classification, footprint, recyclability, hazard status and product performance.

Decision process should evaluate:

• whether the product remains within the same governed technical specification;
• whether external trade-item identity changes;
• whether regulated composition thresholds/classification change;
• whether functional performance/capacity changes;
• whether product-category-specific identity rules require separation.

A changed carbon footprint alone is never sufficient reason for a new EPU.

13. Packaging changes

Packaging should generally be modeled separately from the product identity, but packaging can affect product identity in some markets/product categories.

The default policy should therefore be:

packaging-only change
    ↓
NEW_PRODUCT_VERSION or NO_IDENTITY_IMPACT

unless applicable commercial/regulatory identity policy indicates a distinct product definition.

14. Batch, lot and serial changes

Creating a new batch, lot or serialized physical item never creates a new EPU merely because the instance is new.

EPU
 ├── Batch 001
 ├── Batch 002
 └── Serialized items ...

Instance-specific composition, evidence, provenance or footprint may differ while inheriting the same EPU identity.

15. Calculation, evidence and disclosure changes

The following must never directly change EPU identity:

• new PCF/PEF/LCA result;
• new MICE engine version;
• changed emission factor/dataset;
• new supplier evidence;
• evidence expiration;
• changed TrustGate score;
• verification result;
• disclosure/DPP publication;
• marketing claim change;
• repair/recycling instruction change.

These are state, result, evidence, assurance or disclosure changes.

16. Identity decision record

Every evaluated change event must produce an immutable decision artifact.

IdentityChangeDecision
├── decision_id
├── change_event_id
├── epu_id
├── outcome
├── new_product_definition_version_id?
├── successor_epu_id?
├── policy_profile_id
├── policy_version
├── triggered_rules[]
├── confidence
├── evidence_refs[]
├── reviewer?
├── rationale
├── decided_at
└── provenance_ref

This artifact is essential for audit, replay, support and future policy migration.

17. Conflict handling

Conflicting identity assertions must create explicit conflict state.

Examples:

• one GTIN maps to two candidate EPUs;
• ERP and PLM claim different successor identities;
• supplier and manufacturer source systems disagree on product equivalence;
• duplicate source records represent the same product under different internal IDs.

ZAYAZ must not resolve such conflicts with silent last-write-wins logic.

Conflict workflow:

conflict detected
   ↓
quarantine affected identity mapping
   ↓
collect evidence / source authority
   ↓
apply policy
   ↓
automated resolution or human review
   ↓
publish correction/supersession event

18. Point-in-time reconstruction

Identity and versioning data must support reconstruction of both:

• the product definition valid at a historical business date;
• what ZAYAZ knew/believed at a historical system date.

This is required for reproducing historical calculations, disclosures and assurance decisions.

19. Initial policy registry

A future machine-readable registry should contain at least:

policy_profile_id
product_category_scope
jurisdiction_scope
applicable_identifier_standards[]
change_dimension_rules[]
automation_thresholds
human_review_conditions
new_epu_conditions
version_only_conditions
policy_effective_from
policy_effective_to
policy_version
owner
approval_state

The MDX policy remains the conceptual contract until that registry is introduced.

20. Acceptance tests

A production implementation should pass at least these scenarios:

1. ERP renumbers a material but GTIN/specification remain unchanged → same EPU, new alias history.
2. Supplier is replaced with equivalent approved material → same EPU; relationship/BOM version changes.
3. Product capacity changes from 5 Ah to 8 Ah and is sold as a distinct variant → new EPU.
4. PCF changes because supplier-specific primary data replaces an estimate → same EPU.
5. Existing model is discontinued and a successor product launched → new EPU linked with SUPERSEDED_BY/REPLACED_BY semantics.
6. Two source systems disagree whether a new formulation is equivalent → HUMAN_REVIEW.
7. New production batch at another plant → same EPU, new production context/instance.
8. Product is split into two commercially distinct variants → two successor EPUs with preserved lineage.

The implementation is not production-grade until each outcome is explainable, replayable and auditable.