EPU Supplier Product Data Onboarding

1. Purpose

Supplier Product Data Onboarding establishes a reusable product-data relationship between a supplier/manufacturer and ZAYAZ before repeated customer questionnaires become necessary.

The preferred model is:

Connect or register once. Maintain at source. Resolve many times.

Suppliers should be encouraged during onboarding to connect authoritative product-data infrastructure such as ERP, PLM, PIM, APIs, GS1-compatible product services, existing DPP infrastructure or governed file feeds. Manual registration remains available where integration is not practical.

The objective is not to copy every supplier database into ZAYAZ. It is to create governed identity resolution, synchronization, authority, provenance and access relationships so permitted product information can be reused automatically.

2. Supplier value proposition

Supplier onboarding should explicitly communicate operational value:

• answer equivalent customer sustainability requests once rather than repeatedly;
• maintain product information at the authoritative source;
• reduce email, spreadsheet and portal duplication;
• expose permitted information to qualified customers in seconds rather than weeks;
• receive alerts when evidence or declarations need renewal;
• improve DPP, chemical, PCF and customer-data readiness;
• make verified sustainability performance easier for customers to evaluate;
• retain control over confidential product and supply-chain information.

ZAYAZ should measure supplier-side benefit where possible, including requests fulfilled automatically, questionnaires avoided, product readiness and evidence approaching expiry.

3. Onboarding modes

Preferred order:

1. API / system integration
2. Managed data feed / interoperable exchange
3. Existing DPP / GS1 / machine-readable product source
4. Structured file import
5. Assisted manual product registration

Manual registration is a supported capability, not the desired long-term integration pattern for suppliers with mature product infrastructure.

4. Integration-first onboarding flow

Supplier ECO
    ↓
Discover product-data systems
    ↓
Connect ERP / PLM / PIM / API / other source
    ↓
Ingest source product candidates
    ↓
Product Identity Resolver
    ↓
Existing EPU / new EPU / ambiguity review
    ↓
Establish source authority and synchronization policy
    ↓
Map product information and evidence
    ↓
TrustGate / validation
    ↓
Reusable EPU Product Graph

A supplier should not be required to manually recreate product data that can be governed from an authoritative source integration.

5. Manual registration flow

For suppliers without suitable infrastructure:

Supplier ECO
    ↓
Create / identify product
    ↓
Resolve identifiers
    ↓
Create or match EPU
    ↓
Guided product-data registration
    ↓
Upload / link evidence
    ↓
Validate + TrustGate
    ↓
Maintain through lightweight portal

The portal should progressively request only information relevant to the product category, likely customer requirements and known data gaps.

6. Source authority model

Every synchronized field or object should retain its authority context.

Representative authority classes:

AUTHORITATIVE_SOURCE_SYSTEM
SUPPLIER_ASSERTED
MANUFACTURER_ASSERTED
THIRD_PARTY_VERIFIED
NORMALIZED_DERIVED
MODELED_ESTIMATE
EXTERNAL_REFERENCE

A normalized value must retain a link to the original source value and transformation lineage.

7. Synchronization policy

Connections should support:

• source system and record identity;
• synchronization direction;
• change-detection strategy;
• effective dates;
• freshness expectations;
• conflict handling;
• source precedence;
• evidence expiry;
• deletion/retirement semantics;
• historical snapshot retention;
• tenant and access policy.

Source deletion must not silently remove historical facts that were used in calculations, disclosures or assurance decisions.

8. Product identity resolution

Every source product is a candidate until resolved.

ERP item / PLM object / PIM product
        ↓
normalize aliases and characteristics
        ↓
match GTIN / SKU / MPN / system identifiers
        ↓
resolve product definition
        ↓
EPU

High-confidence resolution should be automatic. Ambiguity should be routed once for governed review and the resulting mapping reused thereafter.

9. Product data packages

Supplier onboarding should support reusable product-information packages, for example:

IDENTITY_PROFILE
TECHNICAL_SPECIFICATION_PROFILE
COMPOSITION_PROFILE
CHEMICAL_DECLARATION_PROFILE
PCF_PROFILE
RECYCLED_CONTENT_PROFILE
PACKAGING_PROFILE
CIRCULARITY_PROFILE
REPAIR_PROFILE
LOGISTICS_ORIGIN_PROFILE
EVIDENCE_PROFILE
DPP_READINESS_PROFILE

These profiles are governed information contracts, not static questionnaires.

A buyer or requirement resolver can request one or more profiles; ZAYAZ resolves already-available information before generating any new request.

10. Access and disclosure controls

Suppliers must retain explicit control over reusable product data.

Possible visibility scopes include:

PUBLIC
CUSTOMER
QUALIFIED_CUSTOMER
CONTRACTED_CUSTOMER
VERIFIER
REGULATOR
INTERNAL_ONLY

Access to data values and permission to discover graph topology are separate concerns.

A supplier may expose a verified product PCF without exposing confidential formulation or sub-tier supplier identities.

11. Freshness and maintenance

Register-once does not mean static-forever.

Every reusable product-data object should support:

• effective period;
• source freshness timestamp;
• evidence validity period;
• supersession/versioning;
• renewal reminders;
• impact propagation when authoritative data changes.

Example:

Evidence approaching expiry
    ↓
Supplier maintenance notification
    ↓
updated declaration received
    ↓
TrustGate
    ↓
dependent requirement states refreshed
    ↓
affected disclosures/calculations re-evaluated where necessary

12. Reuse before request

Supplier onboarding is the foundation of the EPU No Ask Before Reuse principle.

Before asking a supplier for data, ZAYAZ should check:

EPU Product Graph
supplier-maintained product record
connected ERP / PLM / PIM
valid prior supplier contributions
accepted evidence
permitted federated/external product source
derivable governed values

Only the unresolved delta should become a new contribution request.

13. Machine-to-machine resolution

The mature target is permissioned machine-readable resolution:

Customer need
    ↓
product identifier
    ↓
EPU resolution
    ↓
requested information profile
    ↓
access policy
    ↓
current authoritative data + evidence + trust state
    ↓
response in milliseconds

Humans are reserved for absent information, new evidence origination, permission decisions, conflicts, ambiguity and governed approval.

14. Supplier onboarding metrics

Useful operational measures include:

• products resolved to EPU;
• products synchronized automatically;
• manual products maintained;
• information-profile completeness;
• requests fulfilled without supplier action;
• duplicate questionnaire requests avoided;
• evidence expiry risk;
• average resolution latency;
• unresolved identity conflicts;
• percentage of data with primary/authoritative provenance;
• TrustGate distribution.

15. Architectural principles

1. Prefer connection to authoritative infrastructure over duplicate manual entry.
2. Manual registration remains available for suppliers of every maturity level.
3. Product identity resolution precedes product-data reuse.
4. Supplier data remains provenance-bearing and authority-scoped.
5. Access to reusable data is governed explicitly.
6. Historical data used in decisions is never silently deleted by synchronization.
7. Reuse is attempted before any new request.
8. Only unresolved deltas should create supplier work.
9. Supplier onboarding should create operational and commercial value for the supplier, not merely compliance burden.
10. White-label presentation may vary; canonical EPU semantics and source governance must not fork.