EPU Product Graph Ontology
1. Purpose
The EPU Product Graph is the governed relationship network through which ZAYAZ explains a product.
The EPU itself remains a stable identity anchor. The graph connects that identity to product definitions, components, materials, substances, suppliers, organizations, facilities, processes, logistics, production instances, lifecycle events, evidence, calculations, assurance and disclosures.
EPU identifies the product. The EPU Product Graph explains the product.
This ontology defines the semantic contract for graph nodes and relationships. It does not mandate a specific graph database.
2. Graph design principles
- Nodes represent governed identities, states, artifacts, events or reference objects.
- Edges represent explicit typed relationships; important business meaning must not be hidden in application joins.
- Authoritative edges are effective-dated and provenance-bearing.
- Graph topology itself may be confidential and subject to access policy.
- Historical graph state must be reconstructable.
- Source assertions and governed facts must remain distinguishable.
- Derived relationships must identify the derivation method and inputs.
- Every material product-domain artifact must trace directly or transitively to an EPU.
- A graph traversal used for a calculation or disclosure must be reproducible against a defined effective/system-time view.
- The ontology is extensible through governed registries, not arbitrary free-text predicates.
3. Top-level node families
IDENTITY
PRODUCT_STATE
COMPOSITION
ORGANIZATION_AND_LOCATION
PROCESS_AND_ACTIVITY
INSTANCE_AND_EVENT
LOGISTICS_AND_CUSTODY
EVIDENCE_AND_CLAIM
SUSTAINABILITY_RESULT
ASSURANCE
DISCLOSURE
REFERENCE_AND_CLASSIFICATION
These are ontology families, not ZAYAZ Modules.
4. Identity nodes
4.1 EPU
Canonical product-definition identity anchor.
4.2 ECO
Governed organization/legal-entity identity.
4.3 EBU
Governed internal business-unit identity.
4.4 EBP
Governed project/programme/initiative identity.
4.5 ExternalProductIdentity
Representation of an external identifier/namespace such as GTIN, SKU, ERP material ID or PLM ID. This is normally mediated through the Alias Registry rather than treated as an EPU.
5. Product-state nodes
5.1 ProductDefinitionVersion
Effective-dated version of the mutable product definition.
5.2 ProductSpecification
Technical specification artifact or normalized specification set.
5.3 ProductFamily
Grouping/classification node. Product Family is not an EPU by default.
5.4 ProductVariantClassification
Optional grouping for variant semantics where useful for catalog navigation or product policy.
6. Composition nodes
6.1 CompositionVersion
Versioned BOM/formulation/composition root.
6.2 ComponentNode
A component position in a composition structure. It may resolve to another EPU when the component has a governed product identity.
6.3 MaterialNode
Material identity/reference used in composition.
6.4 SubstanceNode
Chemical/substance reference used for regulatory, hazard and composition intelligence.
6.5 PackagingNode
Packaging object kept distinguishable from the primary product/component structure where appropriate.
6.6 CompositionQuantity
Governed quantity/mass/share context for an edge or component node. Quantity semantics must retain unit, basis, uncertainty and source.
7. Organization and location nodes
7.1 Facility
Physical site/location context. Facility is not automatically a governed ACF identity class and must not be conflated with ECO/EBU.
7.2 GeographicLocation
Normalized location/geospatial reference.
7.3 Port, Warehouse, DistributionCenter
Specialized logistics-location nodes where operational intelligence requires them. They may be modeled through a shared facility/location ontology rather than standalone persistence classes.
8. Process and activity nodes
8.1 ManufacturingProcess
Governed process definition or process observation used in production context.
8.2 ActivityData
Measured, reported, estimated or modeled activity input used by calculations.
8.3 EnergyInput
Energy-consumption/generation context where explicit graph representation is useful.
8.4 WasteFlow, WaterFlow, MaterialFlow
Flow nodes where lifecycle or footprint calculations require explicit quantities and provenance.
9. Instance and event nodes
9.1 ProductionRun
Production execution context.
9.2 BatchLot
Batch/lot identity linked to an EPU and production run/context.
9.3 SerializedItem
Lightweight physical-product instance.
9.4 LifecycleEvent
Generic governed event envelope for events such as manufacture, sale, transfer, repair, refurbishment, reuse and end-of-life.
9.5 RepairEvent
Specialized lifecycle event carrying replaced components, evidence and service context.
9.6 EndOfLifeEvent
Specialized lifecycle event for collection, dismantling, recycling, recovery or disposal.
10. Logistics and chain-of-custody nodes
10.1 Shipment
Movement of material/component/product quantities between locations or actors.
10.2 TransportLeg
A shipment segment with origin, destination, transport mode, carrier, distance/time and activity/evidence context.
10.3 TransportMode
Governed reference such as road, rail, ocean, inland waterway, air or multimodal profile.
10.4 CustodyEvent
Transfer or assertion of physical/administrative custody.
10.5 TransformationEvent
Records conversion of input material/components/batches into output product/intermediate/co-product instances.
10.6 MassBalanceAccount
Optional governed object for schemes using mass-balance chain-of-custody accounting. It must remain distinguishable from physical segregation claims.
11. Evidence and claim nodes
11.1 EvidenceArtifact
Document, dataset, certificate, measurement, declaration, transaction record or other evidence artifact.
11.2 Claim
Explicit assertion such as recycled content, origin, renewable-energy share, substance absence/presence, repairability or product footprint claim.
11.3 SupplierContribution
Contribution package from a supplier ECO within a governed scope.
11.4 SourceObservation
Raw or normalized observation from a connected source system.
12. Sustainability-result nodes
12.1 CalculationRun
Governed computation execution with MICE/method/data lineage.
12.2 FootprintResult
PCF, PEF/LCA or other environmental result artifact.
12.3 ImpactCategoryResult
Specific impact category result where separate traversal is valuable.
12.4 ScenarioResult
Modeled alternative used for optimization or decision support.
12.5 AllocationDecision
Governed allocation artifact describing how shared processes/shipments/inputs were assigned to products/co-products.
13. Assurance nodes
13.1 TrustAssessment
TrustGate or equivalent governed trust evaluation.
13.2 VerificationEngagement
Verifier/auditor engagement context.
13.3 VerificationFinding
Finding, exception or approval linked to the exact claim/evidence/result under review.
14. Disclosure nodes
14.1 DisclosureProfile
Rules selecting what may/must be disclosed for an audience, framework or jurisdiction.
14.2 DisclosureArtifact
Published or draft projection such as DPP, PCF API payload, recycler view or customer sustainability record.
14.3 ResolverEndpoint
Governed external resolution endpoint associated with QR/NFC/GS1 Digital Link or other data carrier strategy.
15. Reference and classification nodes
Representative nodes include:
- product classifications;
- CN/HS/customs codes;
- regulatory product categories;
- material classifications;
- substance identifiers;
- hazard classifications;
- lifecycle method profiles;
- emission-factor/dataset references;
- units and functional-unit definitions.
Reference nodes should normally resolve to authoritative ZAYAZ registries rather than duplicate reference datasets inside EPU.
16. Relationship predicate families
Predicates should be grouped into governed families.
IDENTITY_AND_LINEAGE
ORGANIZATIONAL_ROLE
COMPOSITION
PRODUCTION
SUPPLY
LOGISTICS_AND_CUSTODY
LIFECYCLE
EVIDENCE_AND_CLAIM
COMPUTATION
ASSURANCE
DISCLOSURE
CLASSIFICATION
17. Identity and lineage predicates
Recommended initial predicates:
HAS_PRODUCT_DEFINITION_VERSION
SUPERSEDED_BY
REPLACED_BY
SPLIT_INTO
MERGED_INTO
VARIANT_OF
DERIVED_FROM
HAS_EXTERNAL_ALIAS
HAS_INSTANCE
HAS_BATCH_LOT
Direction must be canonical and documented so queries do not rely on inconsistent inverse storage.
18. Organizational-role predicates
Recommended initial predicates:
OWNS_BRAND
MANUFACTURES
CONTRACT_MANUFACTURES
IMPORTS
DISTRIBUTES
SELLS
SUPPLIES
MANAGES
PRODUCES
DEVELOPS
USES
VERIFIES
Example:
ECO-A ── OWNS_BRAND ──> EPU-1
ECO-B ── MANUFACTURES ─> EPU-1
ECO-C ── IMPORTS ──────> EPU-1
Roles must be effective-dated because manufacturer/importer/distributor relationships can change.
19. Composition predicates
Recommended initial predicates:
HAS_COMPOSITION_VERSION
CONTAINS_COMPONENT
COMPONENT_RESOLVES_TO_EPU
CONTAINS_MATERIAL
CONTAINS_SUBSTANCE
USES_PACKAGING
HAS_QUANTITY
SUBSTITUTES_FOR
CO_PRODUCT_OF
BY_PRODUCT_OF
Composition traversal must retain quantity basis and applicable composition version.
Example:
EPU-1
↓ HAS_COMPOSITION_VERSION
BOM-v4
↓ CONTAINS_COMPONENT
BatteryModule-position-17
↓ COMPONENT_RESOLVES_TO_EPU
EPU-BATTERY-9
20. Production predicates
Recommended initial predicates:
PRODUCED_AT
USES_PROCESS
USES_ACTIVITY_DATA
CONSUMES_ENERGY
CONSUMES_MATERIAL
PRODUCES_WASTE
USES_WATER
GENERATED_BY_RUN
USES_COMPOSITION_VERSION
USES_PRODUCT_DEFINITION_VERSION
These relationships allow the same EPU to have different actual production contexts without identity fragmentation.
21. Supply predicates
Recommended initial predicates:
SUPPLIED_BY
SOURCED_FROM
PROVIDES_COMPONENT
PROVIDES_MATERIAL
PROVIDES_SUBSTANCE_DATA
HAS_SUPPLIER_CONTRIBUTION
ORIGINATES_FROM
Supplier role and manufacturer role must remain distinct. A distributor or supplier is not automatically the manufacturer.
22. Logistics and custody predicates
Recommended initial predicates:
SHIPPED_IN
HAS_TRANSPORT_LEG
ORIGIN
DESTINATION
USES_TRANSPORT_MODE
CARRIED_BY
CONTAINS_SHIPMENT_ITEM
TRANSFERRED_TO
HAS_CUSTODY_EVENT
TRANSFORMED_FROM
TRANSFORMED_INTO
ALLOCATED_TO
This predicate family enables logistics optimization without embedding transport data into product identity.
Example traversal:
EPU
↓ composition
Component
↓ supplied_by
Supplier ECO
↓ shipment
Shipment
↓ transport legs
Origin → Port → Port → Plant
↓ activity / factors
GHG + cost + time + risk
23. Lifecycle predicates
Recommended initial predicates:
HAS_LIFECYCLE_EVENT
REPAIRED_AT
REPLACED_COMPONENT
REFURBISHED_AS
REUSED_AS
COLLECTED_BY
RECYCLED_BY
RECOVERED_AS_MATERIAL
DISPOSED_AT
Lifecycle history belongs primarily to physical instances/batches where granularity requires it, not to the shared EPU identity.
24. Evidence and claim predicates
Recommended initial predicates:
SUPPORTED_BY
ASSERTED_BY
DERIVED_FROM_EVIDENCE
CLAIMS
VALIDATES
CONTRADICTS
SUPERSEDES_EVIDENCE
HAS_SOURCE_OBSERVATION
Evidence relationships must preserve source authority and access restrictions.
25. Computation predicates
Recommended initial predicates:
HAS_CALCULATION_RUN
USES_INPUT
USES_METHOD
USES_DATASET
USES_FACTOR
USES_ALLOCATION
PRODUCES_RESULT
HAS_IMPACT_CATEGORY_RESULT
MODELS_SCENARIO
COMPARES_WITH
A product footprint answer should be traversable back through these relationships to the exact evidence and activity data used.
26. Assurance predicates
Recommended initial predicates:
ASSESSED_BY_TRUSTGATE
VERIFIED_BY
HAS_FINDING
APPROVES
REJECTS
QUALIFIES
REQUIRES_REMEDIATION
Verification status should attach to the exact artifact or claim reviewed, not become a generic permanent property of the EPU.
27. Disclosure predicates
Recommended initial predicates:
HAS_DISCLOSURE_PROFILE
PROJECTED_AS
PUBLISHED_AS
RESOLVES_TO
DISCLOSES_CLAIM
DISCLOSES_RESULT
DISCLOSES_EVIDENCE_REFERENCE
A DPP therefore becomes a controlled projection over selected graph paths.
28. Classification predicates
Recommended initial predicates:
CLASSIFIED_AS
HAS_CUSTOMS_CLASSIFICATION
HAS_REGULATORY_CATEGORY
HAS_MATERIAL_CLASSIFICATION
HAS_HAZARD_CLASSIFICATION
Classification edges must carry source/version/effective-date metadata because classifications can evolve independently of identity.
29. Canonical edge envelope
Every authoritative edge should support:
relationship_id
subject_ref
predicate
object_ref
valid_from
valid_to
system_from
system_to
asserted_by
source_ref
evidence_refs[]
authority
confidence
access_policy_ref
provenance_ref
derivation_ref?
valid_* represents business/domain truth time. system_* represents when ZAYAZ held the assertion.
30. Assertion states
Graph relationships should distinguish at least:
SOURCE_ASSERTED
NORMALIZED
INFERRED
GOVERNED
VERIFIED
DISPUTED
SUPERSEDED
REVOKED
A source assertion must not silently become a verified fact merely because it was imported successfully.
31. Traversal views
The Product Graph Service should support explicit view semantics.
31.1 Current governed view
Returns currently effective governed relationships.
31.2 As-of valid-time view
Returns relationships valid for a requested business date/time.
31.3 As-known-at view
Returns what ZAYAZ knew at a specified historical system time.
31.4 Verified-only view
Restricts traversal to relationships/artifacts meeting specified verification/TrustGate criteria.
31.5 Source-native view
Allows authorized users to inspect source assertions before/alongside normalized governed state.
31.6 Scenario view
Overlays modeled alternatives without mutating authoritative graph state.
32. Traversal result contract
A product-intelligence query should not return only an answer. It should be capable of returning an answer envelope.
ProductIntelligenceAnswer
├── question / query intent
├── epu_id
├── answer
├── units / basis
├── effective_time
├── graph_view
├── traversal_path[]
├── source_refs[]
├── evidence_refs[]
├── calculation_refs[]
├── method_refs[]
├── trust_state
├── confidence / uncertainty
├── policy_context
└── generated_at
This contract makes product intelligence auditable and suitable for verifier, customer and regulatory use.
33. Example: manufacturer of a component
Question:
Which manufacturer supplies the cells used in this product's battery?
Traversal:
EPU finished product
↓ HAS_COMPOSITION_VERSION
BOM effective for requested date
↓ CONTAINS_COMPONENT
Battery module
↓ COMPONENT_RESOLVES_TO_EPU
Battery EPU
↓ HAS_COMPOSITION_VERSION
Battery BOM
↓ CONTAINS_COMPONENT
Cell
↓ SUPPLIED_BY / MANUFACTURES
Supplier/manufacturer ECO
↓ SUPPORTED_BY
Evidence / source records
The answer must distinguish supplier from manufacturer where the graph contains different ECOs for those roles.
34. Example: current product GHG footprint
Question:
What is the current approved GHG footprint of this product?
Traversal:
EPU
↓ applicable ProductDefinitionVersion
↓ applicable ProductionContext
↓ HAS_CALCULATION_RUN
CalculationRun
↓ PRODUCES_RESULT
FootprintResult
↓ ASSESSED_BY_TRUSTGATE
TrustAssessment
The answer can additionally traverse calculation inputs, method, factors, datasets, evidence and allocation decisions.
35. Example: freight-route optimization
Question:
Can we optimize the freight routes for the components in this product?
The Product Intelligence Query Gateway should resolve the relevant product graph and then request governed scenario computation.
EPU
↓ composition
Components
↓ supplier/manufacturer relationships
Origin facilities / geographies
↓ shipments and transport legs
Current routes
↓ modes / distances / load factors / consolidation
Activity data
↓ computation
Baseline GHG + cost + time + risk
↓ scenario generation
Alternative suppliers / ports / routes / modes / consolidation
↓ constraints
lead time + capacity + contracts + customs + product requirements
↓ scenario results
Pareto-optimal alternatives
Potential outputs include:
- route changes that reduce freight GHG without violating service constraints;
- modal shift opportunities such as air-to-ocean or road-to-rail;
- component consolidation opportunities;
- alternate port/warehouse routing;
- sourcing changes that reduce unnecessary transport distance;
- changes in production location that alter total inbound/outbound logistics;
- cost versus GHG versus lead-time trade-offs;
- identification of freight lanes dominating product transport emissions;
- uncertainty ranges where route/activity data is incomplete.
The optimization result must remain a scenario, not silently overwrite actual chain-of-custody or shipment history.
36. Example: chemical compliance
Question:
Which components contain substances of concern, and which supplier evidence supports that conclusion?
Traversal can follow:
EPU
→ composition
→ component
→ material
→ substance
→ classification / regulatory requirement
→ supplier contribution
→ evidence
→ verification state
This supports REACH/SCIP and other chemical/product compliance workflows without hard-coding a single regulation into EPU identity.
37. Example: circularity and end of life
Question:
Which components are replaceable, what materials can be recovered, and which recycler can process the product in Norway?
The graph can combine:
- product/component structure;
- repairability/service information;
- material/substance data;
- end-of-life instructions;
- geographic location;
- recycler capability relationships;
- regulatory constraints;
- evidence and assurance.
The recycler answer is contextual and time-sensitive; it must not become a permanent EPU identity attribute.
38. Product-intelligence query families
The graph should ultimately support questions across:
Identity and product definition
- What exactly is this product?
- Which identifiers resolve to it?
- What changed between product-definition versions?
- What product superseded this one?
Supply chain
- Who manufactures each component?
- Which Tier-2/Tier-3 suppliers contribute to this product?
- Which supplier relationships are unverified?
- Which supplier data gaps have the greatest decision impact?
Composition and chemicals
- What materials and substances are present?
- Which components contain regulated substances?
- Which composition version applied to a particular batch?
GHG and lifecycle impact
- What is the approved PCF?
- Which components/processes dominate the footprint?
- Why did PCF v4 differ from v3?
- Which primary data would reduce uncertainty most?
- How does the result change under alternative allocation or sourcing scenarios?
Logistics
- Can we optimize freight routes for this product's components?
- Which transport legs dominate logistics emissions?
- Can shipments be consolidated?
- What is the cost/GHG/lead-time Pareto frontier for alternative routes?
Circularity
- What recycled content is evidenced?
- Which parts are replaceable?
- Which materials are recoverable?
- Which end-of-life pathway has the lowest modeled impact?
Evidence and assurance
- What evidence supports a claim?
- Which claims are supplier-asserted versus verified?
- What evidence is expired or disputed?
- Which verifier findings remain unresolved?
Disclosure
- Is this EPU ready for a specific DPP profile?
- Which required fields are missing?
- Which information may be shown to consumers, regulators, customers or recyclers?
39. Query safety and authority
A graph query engine must never confuse:
source assertion
≠ normalized fact
≠ inferred relationship
≠ governed fact
≠ verified fact
≠ modeled scenario
Product-intelligence answers must expose these distinctions when they materially affect interpretation.
40. Registry roadmap
The ontology should ultimately be backed by machine-readable registries for:
- node types;
- relationship predicates;
- allowed subject/object combinations;
- inverse predicates;
- cardinality expectations;
- temporal requirements;
- evidence requirements;
- confidentiality defaults;
- derivation rules;
- deprecation/supersession;
- ontology versions.
Example registry concept:
predicate: MANUFACTURES
subject_types: [ECO]
object_types: [EPU, ComponentNode]
temporal: required
provenance: required
evidence: recommended
inverse: MANUFACTURED_BY
status: active
ontology_version: 1
41. Non-negotiable graph invariants
- EPU is the stable product entry point, not a mutable dossier record.
- Graph edges are governed first-class objects.
- Supplier and manufacturer roles remain semantically distinct.
- Component nodes may resolve to EPUs but are not automatically EPUs.
- Materials and substances are not forced into EPU identity semantics.
- Facility/location context remains distinct from ECO/EBU identity.
- Actual events and modeled scenarios never share authoritative state.
- Calculation lineage remains traversable to methods, factors, datasets, evidence and allocation.
- Disclosure is a policy-controlled projection over the graph.
- Access control can hide graph topology as well as values.
- Historical graph views are reconstructable.
- Product-intelligence answers can return the path and provenance supporting the answer.
The Product Graph is therefore the semantic foundation that allows EPU to become the backend for DPP, product GHG, PEF/LCA, supply-chain transparency, chemical compliance, circularity, logistics optimization and future product sustainability intelligence without turning EPU itself into an ungovernable monolithic record.