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:
| Information | Likely authority |
|---|---|
| Product identity / GTIN | Brand owner / issuing authority / product master |
| Component composition | Component manufacturer |
| Substance identity | Chemical/material producer or authoritative declaration |
| Recycled content | Material producer / certified chain |
| Manufacturing-site activity | Producing ECO/facility |
| Product PCF | Producing organization or governed calculation process |
| Supplier declaration | Legally/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
- Anticipate foreseeable requirements before they become urgent.
- Prefer commercially advantageous acquisition moments.
- Resolve reusable information before requesting anything.
- Ask only for the unresolved delta.
- Every question must have a governed reason.
- The best data authority may differ from the direct supplier.
- Pergamum owns requirement lineage; EPU owns product-context resolution/orchestration.
- MICE processes/calculates after requirements and data scope are established.
- TrustGate governs confidence and assurance.
- Reactive remediation remains available but is not the preferred mode for foreseeable needs.