Skip to main content

EPU Anticipatory Sustainability Acquisition

1. Purpose

Anticipatory Sustainability Acquisition moves product sustainability data collection from deadline-driven remediation to event-driven preparation.

The governing principle is:

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

A supplier is often most responsive during onboarding, RFQ, negotiation, product qualification or order placement. ZAYAZ should use those commercial moments to resolve likely future sustainability requirements and acquire only information that is both missing and valuable.

Reactive remediation remains necessary for new regulations, expired evidence and unexpected gaps, but it should not be the default operating model where requirements can reasonably be anticipated.

2. Two acquisition modes

2.1 Anticipatory acquisition

Triggered before a requirement is urgent.

Examples:

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

2.2 Reactive remediation

Triggered because a current requirement is unsatisfied or degraded.

Examples:

PERGAMUM_REQUIREMENT_CHANGED
DISCLOSURE_REQUIREMENT_ACTIVATED
EVIDENCE_EXPIRED
TRUST_STATE_DEGRADED
BOM_CHANGED
SUPPLIER_CHANGED
DATA_CONFLICT_DETECTED
REQUIREMENT_BECAME_MANDATORY

Anticipatory acquisition is preferred where the likely future need can be established with sufficient confidence.

3. End-to-end architecture

Commercial / product / regulatory event

Requirement Anticipation

Requirement Set

Product Data Resolution

Gap Analysis

Data Authority Resolution

Acquisition Planning

Supplier Contribution Orchestration

MICE

TrustGate

EPU Product Graph

requirement / calculation / disclosure readiness

4. Requirement sources

Requirements may originate from multiple governed sources:

  • Pergamum Pulse regulatory and standards requirements;
  • product category and technical context;
  • jurisdiction and market-placement context;
  • customer requirements;
  • internal policies;
  • disclosure/DPP profiles;
  • calculation requirements from MICE/Computation Hub;
  • evidence and assurance policies;
  • procurement qualification policies;
  • contractual sustainability clauses.

A supplier question must be traceable to one or more governed requirement sources.

A supplier question should always be generated from a governed requirement or acquisition objective, not from a generic questionnaire.

5. Pergamum Pulse role

Pergamum Pulse provides authoritative requirement context; it does not own supplier collection.

Regulatory / standards source

Pergamum requirement

applicability conditions

required information / evidence

EPU Requirement Anticipation

Pergamum should be able to answer why a requirement exists, its effective period, applicability criteria and evidence expectations.

EPU then evaluates the requirement against the specific product graph.

6. RequirementSet

A requirement determination should produce a governed set rather than immediately creating a questionnaire.

Representative contract:

RequirementSet
├── requirement_set_id
├── epu_id
├── scope_refs[]
├── trigger_event_ref
├── requirement_items[]
├── source_requirement_refs[]
├── applicability_context
├── effective_period
├── priority
├── confidence
└── provenance_ref

Each requirement item should identify required information, evidence expectations, authority expectations and satisfaction criteria.

7. Product Requirement Resolver

The Product Requirement Resolver answers:

Given this EPU and current/foreseeable context, what information is required or economically valuable to obtain now?

Inputs may include:

EPU
product category
jurisdiction
market placement
BOM / materials / substances
supplier/manufacturer roles
production context
customer requirements
procurement event
disclosure profile
Pergamum requirements
existing evidence
TrustGate state
calculation requirements

The resolver must distinguish mandatory, foreseeable, optional/value-enhancing and non-applicable requirements.

8. No Ask Before Reuse

Before generating any supplier work, ZAYAZ must attempt resolution.

Requirement item

Check current governed EPU data

Check supplier-maintained product record

Check connected source systems

Check accepted prior contribution/evidence

Check permitted interoperable/external source

Can value be safely derived?

Only unresolved delta continues to acquisition

Never request information at the point of need if sufficiently authoritative reusable information can already be resolved.

9. Requirement Gap Analyzer

The Gap Analyzer evaluates every requirement item against available product intelligence.

Recommended states:

NOT_APPLICABLE
SATISFIED
SATISFIED_ESTIMATED
SATISFIED_SECONDARY_DATA
MISSING
REQUESTED
SUBMITTED
VALIDATING
INSUFFICIENT
EXPIRED
VERIFIED
WAIVED

The state must retain the evidence/data object satisfying the requirement and the applicable quality/trust threshold.

10. Data Authority Resolver

The Data Authority Resolver determines who or what is best positioned to provide missing information.

Examples:

InformationLikely authority
Product identity / GTINBrand owner / issuing authority / product master
Component compositionComponent manufacturer
Substance identityChemical/material producer or authoritative declaration
Recycled contentMaterial producer / certified chain
Manufacturing-site activityProducing ECO/facility
Product PCFProducing organization or governed calculation process
Supplier declarationLegally/accountably responsible supplier

The commercial supplier in a PO is not automatically the authoritative source for every datum.

The resolver should use EPU graph relationships, ECO roles, source authority, contractual context and evidence requirements to identify the best source.

11. Acquisition Planner

The Acquisition Planner decides whether, when and how to acquire an unresolved requirement.

Inputs include:

  • requirement criticality;
  • commercial leverage/event stage;
  • disclosure/regulatory deadline;
  • supplier relationship;
  • data authority;
  • expected effort;
  • product/materiality/revenue context;
  • uncertainty reduction value;
  • calculation impact;
  • evidence quality gap;
  • supplier responsiveness history.

Possible actions:

REQUEST_NOW
REQUEST_WITH_RFQ
REQUEST_DURING_NEGOTIATION
ADD_TO_PURCHASE_CONDITION
REQUEST_AT_SUPPLIER_ONBOARDING
DEFER_UNTIL_TRIGGER
REQUEST_LOWER_TIER
USE_GOVERNED_ESTIMATE_TEMPORARILY
ESCALATE_FOR_REVIEW
NO_ACTION_REQUIRED

12. Request generation

Contribution requests should be dynamically instantiated from governed requirement templates.

Example chemical request:

Requirement: REACH_SVHC_DECLARATION
Scope: COMPONENT-881
Supplier: ECO-123
Reason: EU market + applicable article requirement
Already known: product, component, supplier, jurisdiction
Missing:
- relevant substance declaration
- concentration range where applicable
- evidence document

The supplier should see the minimum unresolved questions and why they are being asked.

13. Commercial leverage integration

ACF/Input Hub connectors can emit commercial events without embedding ESG logic in ERP adapters.

SAP / Business Central / NetSuite / other source

RFQ / PO / supplier / item event

ACF / Input Hub normalization

EPU product + ECO resolution

Requirement Anticipation

The source system need only communicate the business event and source identities. ZAYAZ determines sustainability implications through governed requirements and product context.

14. Regulatory change cascade

A Pergamum change can trigger portfolio-scale impact resolution:

PERGAMUM_REQUIREMENT_CHANGED

applicability query

affected EPU population

requirement gap analysis

existing data resolved

remaining missing supplier data

prioritized acquisition plans

This turns regulatory change into controlled portfolio remediation rather than uncontrolled questionnaire campaigns.

15. MICE and TrustGate boundary

MICE does not decide why a supplier should be asked a question.

After information is submitted/resolved, MICE may:

  • normalize chemical/substance information;
  • resolve units and identifiers;
  • perform threshold/compliance calculations;
  • calculate PCF/LCA impacts;
  • evaluate allocation;
  • model scenarios;
  • derive governed results.

TrustGate evaluates evidence quality, provenance, validity, consistency, verification and confidence.

The orchestration boundary is:

WHY / WHAT → requirements
DO WE HAVE IT → resolution + gap analysis
WHO → data authority
WHEN / HOW → acquisition planning
ASK → supplier contribution
WHAT DOES IT MEAN → MICE
CAN WE TRUST IT → TrustGate

16. Prioritization

A portfolio-scale acquisition priority may combine:

regulatory criticality
× deadline proximity
× commercial leverage
× product materiality
× sustainability impact
× uncertainty reduction value
× evidence quality gap
× supplier responsiveness

The exact scoring method must be governed and explainable.

17. Readiness views

Requirement states can aggregate into operational readiness, for example:

Chemical readiness: 86%
42 satisfied
3 awaiting supplier
2 expired
1 verification review

Readiness is a derived view and must remain traceable to individual requirements, evidence and policy versions.

18. Core principles

  1. Anticipate foreseeable requirements before they become urgent.
  2. Prefer commercially advantageous acquisition moments.
  3. Resolve reusable information before requesting anything.
  4. Ask only for the unresolved delta.
  5. Every question must have a governed reason.
  6. The best data authority may differ from the direct supplier.
  7. Pergamum owns requirement lineage; EPU owns product-context resolution/orchestration.
  8. MICE processes/calculates after requirements and data scope are established.
  9. TrustGate governs confidence and assurance.
  10. Reactive remediation remains available but is not the preferred mode for foreseeable needs.
GitHub RepoRequest for Change (RFC)