EPU Commercial Acquisition and Procurement Service Extension

1. Purpose

This document extends the EPU Canonical Object and Service Model with implementation contracts required for three first-class EPU capabilities:

1. Supplier Product Data Onboarding;
2. Anticipatory Sustainability Acquisition;
3. Procurement Sustainability Intelligence.

It does not change the core rule that EPU is a thin product identity. Commercial events, requirements, supplier contributions, prices, internal carbon policies and procurement calculations remain separate governed objects/services connected through EPU context.

2. Module responsibility boundary

Responsibility	Primary authority
Product identity, graph context, requirement/product orchestration	SIS / EPU
Source-system and procurement-event ingestion	Input Hub / ACF connectors
Regulatory/standards requirement lineage	Pergamum Pulse
Supplier product-data source ingestion	Input Hub + EPU resolution
PCF, normalization, financial-impact and scenario calculations	Computation Hub / MICE
Evidence quality and assurance	TrustGate / verifier services
Decision/report presentation	Reports & Insights / consuming UX

No ERP connector should contain hard-coded ESG requirement logic, and EPU must not duplicate MICE calculations or Pergamum regulatory authority.

3. Additional canonical object contracts

3.1 SupplierProductDataConnection

SupplierProductDataConnection
├── connection_id
├── supplier_eco_id
├── source_system_type
├── source_system_ref
├── connection_mode
├── authority_profile_ref
├── synchronization_policy_ref
├── access_policy_ref
├── status
├── last_successful_sync
└── provenance_ref

Represents the governed relationship to supplier product infrastructure, not credentials or connector secrets.

3.2 ProductInformationProfile

ProductInformationProfile
├── profile_id
├── profile_type
├── schema_version
├── required_fields[]
├── optional_fields[]
├── evidence_expectations[]
├── authority_expectations[]
├── validity_rules[]
└── policy_ref

Profiles support reusable machine-readable requests such as chemical declaration, PCF, recycled content or DPP-readiness information.

3.3 RequirementSet

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

3.4 RequirementSatisfaction

RequirementSatisfaction
├── satisfaction_id
├── requirement_item_ref
├── epu_id
├── scope_ref
├── state
├── satisfying_data_refs[]
├── evidence_refs[]
├── trust_state
├── evaluated_at
├── valid_until?
└── provenance_ref

States should include NOT_APPLICABLE, SATISFIED, SATISFIED_ESTIMATED, SATISFIED_SECONDARY_DATA, MISSING, REQUESTED, SUBMITTED, VALIDATING, INSUFFICIENT, EXPIRED, VERIFIED and WAIVED.

3.5 DataAuthorityDecision

DataAuthorityDecision
├── decision_id
├── requirement_item_ref
├── scope_ref
├── candidate_authorities[]
├── selected_authority_ref
├── authority_role
├── confidence
├── policy_version
├── rationale
└── provenance_ref

3.6 AcquisitionPlan

AcquisitionPlan
├── acquisition_plan_id
├── requirement_set_id
├── unresolved_requirement_refs[]
├── trigger_event_ref
├── commercial_context_ref?
├── selected_action
├── target_authority_refs[]
├── requested_information_profiles[]
├── priority
├── due_context
├── policy_version
└── provenance_ref

3.7 ComparabilityAssessment

ComparabilityAssessment
├── assessment_id
├── candidate_result_refs[]
├── product_scope_refs[]
├── functional_unit_profile
├── boundary_profile
├── method_profile
├── normalization_actions[]
├── comparability_outcome
├── limitations[]
├── uncertainty_notes[]
├── policy_version
├── generated_at
└── provenance_ref

3.8 InternalCarbonPricePolicyRef

EPU may reference, but should not own, a governed financial-impact policy:

InternalCarbonPricePolicyRef
├── policy_ref_id
├── organization_eco_id
├── external_policy_artifact_id
├── effective_period
├── scenario_class
└── provenance_ref

The authoritative policy belongs in the appropriate financial-impact/governance domain.

3.9 ProcurementDecisionRef

ProcurementDecisionRef
├── decision_ref_id
├── candidate_epu_refs[]
├── supplier_eco_refs[]
├── commercial_context_ref
├── comparability_assessment_ref
├── calculation_result_refs[]
├── internal_policy_refs[]
├── trust_context_refs[]
├── decision_time
└── provenance_ref

This references a decision artifact; it does not turn commercial price into an EPU identity property.

4. Additional services

4.1 Supplier Product Data Connection Service

Responsibilities:

• establish supplier product-data source relationships;
• manage synchronization policy and source authority metadata;
• coordinate Input Hub adapters;
• monitor freshness and source availability;
• emit product/source change observations;
• preserve source snapshots required for audit.

4.2 Product Information Profile Registry

Responsibilities:

• govern reusable information profiles;
• version profile schemas;
• express evidence and authority expectations;
• support machine-to-machine requests;
• avoid proliferation of customer-specific static questionnaires.

4.3 Product Requirement Resolver

Responsibilities:

• consume Pergamum, customer, internal, disclosure, calculation and procurement requirements;
• evaluate applicability against EPU/product context;
• produce versioned RequirementSet artifacts;
• distinguish mandatory, foreseeable and value-enhancing requirements;
• explain why each requirement applies.

4.4 Requirement Gap Analyzer

Responsibilities:

• evaluate requirement satisfaction against current governed data;
• enforce No Ask Before Reuse;
• recognize primary, secondary, estimated and expired satisfaction states;
• identify the exact unresolved delta;
• re-evaluate when product data, evidence or requirement policy changes.

4.5 Data Authority Resolver

Responsibilities:

• identify the best party/system to provide each missing datum;
• distinguish commercial supplier from manufacturer/data authority;
• traverse ECO/EPU/component/material relationships;
• use authority, evidence and contractual policy;
• route ambiguous authority decisions for review.

4.6 Acquisition Planner

Responsibilities:

• choose when/how unresolved data should be acquired;
• exploit commercial leverage events where appropriate;
• prioritize requests using requirement criticality, deadlines, materiality, uncertainty reduction and supplier responsiveness;
• choose supplier onboarding, RFQ, negotiation, PO condition, lower-tier request, deferment or temporary governed estimate strategies;
• preserve explainable policy decisions.

4.7 Contribution Request Generator

Responsibilities:

• instantiate governed information/question templates;
• prefill known product/supplier/context information;
• request only unresolved fields;
• expose the reason, evidence expectation and permitted use;
• support branching questions;
• hand execution to Supplier Contribution Orchestrator.

4.8 Product Sustainability Comparability Resolver

Responsibilities:

• compare functional units, product equivalence, system boundaries, methods, allocation, periods, geography, production context, data quality and assurance;
• return COMPARABLE, CONDITIONALLY_COMPARABLE, NORMALIZABLE, NOT_COMPARABLE or INSUFFICIENT_INFORMATION;
• invoke governed MICE normalization only where methodologically valid;
• preserve limitations and uncertainty;
• prevent unsupported PCF ranking.

4.9 Procurement Sustainability Intelligence Service

Responsibilities:

• assemble commercial candidates with EPU/product context;
• require comparability assessment before footprint ranking;
• invoke Computation Hub/MICE for carbon-adjusted and sustainability-adjusted cost calculations;
• apply governed internal carbon-price policy references;
• expose uncertainty and TrustGate context;
• calculate break-even scenarios;
• return traceable decision artifacts without modifying source commercial records.

5. Supplier Contribution Orchestrator extension

The existing Supplier Contribution Orchestrator should be treated as an execution service downstream of resolution and acquisition planning.

Revised responsibility flow:

Requirement Resolver
    ↓
Gap Analyzer
    ↓
Data Authority Resolver
    ↓
Acquisition Planner
    ↓
Contribution Request Generator
    ↓
Supplier Contribution Orchestrator
    ↓
MICE / validation
    ↓
TrustGate

The orchestrator should not independently decide regulatory applicability or create broad questionnaires.

6. Commercial event contract

Input Hub/ACF should normalize commercial events into a stable envelope rather than making EPU depend directly on ERP-specific event names.

Representative event types:

SUPPLIER_ONBOARDING_STARTED
RFQ_CREATED
SOURCING_EVENT_STARTED
CONTRACT_NEGOTIATION_STARTED
SUPPLIER_SELECTED
PURCHASE_REQUISITION_CREATED
PURCHASE_ORDER_DRAFTED
PURCHASE_ORDER_APPROVED
BOM_RELEASED
NEW_PRODUCT_INTRODUCED
CONTRACT_RENEWAL_STARTED

Minimum envelope:

CommercialLifecycleEvent
├── event_id
├── event_type
├── tenant_id
├── source_system_ref
├── source_record_ref
├── supplier_candidate_refs[]
├── product_candidate_refs[]
├── quantity / unit context?
├── delivery / jurisdiction context?
├── occurred_at
├── correlation_id
├── causation_id
└── provenance_ref

Product and supplier source references must pass through governed EPU/ECO resolution before being treated as canonical identities.

7. Requirement-change events

Representative events:

PERGAMUM_REQUIREMENT_CHANGED
REQUIREMENT_APPLICABILITY_CHANGED
REQUIREMENT_SATISFACTION_CHANGED
EVIDENCE_EXPIRED
TRUST_STATE_DEGRADED
DATA_AUTHORITY_CHANGED
ACQUISITION_PLAN_CREATED
ACQUISITION_ACTION_DUE
PRODUCT_INFORMATION_PROFILE_UPDATED

Portfolio-scale consumers must be idempotent and capable of bounded re-evaluation rather than uncontrolled fan-out.

8. Procurement calculation events

Representative events:

PROCUREMENT_CANDIDATE_RESOLVED
COMPARABILITY_ASSESSMENT_COMPLETED
INTERNAL_CARBON_PRICE_POLICY_CHANGED
PROCUREMENT_SCENARIO_REQUESTED
PROCUREMENT_SCENARIO_CALCULATED
PROCUREMENT_DECISION_RECORDED

A carbon-price policy change may invalidate a derived decision view but must not mutate the historical result produced under the earlier policy.

9. Calculation boundary

EPU orchestration may request:

CARBON_ADJUSTED_ACQUISITION_COST
SUSTAINABILITY_ADJUSTED_ACQUISITION_COST
CARBON_PRICE_BREAK_EVEN
SUPPLIER_SUBSTITUTION_SCENARIO
FREIGHT_INCLUSIVE_SCENARIO
UNCERTAINTY_PROPAGATION
PORTFOLIO_SOURCING_OPTIMIZATION

The computation request must reference candidate EPU/product contexts, applicable sustainability results, commercial inputs, financial policy versions, functional units and scenario assumptions.

The authoritative result artifact remains owned by Computation Hub/MICE.

10. Access-control additions

Commercial acquisition/procurement adds sensitive permissions beyond ordinary product traversal:

DISCOVER_SUPPLIER_PRODUCT
RESOLVE_REUSABLE_PROFILE
REQUEST_SUPPLIER_DATA
VIEW_COMMERCIAL_PRICE
VIEW_INTERNAL_CARBON_POLICY
VIEW_PROCUREMENT_SCENARIO
CREATE_ACQUISITION_PLAN
APPROVE_ACQUISITION_REQUEST
VIEW_SUPPLIER_CONFIDENTIAL_DATA

Commercial price and internal carbon policy must not leak through product-data sharing or future marketplace discoverability.

11. Idempotency and deduplication

Commercial events can arrive repeatedly from ERP systems. The architecture must prevent duplicate supplier requests.

A request-deduplication key should consider:

epu/scope
requirement item
supplier/data authority
information profile
applicable product version
requirement policy version
existing open request

If a valid request or reusable answer already exists, a repeated RFQ/PO event should update context/priority rather than create duplicate supplier work.

12. Change propagation

A new accepted supplier datum may trigger:

Requirement Satisfaction refresh
TrustGate refresh
MICE recalculation
Comparability reassessment
Procurement scenario refresh
Disclosure readiness refresh

Dependency propagation must be explicit and bounded. Historical artifacts remain immutable.

13. Scale considerations

Anticipatory acquisition can create large event volumes. Implementations should support:

• portfolio-level applicability indexing;
• cached requirement fingerprints;
• incremental gap evaluation;
• batch product resolution;
• deduplicated supplier requests across multiple buyer needs where policy permits;
• asynchronous MICE/TrustGate workflows;
• priority queues based on commercial/deadline value;
• bounded Pergamum-change impact propagation.

A regulatory update affecting millions of products must not synchronously traverse every full product graph.

14. Implementation order

Recommended incremental order:

1. Supplier product-data connection + identity resolution
2. Product information profiles
3. RequirementSet + Requirement Satisfaction
4. Resolution-first Gap Analyzer
5. Data Authority Resolver
6. Acquisition Planner
7. Contribution Request Generator integration
8. Commercial event ingestion
9. Comparability Assessment
10. Internal carbon policy reference
11. Procurement MICE calculations
12. Procurement decision API/UI

Marketplace listing, auction, payment and transaction services are explicitly excluded.

15. Acceptance scenarios

Scenario A — supplier onboarding

Given a supplier connects a PIM containing 4,000 products, ZAYAZ resolves products to EPUs, establishes source authority, identifies ambiguous mappings for review, and makes permitted product profiles reusable without requiring manual recreation.

Scenario B — RFQ anticipation

Given an RFQ for an EPU-resolved component, ZAYAZ identifies foreseeable chemical/PCF requirements, resolves existing supplier data, determines two fields are missing, and generates only those two requests during negotiation.

Scenario C — carbon-adjusted comparison

Given two technically equivalent products with comparable PCFs, commercial prices and an effective internal carbon-price policy, ZAYAZ produces a reproducible carbon-adjusted comparison with separate commercial price, internal carbon cost, uncertainty, TrustGate state and calculation lineage.

Scenario D — non-comparable PCFs

Given two supplier PCFs with incompatible functional units/boundaries that cannot be governedly normalized, ZAYAZ returns NOT_COMPARABLE and prevents an authoritative carbon-adjusted ranking based on those values.

16. Non-negotiable extension invariants

1. Supplier infrastructure is connected where possible; duplicate manual maintenance is avoided.
2. Reuse precedes request.
3. Commercial leverage can trigger acquisition, but does not alter requirement authority.
4. Every supplier question has a governed requirement/acquisition reason.
5. Supplier contribution execution is downstream of requirement, gap, authority and acquisition decisions.
6. PCF comparability precedes ranking.
7. Commercial price and internal shadow costs remain semantically separate.
8. Computation Hub/MICE owns analytical result artifacts.
9. TrustGate state remains explicit and does not rewrite supplier assertions.
10. Marketplace mechanics remain outside the current service boundary.