EPU Supplier Contribution Architecture

1. Purpose

EPU should make product sustainability data acquisition easier by resolving reusable information first and requesting only missing information from the party best positioned to provide it.

Supplier Contributions are therefore not synonymous with questionnaires. They are governed acquisition objects used when authoritative product information cannot already be resolved with sufficient validity, authority and quality.

Suppliers do not receive unrestricted access to the EPU dossier. They receive governed rights to contribute to specific product, BOM, material, evidence, calculation or disclosure requirements.

The preferred operating sequence is:

Resolve → anticipate → acquire the delta → validate → reuse.

2. Relationship to supplier product-data onboarding

Where possible, a supplier/manufacturer should first establish a reusable product-data relationship by connecting ERP, PLM, PIM, API or other authoritative infrastructure, or by manually registering product information where integration is unavailable.

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

A contribution request should not duplicate information already available through that governed relationship.

3. Contribution scope

Manufacturer ECO
      │
      ▼
Product EPU
      │
      ├── BOM node A ── contribution scope ──> Supplier ECO A
      ├── BOM node B ── contribution scope ──> Supplier ECO B
      └── BOM node C ── contribution scope ──> Supplier ECO C

A contribution request can specify:

• the EPU and relevant product/BOM node;
• contributor ECO identity;
• governed requirement/acquisition objective;
• requested unresolved data fields;
• required evidence types;
• applicable reporting/disclosure/calculation requirement;
• validity period;
• acquisition trigger and commercial context where permitted;
• due date;
• confidentiality and onward-disclosure policy;
• read/write/discovery permissions;
• verification requirements;
• status and completeness;
• provenance.

4. Multi-tier propagation

The architecture should support controlled cascading through supply tiers.

Manufacturer
     │
     ▼
Tier 1 Supplier
     │
     ├──> Tier 2 Supplier A
     └──> Tier 2 Supplier B
              │
              └──> Tier n

The manufacturer does not necessarily need unrestricted visibility of every commercially sensitive lower-tier relationship, and lower-tier suppliers do not need visibility of the manufacturer's full BOM or other suppliers.

Contribution permissions therefore require both data access policy and graph-discovery policy.

5. Data authority

Supplier-provided values must remain distinguishable from manufacturer-provided, source-system, normalized, classified, estimated and derived values.

A supplier contribution should preserve:

source party
source system / submission channel
original value
normalized value
unit
applicable product/component/material
period / validity
methodology where applicable
evidence
verification state
confidence / quality state
provenance

Higher-quality primary data can supersede the use of lower-quality estimates in later calculations without deleting historical calculations.

The direct commercial supplier is not automatically the authoritative party for every datum. Data Authority Resolution may identify a manufacturer, material producer, chemical producer, facility, verifier or lower-tier supplier as the correct source.

6. Resolution before request

Before creating a contribution request, ZAYAZ should evaluate:

requirement / acquisition objective
        ↓
current governed EPU data
        ↓
supplier-maintained product record
        ↓
connected ERP / PLM / PIM / API
        ↓
valid prior contribution / evidence
        ↓
permitted interoperable source
        ↓
derivable governed value
        ↓
unresolved delta only

This is the No Ask Before Reuse rule.

7. Anticipatory acquisition

Supplier contributions can be triggered before a requirement becomes urgent.

Commercial/product triggers may include:

SUPPLIER_ONBOARDING_STARTED
RFQ_CREATED
SOURCING_EVENT_STARTED
CONTRACT_NEGOTIATION_STARTED
SUPPLIER_SELECTED
PURCHASE_REQUISITION_CREATED
PURCHASE_ORDER_DRAFTED
BOM_RELEASED
NEW_PRODUCT_INTRODUCED
CONTRACT_RENEWAL_STARTED

Requirement/risk triggers may include:

PERGAMUM_REQUIREMENT_CHANGED
EVIDENCE_EXPIRED
TRUST_STATE_DEGRADED
BOM_CHANGED
SUPPLIER_CHANGED
DISCLOSURE_REQUIREMENT_ACTIVATED

Acquire at the point of leverage; resolve at the point of need.

8. Requirement-driven question generation

A contribution request should be generated from a governed requirement or acquisition objective rather than a generic static questionnaire.

Requirement
    ↓
Product scope
    ↓
Gap Analyzer
    ↓
Data Authority Resolver
    ↓
Contribution template
    ↓
minimum unresolved questions

Known context such as product, component, supplier, jurisdiction and existing fields should not be asked again.

Conditional questions should branch only where necessary.

9. Example

For a battery assembly, a requirement may need:

• cell chemistry;
• component mass;
• cobalt or other relevant material content;
• recycled content;
• material origin;
• production location;
• supplier-specific PCF data;
• substance declarations;
• certificates and supporting evidence.

If seven of nine items are already valid and sufficiently authoritative, the supplier should be asked only for the remaining two.

The supplier should also be told why the information is requested and the relevant product/component scope.

10. Trust and assurance

Contribution data should integrate with TrustGate and the wider ZAYAZ evidence model.

A contribution can move through states such as:

requested
  ↓
submitted
  ↓
validated
  ↓
evidence-linked
  ↓
verified / accepted / rejected
  ↓
used in calculation or disclosure

Every use of supplier data in a calculation, procurement decision or disclosure should remain traceable to the exact contribution and evidence version used.

11. Change propagation

When accepted supplier information changes, dependent product intelligence should be evaluated rather than blindly overwritten.

Potential effects include:

refresh requirement satisfaction
re-run affected MICE calculations
re-evaluate PCF comparability
refresh procurement decision scenarios
re-evaluate TrustGate
refresh disclosure readiness
notify affected product owners

Historical calculations and decisions retain their original contribution/evidence references.

12. Supplier experience principle

Suppliers should never be forced to fill out a broad “ZAYAZ questionnaire” when ZAYAZ can identify a smaller governed information delta.

The supplier experience should answer:

What do you need?
For which product/component?
Why do you need it?
Do you already know part of it?
What evidence is required?
Who will be allowed to see it?
When does it need renewal?

This turns supplier contribution from repetitive ESG administration into a reusable product-data relationship.