PEF / LCA Implementation Roadmap

1. Purpose

This document turns the recurring PEF / LCA / Emissions-Factor research intake into a continuously governed ZAYAZ implementation roadmap.

The premise is deliberately ambitious but controlled:

ZAYAZ should continuously learn from the global PEF/LCA scientific, technical and regulatory community without surrendering architecture or method governance to it.

The objective is therefore not to accumulate interesting papers or automatically implement whatever is newest. The objective is to continuously answer:

What should ZAYAZ change, add, govern, test or prepare because this new PEF/LCA knowledge exists?

Research findings, technical analyses, datasets and expert recommendations are treated as high-value evidence and architecture inputs. They do not automatically become ZAYAZ policy. Normative authority continues to come from the applicable laws, Commission methods and guidance, valid PEFCR/OEFSR rules, governed internal policies and other authoritative sources applicable to the calculation or claim.

1.1. The continuous research → architecture → implementation loop

The operating model deliberately separates discovery from architectural judgment.

Every Friday, ZAYAZ scans for the most consequential new peer-reviewed research, JRC/EU/government work, technical datasets, methodology notes and credible analyses relevant to PEF, LCA and emissions-factor intelligence.

Every Saturday, the resulting weekly cohort is subjected to a stricter Architecture Integration review. Each finding is re-checked, classified, compared with the current canonical ZAYAZ architecture and accepted into this roadmap only if it creates a meaningful method, data, computation, uncertainty, supplier-data, assurance, rights, interoperability, performance or product-strategy delta.

The resulting loop is:

GLOBAL PEF / LCA RESEARCH, METHODS & TECHNICAL EVIDENCE
                         │
                         ▼
              Friday intelligence scan
                         │
                         ▼
                 YYYY-Www cohort
                         │
                         ▼
          Saturday architecture integration
                         │
                         ▼
        Does it create a meaningful ZAYAZ delta?
                 ╱                       ╲
               NO                         YES
               │                           │
               ▼                           ▼
        WATCH / NO_ACTION          Roadmap evolution
               │                           │
               │                           ▼
               │                 Canonical-spec impact
               │                           │
               │                           ▼
               │                 Governed contract / Need
               │                           │
               │                           ▼
               │                         Hecate
               │                           │
               │                           ▼
               │                    Implementation
               │                           │
               │                           ▼
               │                      Validation
               │                           │
               └───────────────►          ZAYAZ
                                           │
                                           └──► next research cycle

This creates a deliberately short path from new expert knowledge to governed product capability, while retaining constitutional control at every stage.

The automation is valuable precisely because it can compress the discovery-to-architecture cycle from months or annual methodology reviews to days. The governance gates are equally important: automation increases the speed at which ZAYAZ can evaluate an idea, not the authority of the idea itself.

A paper that is scientifically interesting but creates no current ZAYAZ consequence remains WATCH or NO_ACTION. A material finding may change this roadmap, identify another canonical specification that requires review, create a governed contract requirement or become a bounded Hecate Need. Repository changes remain reviewable and are not automatically merged into main simply because the weekly automation proposed them.

1.2. The roadmap is also an evolution history

The ISO weekly cohort tags — for example 2026-W35, 2026-W36, 2026-W37, 2026-W38 — create more than a filing convention. Together with the architecture-delta tags, they create a research-derived evolution history of the PEF/LCA capability.

Over time, the crew should be able to trace statements such as:

2026-W35
  → governed product comparability
  → functional-unit sensitivity
  → time-resolved factor requirements
  → footprint / circularity separation
  → native ILCD/eILCD preservation

2026-W36
  → governed Method Profiles
  → explainable Factor Resolution Receipts
  → supplier-data escalation from hotspots and sensitivity
  → prospective LCA scenario architecture
  → probabilistic uncertainty requirements
  → dataset-rights eligibility

2026-W37
  → LCIA Method Packages with category-specific factor semantics
  → progressive LCA aligned to product-development maturity
  → immutable factor-dataset vintage / snapshot semantics
  → governed service-life and replacement assumptions
  → LNG pathway analysis retained as a validation fixture rather than a new architecture

2026-W38
  → governed data-quality admission floors and pedigree/uncertainty lineage
  → activity-data resolution and aggregation lineage
  → governed provenance for derived / predicted inventory evidence
  → dependency-bounded incremental recalculation
  → process-based inventory versus pre-aggregated factor fitness
  → multidimensional factor-resolution stress testing
  → governed rule-stack resolution for PCR/PEFCR/programme applicability
  → purpose-specific data-detail requirements

2026-W39
  → factor-scope/decomposition semantics and licence-aware factor eligibility
  → LCIA aggregation metadata for ecosystem/resource methods
  → allocation/method-choice uncertainty separated from parameter uncertainty
  → deterministic validation boundary for natural-language model editing

2026-W40
  → jurisdiction-, claimant- and publication-context method/disclosure precedence
  → serialization-independent uncertainty semantics with explicit mapping loss
  → supplier-resolution bias retained as escalation evidence
  → release- and rights-aware use of open emissions datasets

2026-W41
  → indicator-specific dataset fitness and required-flow coverage
  → competing proxy hypotheses preserved instead of collapsed
  → process-level hotspot and comparison studies retained as validation fixtures
  → product-carbon-footprint adoption evidence retained as a strategy signal

2026-W42
  → source-inventory identity separated from distribution/import representation
  → attributional and consequential modelling principles isolated by governed method
  → marginal-supplier assumptions separated from observed supplier relationships
  → future circular credits bound to time, recovered-material quality and displaced process
  → declared boundaries checked against modeled coverage evidence
  → BIM-linked LCA retained as an interoperability fixture rather than a new engine

2026-W43
  → exchanged footprint evidence separated from completeness, reproducibility and assurance claims
  → external ontology mappings governed without duplicating canonical identities
  → consequential scenarios disclose included, excluded and unresolved response mechanisms
  → remanufacturing and technical-performance studies retained as comparability fixtures
  → actor-specific DPP data priorities retained as product-strategy evidence

Future cohorts will continue that record.

This means the document becomes an architecture provenance ledger in human-readable form. It records not only what ZAYAZ decided, but increasingly:

• which external finding triggered the review;
• when that finding entered the architecture process;
• whether it was research insight, technical guidance, normative methodology or legal authority;
• which ZAYAZ contracts, datasets, engines, assurance rules or product capabilities it affected;
• whether the finding was accepted, watched, superseded or implemented;
• which Hecate Need and deterministic acceptance evidence ultimately operationalised it.

This history is important because sophisticated PEF/LCA architecture contains many decisions that can otherwise look arbitrary years later. The cohort lineage allows a future engineer, verifier, sustainability specialist or architect to ask:

Why does ZAYAZ work this way?

and follow the answer back through the architectural decision to the scientific, methodological or regulatory evidence that caused it.

1.3. Why this matters to ZAYAZ

The loop creates several strategic advantages.

Continuous exposure to state-of-the-art practice. ZAYAZ does not freeze its PEF/LCA architecture at the knowledge level available when the first calculator is built. New work on uncertainty, functional equivalence, factor quality, primary data, prospective modelling, verification or datasets continuously challenges the current design.

Selective rather than reactive innovation. Newness alone is not a reason to alter the platform. Every finding is tested against the current architecture and governing authority before it becomes a canonical delta. This reduces architecture churn and avoids bolting fashionable research ideas onto the platform without a bounded responsibility.

Fast translation from expertise into software. Once a useful idea survives architectural review, ZAYAZ can translate it into governed contracts, acceptance criteria and Hecate-ready implementation work quickly. The system is designed so that valuable external expertise can become testable product capability in days rather than waiting for a large periodic redesign.

Architecture coherence. New ideas are evaluated against the EPU Product Graph, Computation Hub/MICE, Pergamum Pulse, TrustGate, Replay, SSSR/USO/ZAR and other canonical specifications before implementation. The platform therefore evolves as a system rather than as a collection of independent PEF features.

Institutional memory and auditability. Weekly cohorts create a durable explanation of why major PEF/LCA design choices entered ZAYAZ. This reduces dependence on individual memory and gives future reviewers a traceable reasoning path.

Implementation discipline. The loop ends in bounded, deterministic Hecate work rather than in research notes or broad engineering epics. Architecture precedes implementation, and implementation is expected to prove the accepted design through validation evidence.

Compounding advantage. Every accepted cohort improves the baseline against which the next cohort is evaluated. The architecture therefore becomes progressively more informed, more explicit and harder to displace with a superficially attractive but incomplete proposal.

For the crew, this is the central importance of the roadmap: it is not simply a plan for building PEF. It is the mechanism by which ZAYAZ keeps learning how the best possible PEF/LCA system should be built, while preserving its own governance, traceability and implementation discipline.

The PEF/LCA process is also a proving ground for a broader ZAYAZ operating model. If the pattern continues to demonstrate value, the same separation of external intelligence → governed architecture integration → Hecate implementation can be reused for domains such as CSRD/ESRS, CSDDD, assurance, Digital Product Passports, biodiversity methods, financed emissions and procurement. Each domain would retain its own authorities, canonical architecture and acceptance rules; the reusable innovation is the governance loop itself.

1.4. Initial cohorts

Version 0.4.1 establishes the evolution history across 2026-W35 through 2026-W38. The 2026-W35 and 2026-W37 cohorts remain explicitly marked as reconstructed. The 2026-W38 cohort was initially reconstructed during the Saturday architecture review, then reconciled on 19 September 2026 against the exact Friday shortlist supplied after that review. The canonical W38 record now follows the actual Friday cohort, while additional Saturday discoveries are labelled separately as supplemental architecture-review sources.

The weekly items are not treated as disconnected features. They are interpreted together and integrated only when they create a meaningful method, data, computation, uncertainty, supplier-data, assurance, rights, interoperability or product-strategy delta.

For the 2026-W36 cohort, the combined signal is that:

1. harmonisation work shows which modelling choices must become explicit governed method parameters rather than analyst conventions;¹
2. supplier-data research shows how ZAYAZ can move intelligently from coarse screening data to primary product evidence instead of asking every supplier for everything;²
3. prospective LCA research shows that future product footprints require governed scenario identity, time consistency and future background datasets rather than a static factor lookup;³
4. probabilistic whole-life-cycle research shows that uncertainty must be propagated through calculations and reported as a distribution, not hidden behind a single confidence label;⁴
5. the IEA 2026 factor products show both the value of richer electricity life-cycle factors and the need to treat licensing and permitted use as part of dataset governance.⁵⁶

For the reconstructed 2026-W37 cohort, the combined signal is that:

1. LCIA methods themselves are increasingly multi-dimensional governed packages rather than one method name plus one undifferentiated characterization-factor table;⁷
2. useful LCA must be available early enough in product development to change design decisions, with explicit maturity and evidence limits rather than waiting for a final product definition;⁸
3. rapidly updated factor products require provider-release/vintage identity and immutable captured snapshots in addition to observation-period semantics;⁹
4. service-life and replacement assumptions can materially dominate whole-life results and therefore require governed evidence, uncertainty and scenario treatment beyond comparative claims;¹⁰
5. supply-chain pathway analyses such as LNG reinforce the existing need for stage-resolved, route-aware factor lineage, but do not require a new ZAYAZ architecture because the current graph/factor model already supports that decomposition.¹¹

For the reconciled 2026-W38 Friday cohort, the combined signal is that:

1. authoritative technical methods can impose explicit minimum data-quality admission floors and derive uncertainty from pedigree dimensions, so ZAYAZ must distinguish admission eligibility from later candidate ranking or trust assessment;¹²
2. activity-data aggregation itself can materially change calculated impacts and hotspot visibility, so the original observation resolution and every aggregation transform must remain governed and replayable;¹³
3. proxy, mined, simulated and predictive environmental data are useful for closing data gaps only when their generation method, applicability, reproducibility evidence and uncertainty remain explicit — and a predicted LCIA result must never masquerade as an LCI dataset;¹⁴
4. continuous product-footprint systems benefit from dependency-bounded incremental recomputation, but inferred inputs must retain provenance/confidence and never become silently equivalent to verified or authoritative evidence;¹⁵
5. real technical datasets stress factor identity across domain/process context, geography, lifecycle stage, reference year, scenario and source version, while reproducible code can become validation evidence for factor transformations;¹⁶
6. no new authoritative European Commission/JRC EF normalisation or weighting release was identified for the W38 window; the EPLCA Environmental Footprint page remained last updated on 7 July 2026.¹⁷

The Saturday architecture review additionally identified two useful supplemental sources: process-based clinker-substitute inventory work strengthens the accepted Inventory Dataset Fitness delta,¹⁸ while prospective agrivoltaics remains a WATCH scenario-coherence fixture already covered by the W36 prospective-LCA architecture.¹⁹

The resulting architectural conclusion remains:

ZAYAZ should not build PEF as one large calculator. It should build a governed product-footprint capability in which product-system state, method rules, activity-data resolution, dataset representation, factor resolution, computation, uncertainty, evidence, rights, replay and verification remain separate but composable constitutional concerns.

This roadmap is therefore a cross-module capability specification. It does not create a new ZAYAZ Module and it does not redefine existing constitutional object types.

---

2. Executive decision

The recommended PEF/LCA architecture is a governed calculation stack over the EPU Product Graph, with the Computation Hub executing versioned methods and TrustGate assessing whether a resulting footprint is sufficiently trustworthy for its intended purpose.

The target operating chain is:

Authoritative PEF / LCA rules and scientific methods
        │
        ▼
Pergamum Pulse governed knowledge
        │
        ▼
Rule Stack Resolution
(governing framework + core rules + PCR/PEFCR + programme/adoption/interpretation + applicable legal/harmonisation rules)
        │
        ▼
Governed method profile + factor-resolution policy
        │
        ├─────────────── Dataset / factor registry + rights
        │
        ▼
EPU Product Graph
(product, BOM, materials, suppliers, facilities, activity, logistics, lifecycle)
        │
        ▼
Assessment maturity + intended-use context
        │
        ▼
Activity-data resolution / aggregation + derivation provenance
        │
        ▼
LCI assembly + dataset-fitness + data-quality evaluation
        │
        ▼
LCIA Method Package resolution
        │
        ▼
Computation Hub / MICE execution
(characterisation → normalisation → weighting → interpretation)
        │
        ├─────────────── uncertainty / sensitivity / scenario execution
        │
        ▼
CalculationRun
        │
        ├── FootprintResult
        ├── ImpactCategoryResult[]
        ├── AllocationDecision[]
        └── ScenarioResult[]
        │
        ▼
TrustGate + verifier workflow
        │
        ▼
Governed disclosure projections
(PEF report, PCF, Carbon Passport, DPP, customer / procurement / reporting outputs)

The architecture should preserve one principle throughout:

A footprint result is not a number. It is a replayable evidence graph describing what was calculated, which governed rule stack applied, why that method was allowed, which product state and activity-data resolution were used, how derived data was generated, which datasets and factors were selected, which alternatives were rejected, what uncertainty remains, and what level of assurance the result has earned.

---

3. What ZAYAZ already has that should become the PEF foundation

3.1. EPU Product Graph is the correct product-system substrate

The current EPU Product Graph already defines the objects PEF/LCA needs at product level:

• ActivityData;
• material, water, energy and waste flows;
• product and composition versions;
• supplier contributions;
• production and logistics context;
• lifecycle events;
• CalculationRun;
• FootprintResult;
• ImpactCategoryResult;
• AllocationDecision;
• ScenarioResult;
• evidence and verification relationships;
• method, factor and dataset references.

It also already establishes the critical computation predicates:

HAS_CALCULATION_RUN
USES_INPUT
USES_METHOD
USES_DATASET
USES_FACTOR
USES_ALLOCATION
PRODUCES_RESULT
HAS_IMPACT_CATEGORY_RESULT
MODELS_SCENARIO
COMPARES_WITH

That is the correct ontology. PEF should extend its use, not introduce a second PEF-specific product graph.

W38 does, however, require review of how ActivityData carries observation resolution, aggregation lineage and derived/proxy provenance. That review must extend existing EPU semantics where possible rather than inventing a parallel PEF activity object.

3.2. Supplier Contribution Architecture already supports the right acquisition philosophy

The current EPU Supplier Contribution architecture uses:

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

That is almost exactly the operating model suggested by the supplier-data escalation research.²

PEF should therefore consume the Supplier Contribution architecture rather than creating a PEF questionnaire subsystem.

W38 strengthens the definition of the unresolved delta: it may be not only a missing value, but also a material resolution, derivation or dataset-granularity deficiency that prevents the intended decision from being supported safely.

3.3. Computation Hub already has the correct execution principles

The current Computation Hub model already supports:

• versioned compute methods;
• dataset requirements;
• normalization;
• scenario modelling;
• uncertainty quantification;
• replayable executions;
• dataset provenance.

PEF/LCA should become one of the strongest users of those contracts.

Activity-data aggregation, inventory derivation and dataset-fitness evaluation should be expressed as governed inputs/transforms/receipts around computation, not as undocumented preprocessing hidden inside an engine.

3.4. Existing PEF/LCA identities are historical inputs, not assumed target architecture

The repository already contains older PEF/LCA assets. They were created before several of the current constitutional, EPU, Hecate, replay, Pergamum Pulse and product-intelligence specifications existed.

They should therefore be preserved as historical/canonical identities where applicable, but their current content must not be assumed to represent the final PEF architecture.

Existing identity	Current state	Recommended disposition
PEF-ME	Older Micro-Engine placeholder	Preserve the identity while its legacy/PDF source is migrated into a current Docusaurus specification. Make it Hecate-ready, then evaluate its bounded responsibility against this roadmap, the EPU specification series, current MICE architecture and applicable constitutions.
LCA-OPTI	Older LCA Optimizer placeholder	Preserve the identity while its legacy/PDF source is migrated. Evaluate whether the final responsibility remains optimization, should be narrowed, or should be decomposed after the deterministic PEF/LCA execution architecture is defined.
ZARA-MO	Older ZARA PEF/OEF modelling placeholder	Reconcile during documentation migration against current ZARA responsibilities. The likely long-term role is governed orchestration, explanation and scenario assistance; LLM reasoning must not become numeric method authority.
PEFX	Older Product Environmental Footprint Exchange placeholder	Migrate and make Hecate-ready, then reconcile with EPU disclosure/interoperability, Carbon Passport, DPP and current external-contract architecture before assigning the final responsibility boundary.
fact_pef_run	Older narrow persistence prototype linked to FUME input/result rows	Treat as existing implementation evidence rather than target architecture. Reconcile its actual semantics against the future generic CalculationRun, computation telemetry and product-result persistence model before deciding migration, reuse or deprecation.
schemas/pef-run-request.schema.json	Referenced by older architecture documentation but not present on main	Define a governed request contract only after the method/run envelope in this roadmap is approved.

The migration procedure is therefore:

Legacy PDF / historical specification
        ↓
Governed documentation transfer
        ↓
Current Docusaurus specification
        ↓
Hecate-ready contract + acceptance criteria
        ↓
Reconciliation against:
  - this PEF/LCA roadmap
  - EPU specification series
  - current constitutions
  - MICE / Computation Hub
  - SSSR / USO / ZAR
  - Pergamum Pulse
  - TrustGate / Replay / Scoring
  - current product/disclosure architecture
        ↓
Keep / update / narrow / split / deprecate implementation semantics

---

4. Weekly research cohorts → ZAYAZ architecture deltas

4.0. Cohort tagging convention

Every weekly research item that enters the canonical roadmap shall carry two independent tag dimensions.

Weekly cohort tag

YYYY-Www

Examples:

2026-W35
2026-W36
2026-W37
2026-W38

The cohort tag uses the ISO week number and identifies the Friday research intake in which the item entered architectural review.

Architecture-delta tags

One item may have multiple delta tags:

METHOD_DELTA
FACTOR_DATA_DELTA
QUALITY_DELTA
UNCERTAINTY_DELTA
SUPPLIER_DATA_DELTA
SCENARIO_DELTA
ASSURANCE_DELTA
RIGHTS_DELTA
INTEROPERABILITY_DELTA
PERFORMANCE_DELTA
PRODUCT_STRATEGY_DELTA
NO_ACTION
WATCH

The weekly cohort identifies when the item entered review. Delta tags identify why it matters.

An item should be added to this roadmap only when the analysis produces a meaningful architecture, data, computation, assurance, rights, interoperability or product-strategy consequence. Interesting research with no current ZAYAZ consequence remains in the weekly brief under WATCH or NO_ACTION rather than inflating the canonical roadmap.

4.1. Horizon Europe battery LCA harmonisation

Weekly cohort: 2026-W36
Delta tags: METHOD_DELTA, QUALITY_DELTA, INTEROPERABILITY_DELTA

The battery harmonisation paper compares five Horizon Europe projects and reports convergence around capacity-based functional units, common background databases and EF 3.1, while still finding material differences in system boundaries, end-of-life modelling, allocation, electricity assumptions and reporting.¹

What this means for ZAYAZ

These are not analyst preferences. They are method-profile parameters.

ZAYAZ should make at least the following explicit, versioned and replayable for every product-footprint run:

study_goal
intended_use
product_category
method_profile_ref
category_rule_ref?
functional_unit
reference_flow
functional_equivalence_profile_ref?
system_boundary
life_cycle_stages[]
cut_off_policy_ref
allocation_policy_ref
recycling_model_ref
end_of_life_model_ref
electricity_model_ref
transport_model_ref
background_dataset_profile_ref
impact_method_ref
impact_categories[]
normalisation_profile_ref
weighting_profile_ref
representative_product_ref?
benchmark_ref?
reporting_profile_ref
verification_profile_ref

The important design decision is that these belong to a governed method/run envelope, not hidden inside one engine implementation.

Implementation delta

Create a governed PEF/LCA Method Profile contract capable of representing:

• general PEF;
• a specific valid PEFCR;
• ISO-oriented LCA variants;
• product carbon footprint profiles;
• future sector/product-specific variants;
• EF 3.1 and later EF method versions side-by-side.

A method profile should define allowed choices, required choices and prohibited combinations. The engine consumes the profile; it does not invent the profile.

Why battery is a strong golden specimen

A battery EPU is a strong first implementation specimen because it forces ZAYAZ to handle, in one bounded test case:

• multi-level BOMs;
• supplier-specific upstream material data;
• electricity assumptions;
• recycled content;
• allocation;
• logistics;
• use-stage assumptions where applicable;
• end-of-life and recycling;
• high-impact material hotspots;
• regulatory and product-footprint relevance.

The golden specimen should be a real governed EPU with versioned composition and evidence, not a disconnected calculator fixture.

---

4.2. EEIO hotspot screening → supplier-specific data prioritisation

Weekly cohort: 2026-W36
Delta tags: SUPPLIER_DATA_DELTA, QUALITY_DELTA, UNCERTAINTY_DELTA, PRODUCT_STRATEGY_DELTA

The supplier-data paper proposes a data-escalation protocol moving from EEIO hotspot screening through supply-chain structure and public product evidence toward targeted supplier-specific information.²

This is especially important because the economically rational PEF strategy is not:

ask every supplier for perfect primary data before calculating anything.

It is:

calculate with the best governed evidence available, identify where better data would materially change the decision, and acquire that data first.

Recommended ZAYAZ capability: Data Escalation Planner

The Data Escalation Planner should be a governed workflow/service capability, not a new scoring formula hidden inside PEF-ME.

Conceptually:

Product / EPU scope
      ↓
available primary + secondary data
      ↓
coarse screening model
      ↓
hotspot decomposition
      ↓
quality + uncertainty + boundary-gap analysis
      ↓
ranked data-improvement opportunities
      ↓
Data Authority Resolution
      ↓
EPU Supplier Contribution request for unresolved delta only
      ↓
TrustGate / validation
      ↓
recalculation
      ↓
measured improvement in result quality / uncertainty

The prioritisation model should consider separately:

• contribution to total impact;
• contribution to decision-relevant impact categories;
• uncertainty contribution;
• data-quality deficiency;
• likelihood that better data can be obtained;
• supplier leverage / acquisition cost;
• verification state;
• boundary mismatch;
• whether the current value is estimated, proxy, industry average or primary;
• whether the result is close to a decision or compliance threshold.

A later optimization objective can rank requests by expected decision value per acquisition effort. That optimization should remain a governed policy/scoring problem and conform to the Scoring Constitution.

FOGE / SEEL consequence

FOGE should not generate generic PEF questionnaires. It should generate a contribution form from the exact unresolved data contract.

For example:

EPU battery pack
  → hotspot = cathode material
  → current dataset = generic regional secondary dataset
  → uncertainty contribution = high
  → missing fields = supplier material mass + electricity geography + recycled content
  → authoritative party = cathode supplier
  → FOGE generates only those fields
  → SEEL explains why the data matters and how it will be used

This directly operationalises ZAYAZ's existing No Ask Before Reuse principle.

---

4.3. Prospective LCA

Weekly cohort: 2026-W36
Delta tags: SCENARIO_DELTA, UNCERTAINTY_DELTA, METHOD_DELTA

The prospective PV LCA review finds recurring weaknesses in future scenario construction, scaling, foreground/background time consistency, future inventory data and uncertainty treatment.³

The ZAYAZ consequence is significant:

Prospective LCA must not be implemented by replacing today's factors with guessed future factors.

It requires a separate scenario state with its own identity, assumptions, time horizon and dataset versions.

Recommended scenario contract

Every prospective footprint scenario should preserve:

scenario_id
scenario_family_ref
base_calculation_run_ref
future_time_horizon
foreground_projection_ref
background_projection_ref
technology_maturity_assumptions
scale_up_assumptions
market_assumptions
energy_mix_assumptions
policy_assumptions
impact_method_version
factor_dataset_versions[]
uncertainty_model_ref
stakeholder_assumption_refs[]
created_from_evidence_refs[]

The EPU Product Graph already provides the right safety model: modeled scenarios must remain distinct from actual authoritative product state.

RIF / FIRM / LCA-OPTI consequence

Prospective LCA should interface with scenario and risk capabilities rather than duplicate them.

Recommended separation:

• PEF/LCA computation calculates environmental outcomes under a scenario;
• RIF quantifies uncertainty/risk and compares scenario distributions;
• FIRM may translate environmental scenario changes into financial exposure where relevant;
• LCA-OPTI may search the governed scenario space for lower-impact alternatives;
• ZARA explains scenario assumptions and trade-offs.

LCA-OPTI should not optimize against a single point estimate when uncertainty materially changes the ranking of alternatives.

---

4.4. Probabilistic whole-life-cycle modelling

Weekly cohort: 2026-W36
Delta tags: UNCERTAINTY_DELTA, ASSURANCE_DELTA, METHOD_DELTA

The probabilistic displacement-factor study uses Monte Carlo simulation and sensitivity analysis to propagate uncertainty in EPD data and end-of-life scenarios rather than reporting one deterministic value.⁴

This should become a general ZAYAZ LCA principle:

Data quality and statistical uncertainty are related but different concepts and must never be collapsed into one score.

A dataset can have a documented quality rating while still carrying a statistical distribution. A highly uncertain input can also be well documented. Conversely, a precise-looking number can have poor representativeness or weak provenance.

Uncertainty families to represent separately

At minimum:

1. measurement uncertainty — uncertainty in measured activity data;
2. factor uncertainty — uncertainty/distribution in an emission or characterization factor;
3. representativeness uncertainty — temporal, geographical, technological and precision/quality limitations;
4. allocation uncertainty — uncertainty caused by alternative allocation rules or parameters;
5. scenario uncertainty — uncertainty over future states, EoL pathways, grid mix, technology scale-up, etc.;
6. model uncertainty — alternative valid methodological models;
7. structural/boundary uncertainty — excluded, unresolved or proxy processes.

Recommended calculation output

For uncertainty-enabled runs, ImpactCategoryResult should be capable of retaining:

central_estimate
mean?
median?
percentiles
confidence_or_credible_interval
sample_count
sampling_method
random_seed_or_replay_ref
distribution_refs[]
sensitivity_contributions[]
uncertainty_model_version

The exact statistical contract must be governed before implementation.

For deterministic inputs, the normal deterministic result remains valid. Monte Carlo should be activated when required by the method profile, assurance profile or decision context.

Replay consequence

Probabilistic calculations require explicit Replay Constitution treatment.

The likely model is:

• deterministic core calculation: EXACT replay;
• Monte Carlo distribution run with frozen PRNG algorithm/seed and frozen inputs: preferably EXACT replay where technically controlled;
• externally supplied stochastic/model output where exact recreation is not guaranteed: governed BANDED or RECORDED as appropriate.

Replay mode and tolerances must come from governed policy, never from local engine constants.

---

4.5. IEA 2026 emission-factor products

Weekly cohort: 2026-W36
Delta tags: FACTOR_DATA_DELTA, RIGHTS_DELTA, QUALITY_DELTA

The IEA 2026 factor products are useful because they distinguish direct electricity/heat emissions from upstream life-cycle factors, fuel-cycle factors and life-cycle transmission/distribution adjustments.⁵⁶

This is a direct warning against a simplistic country → kgCO2e/kWh lookup table.

Factor model implication

An electricity factor identity should be able to distinguish, among other dimensions:

provider
source_dataset
source_dataset_version
factor_family
factor_value
unit
impact_indicator
pollutant_or_gwp_basis
geography
spatial_resolution
temporal_resolution
valid_period
time_slice_or_series_ref?
technology_or_mix_context
market_or_location_context?
direct_generation_component?
upstream_component?
fuel_cycle_component?
transmission_distribution_component?
trade_adjustment_component?
loss_adjustment_component?
calculation_method_ref
quality_metadata
uncertainty_metadata
licence_ref
permitted_use_policy_ref
provenance_ref
checksum_or_source_hash

A factor may be one component of a lifecycle calculation rather than a complete lifecycle factor. ZAYAZ must prevent double counting when a method combines direct, upstream and grid-loss components.

Licensing is architecture

The IEA states that ordinary licences do not permit certain third-party/client carbon-footprint work or derived-product/service uses without a separate agreement.⁵⁶

For a multi-tenant SaaS platform, this means dataset_registry needs more than technical metadata.

It should be able to bind to rights objects describing:

licence identity
licence version
licence holder
permitted tenant scope
permitted user scope
permitted locations
internal-use permission
client-work permission
derived-data permission
publication permission
redistribution/display permission
attribution requirements
expiry / renewal
contract / agreement reference
usage logging requirements

Pergamum Pulse Core already defines Rights Record, Licence Record, Agreement Record, Publication Rights Record and related rights objects. PEF datasets should consume that rights architecture rather than adding ad hoc licence flags.

A computation must be capable of being technically valid but legally unusable for a particular output. ZAYAZ should detect that before the result is disclosed.

---

4.6. 2026-W35 — reconstructed previous weekly cohort

Weekly cohort: 2026-W35
Report date: 28 August 2026
Cohort state: reconstructed from authoritative public releases because the exact delivered automation message is not available to this authoring session.

This cohort is retained as the first example of how an earlier weekly brief is absorbed into the roadmap. It is not included merely as an archive: each retained item below creates a concrete architecture delta.

4.6.1. Comparative LCA of bio-based versus fossil-based products

Delta tags: METHOD_DELTA, QUALITY_DELTA, PRODUCT_STRATEGY_DELTA

Lagodzka, Sporchia and Pizzol identify recurring bias in comparative LCA where products are compared by mass or nominal category despite differences in technical function, durability, additional treatments and system requirements.²⁰

The key ZAYAZ implication is that comparability itself must be governed.

A product comparison should not be accepted merely because two products have footprints expressed in the same unit. ZAYAZ should be able to prove functional equivalence or explicitly model the compensatory processes required to make alternatives equivalent.

Recommended method-profile additions:

comparison_intent
comparison_basis_ref
functional_equivalence_requirements[]
performance_requirements[]
durability_basis
service_life_basis
compensatory_process_rules[]
comparative_system_boundary_rules
comparability_verification_profile_ref

Examples of compensatory processes include coatings, barriers, fire protection, added maintenance, different product quantities, replacement frequency or altered logistics needed for one option to deliver the same service as another.

Architecture delta: introduce a governed Comparability Receipt for comparative PEF/LCA and optimization results. LCA-OPTI and procurement comparisons should not rank alternatives until equivalence conditions are satisfied or the limitations are explicitly routed.

4.6.2. Monte Carlo PEF of alternative pasta systems

Delta tags: UNCERTAINTY_DELTA, METHOD_DELTA, PRODUCT_STRATEGY_DELTA

Moresi combines cradle-to-grave PEF with Monte Carlo simulation and demonstrates how packaging mass, cold-chain requirements, preparation energy, transport efficiency and the chosen comparison basis materially influence the result.²¹

The study is useful to ZAYAZ for two reasons.

First, it reinforces the uncertainty architecture already required by 2026-W36.

Second, it shows that a single functional unit may not be sufficient for product strategy. The paper evaluates the product by mass and also normalizes to an isocaloric serving to account for differences in product state and use.

Architecture delta: comparative product analysis should support governed functional-unit sensitivity without allowing analysts to cherry-pick the most favorable basis.

Conceptually:

primary_functional_unit
alternative_valid_functional_units[]
functional_equivalence_rules
results_by_basis[]
ranking_stability
basis_sensitivity_finding

The EPU Product Graph should also retain packaging, cold-chain, use-stage and preparation assumptions as first-class product-system contributors so eco-design recommendations remain traceable to the actual design change.

4.6.3. Spatio-temporal life-cycle carbon intensity for electrolytic hydrogen

Delta tags: FACTOR_DATA_DELTA, SCENARIO_DELTA, METHOD_DELTA, PERFORMANCE_DELTA

Gohil, Haque and Farid model hourly life-cycle electricity carbon intensity across Australian regions and use the time-varying signal to change electrolyzer operation.²²

This creates a major factor-resolution requirement:

Some emission factors are not scalar reference values. They are governed time-series signals.

ZAYAZ factor identity therefore needs to support:

spatial_resolution
temporal_resolution
observation_or_model_time
valid_time
time_zone
interval_start
interval_end
series_ref
aggregation_method_ref
missing_interval_policy_ref

A calculation using annual average electricity should be distinguishable from one using monthly, daily or hourly factors even if both originate from the same provider and geography.

Architecture delta: the Factor Resolver must be able to resolve a factor for a time interval, and a method profile must govern whether time-resolved factors are required, optional or prohibited for the intended assessment.

This also connects PEF/LCA to operational optimization. An EPU-related production process may have the same equipment and location but a materially different footprint depending on when electricity is consumed.

4.6.4. Product declarations + circularity metrics for recycled steel

Delta tags: PRODUCT_STRATEGY_DELTA, METHOD_DELTA, ASSURANCE_DELTA

Rumsa et al. show that EPD-aligned LCA and circularity indicators answer different but complementary questions. High recycled content and high circularity do not automatically guarantee the lowest environmental footprint, and end-of-life allocation can obscure important trade-offs.²³

The ZAYAZ consequence is that circularity should not be forced into the PEF score as an undocumented modifier.

Instead, EPU should support parallel governed result families:

Environmental footprint results
Circularity results
Resource-recovery results
Recycled-content claims
End-of-life assumptions
Assurance state

These can be displayed together, compared and interpreted together while retaining their own methods and provenance.

Architecture delta: product disclosure profiles should be capable of projecting an integrated sustainability view from one EPU without conflating methodologically distinct metrics. This strengthens Carbon Passport/DPP outputs and protects against a "circularity at any cost" interpretation.

4.6.5. EPLCA / LCDN EF model and developer tooling

Delta tags: INTEROPERABILITY_DELTA, FACTOR_DATA_DELTA, QUALITY_DELTA

The European Platform on Life Cycle Assessment exposes EF study resources and developer tooling around the extended-ILCD (eILCD) format, including XML schemas, life-cycle-model datasets, validation checks and tooling capable of aggregating models into EF-compliant datasets.²⁴

This is directly relevant to ZAYAZ ingestion architecture.

ZAYAZ should not convert every EF/ILCD source immediately into a lossy internal flat format and discard the native artifact.

Recommended dataset-ingestion metadata:

native_format
native_schema_version
native_artifact_hash
native_model_ref
aggregation_state
validation_profile_ref
validation_result_ref
nomenclature_profile_ref
mapping_profile_ref
normalized_projection_ref

Architecture delta: create a governed eILCD/ILCD adapter and validation boundary in the factor/dataset ingestion path. Native source files remain immutable evidence; normalized ZAYAZ projections are derived artifacts with explicit mapping/aggregation lineage.

This supports future interoperability with LCDN/EF datasets while preserving auditability and avoids embedding software-specific nomenclature into the canonical dataset identity.

---

4.7. 2026-W37 — reconstructed weekly cohort

Weekly cohort: 2026-W37
Report date: 11 September 2026
Cohort state: reconstructed from authoritative sources published or updated during 9–11 September 2026 because the exact Friday shortlist output is not available to this architecture-integration session.

The W37 review produces four accepted architecture deltas and one WATCH item whose implications are already covered by the current model.

4.7.1. GLAM human-health LCIA method

Authority: peer-reviewed methodological documentation of a UNEP Life Cycle Initiative consensus process; not an EU PEF normative method.
Delta tags: METHOD_DELTA, FACTOR_DATA_DELTA, UNCERTAINTY_DELTA, INTEROPERABILITY_DELTA

Fantke et al. document the human-health portion of the Global Life Cycle Impact Assessment Method (GLAM), including climate change, fine particulate matter, human toxicity, ionising radiation, work-environment impacts, water scarcity and lifestyle-related health pathways.⁷

The paper is architecturally important because one LCIA method can contain category-specific characterization-factor sets with materially different dimensions. Examples in GLAM include:

• multiple time horizons for climate-change damage;
• spatially differentiated outdoor PM effects;
• indoor versus outdoor pathways;
• near-field versus far-field toxicity exposure;
• midpoint and damage indicators;
• category-specific population/exposure semantics;
• differing uncertainty coverage and sensitivity recommendations.

The existing ZAYAZ roadmap already requires versioned LCIA methods. W37 makes the required internal boundary clearer:

An LCIA method must be represented as a governed package of category definitions, characterization-factor sets and applicability semantics; it cannot be reduced to one method code plus one undifferentiated factor table.

Architecture delta: define a governed LCIA Method Package contract family below the broad PEF/LCA Method Profile. The Method Profile selects an approved LCIA package; the package defines the category-specific factor sets and their compatibility semantics. External methods such as GLAM may be supported for analysis or future products without becoming PEF authority unless a governing PEF rule explicitly adopts them.

The package must be able to express conceptually:

method identity / version
impact categories[]
indicator level (midpoint / damage)
characterisation factor dataset refs[]
inventory-flow / stressor compatibility
compartment / exposure-pathway dimensions
population / receptor dimensions where applicable
spatial-resolution semantics
time-horizon semantics
primary vs sensitivity factor sets
uncertainty metadata / coverage
applicability / exclusion rules
normalisation / weighting compatibility
source / authority / rights / provenance

This also confirms that characterization factors are a distinct factor role and should never be selected through the same rules as activity/emission factors merely because both are numeric reference data.

4.7.2. V-model for LCA in product development

Authority: peer-reviewed research methodology; not a normative PEF requirement.
Delta tags: PRODUCT_STRATEGY_DELTA, QUALITY_DELTA, ASSURANCE_DELTA, PERFORMANCE_DELTA

Keller, Müller and Held propose scheduling LCA throughout product development so that environmental information arrives while designers still have meaningful degrees of freedom, rather than after the product has effectively been fixed.⁸

This aligns strongly with EPU versioning and the existing Data Escalation approach, but exposes one missing runtime concept: assessment maturity.

A footprint calculated from early requirements, generic datasets and provisional design assumptions is useful for eco-design, but it is not equivalent to a footprint calculated from a frozen BOM and verified primary evidence.

ZAYAZ therefore needs to distinguish:

early design screening
concept / architecture comparison
detailed design assessment
pre-production validation
production-state calculation
claim / disclosure-grade calculation

The labels above are illustrative, not canonical statuses.

Architecture delta: define a governed Progressive Assessment Context contract family that binds a calculation to the maturity of the product definition, the decision being supported, the evidence-completeness expectation, permitted proxy/inference policy, and refresh/recalculation triggers.

This is deliberately separate from PEF methodology. Product-development maturity describes what is known about the product and what the result may be used for; the Method Profile describes how the environmental calculation is performed.

TrustGate should therefore be able to accept a provisional LCA for an early design decision while refusing the same result for a customer claim or verified PEF disclosure.

4.7.3. IEA September emissions-factor package update

Authority: authoritative technical data product; contractual licence terms apply.
Delta tags: FACTOR_DATA_DELTA, QUALITY_DELTA, RIGHTS_DELTA, PERFORMANCE_DELTA

The IEA data-services schedule shows a September 2026 release on 11 September and describes the Emissions Factors Package as combining monthly and quarterly emission factors with annual Emissions Factors and Life Cycle Upstream Emission Factors products.⁹

W35 already established that factors can be time-resolved series. W37 exposes a different temporal dimension:

The period a factor describes is not the same thing as the provider release or dataset vintage from which ZAYAZ obtained it.

A provider may publish multiple vintages covering the same observation period as provisional values are revised, methodology changes or source data is corrected.

Architecture delta: factor/dataset governance must distinguish at least conceptually:

observation / applicability period
provider release / vintage
provider publication timestamp
ZAYAZ ingestion / capture timestamp
source artifact hash
revision / provisional / final state where supplied
supersession relationship

Replay must bind to the immutable captured snapshot actually used. A later provider release covering the same month or quarter creates a new governed dataset version and an impact-analysis candidate; it must never silently rewrite historical calculations.

This delta applies beyond IEA. It is a general rule for any frequently revised emissions-factor or lifecycle dataset.

4.7.4. Reference service life and replacement modelling

Authority: peer-reviewed research; ISO/EPD references within the paper may provide domain-specific normative definitions, but the paper itself does not create PEF authority.
Delta tags: METHOD_DELTA, UNCERTAINTY_DELTA, QUALITY_DELTA, PRODUCT_STRATEGY_DELTA

Sadeghi et al. show that reference-service-life assumptions for non-structural materials can materially change whole-building LCA results; in their cases, high replacement rates changed total results by roughly 19–37%, while different building lifetimes produced still larger changes.¹⁰

The current roadmap already considers service life when comparing alternatives. W37 establishes that this is too narrow.

For products where maintenance, repair or replacement occurs inside the study period, ZAYAZ needs to distinguish:

• evidence-backed declared/reference service life;
• context-specific modeled service life;
• maintenance and replacement schedule;
• reference study period / use-period assumption;
• uncertainty/distribution around those assumptions;
• resulting replacement quantities and lifecycle events.

Architecture delta: service-life and replacement assumptions become governed calculation/scenario inputs for applicable whole-life studies, not merely comparability annotations.

The EPU should preserve product evidence and lifecycle facts. A context-adjusted modeled service life belongs to the calculation/scenario layer and must not silently mutate authoritative product state.

The exact EPU ontology boundary — for example whether reference service life is represented through existing ProductSpecification / Claim / evidence semantics or requires another governed object — remains intentionally unresolved pending EPU review.

4.7.5. IEA LNG supply-chain emissions analysis

Authority: authoritative technical analysis; not a PEF normative method.
Delta tags: FACTOR_DATA_DELTA, QUALITY_DELTA, WATCH

The IEA's 10 September 2026 LNG analysis decomposes supply emissions across production/processing, pipeline transmission, liquefaction, shipping and regasification, and reports substantial variability across pathways.¹¹

This is exactly the kind of analysis ZAYAZ should ultimately be able to represent. However, it does not expose a new architecture gap.

The current roadmap and EPU Product Graph already require:

• process/activity-level lineage;
• logistics/route context;
• lifecycle-stage coverage;
• factor role and boundary metadata;
• factor-resolution receipts;
• dataset version/provenance;
• uncertainty/quality separation.

Integration decision: WATCH / no new canonical object or contract. Retain LNG pathway decomposition as a future validation fixture for the Factor Resolver and LCI Builder, particularly to test that a generic commodity-average factor is not selected when a method/context requires route- or facility-specific upstream data.

---

4.8. 2026-W38 — reconciled Friday cohort

Weekly cohort: 2026-W38
Friday report date: 18 September 2026
Cohort state: reconciled on 19 September 2026 against the exact Friday shortlist supplied after the initial Saturday architecture review.

The canonical Friday cohort contains four accepted architecture refinements, one WATCH/reference fixture, and one explicit NO_ACTION surveillance result. Two additional papers discovered during the Saturday review are retained separately as supplemental sources: one accepted architecture refinement and one WATCH fixture.

4.8.1. Government of Canada Fuel LCA Model — data-quality admission and pedigree uncertainty

Authority: government technical methodology used to support Canadian programmes and regulations; not an EU PEF normative method.
Delta tags: FACTOR_DATA_DELTA, QUALITY_DELTA, UNCERTAINTY_DELTA, METHOD_DELTA, ASSURANCE_DELTA

Environment and Climate Change Canada's September 2026 Fuel LCA Model defines explicit source-quality levels and excludes data that do not meet its lowest acceptable level. It separately evaluates five pedigree dimensions — reliability, completeness, temporal correlation, geographical correlation and technological correlation — and converts those assessments into uncertainty inputs used in Monte Carlo analysis.¹²

The important ZAYAZ consequence is not to copy Canada's thresholds or scores. It is the architectural separation between:

method / intended-use requirement
      ↓
minimum data-quality admission policy
      ↓
admissible candidates
      ↓
candidate quality / representativeness evaluation
      ↓
factor or dataset selection
      ↓
uncertainty propagation
      ↓
TrustGate / intended-use assessment

A factor or dataset can therefore be numerically compatible yet inadmissible because it falls below a governed minimum evidence/quality floor.

Where a methodology uses a pedigree/DQI approach, ZAYAZ should be able to preserve the dimension scores, mapping method and resulting uncertainty distribution without collapsing them into one opaque confidence score. The Canadian model's choice not to expose its development uncertainty results is also a useful contrast: ZAYAZ should preserve uncertainty outputs downstream where the governing disclosure/rights profile permits them.

The same methodology provides separate AR5 and AR6 GWP-100 LCIA methods and multiple allocation approaches. Those features reinforce — rather than replace — the existing LCIA Method Package and AllocationDecision architecture.

Architecture delta: strengthen Factor/Dataset Governance and Factor Resolution with a governed data-quality admission floor before candidate ranking. No Canadian threshold becomes ZAYAZ policy unless separately adopted through governance.

4.8.2. Battery-cell LCA: data aggregation and multifunctionality

Authority: peer-reviewed research conducted in the context of the EU Batteries Regulation and associated carbon-footprint standardisation work; not itself a legal or PEF normative requirement.
Delta tags: METHOD_DELTA, QUALITY_DELTA, PERFORMANCE_DELTA, PRODUCT_STRATEGY_DELTA, ASSURANCE_DELTA

Husmann et al. show that temporal aggregation of primary battery-production data can change climate-impact results by about ±10%, while the chosen multifunctionality treatment changes the case-study result by about 6%. Spatial aggregation may leave the overall result similar while changing hotspot identification materially.¹³

The resolution of activity data is part of the calculation evidence. It is not merely an ingestion detail.

W35 established temporal resolution for factors. W38 establishes the corresponding requirement for activity data itself.

For material activity inputs, ZAYAZ should be able to preserve conceptually:

source observation resolution
source temporal interval / cadence
source spatial / process granularity
measurement scope
aggregation method
aggregation window
calendar vs rolling window semantics
aggregation target resolution
missing-interval treatment
transformation / derivation lineage
information-loss finding
intended-use fitness

Where technically, contractually and economically permissible, the highest governed source granularity should be retained as evidence and coarser views should be derived from it rather than destructively replacing the source observations.

The paper also distinguishes data detail useful for engineering/optimisation from aggregation useful for reporting. That must not become a hard-coded monthly/hourly rule in ZAYAZ. Instead, the applicable Method Profile and intended-use/assessment context should determine the permitted or required resolution.

Likewise, the authors' recommendations concerning cut-off versus CFF and aggregation windows are research recommendations, not ZAYAZ policy. Allocation/multifunctionality continues to use the existing governed AllocationDecision and applicable authoritative method rules.

Architecture delta: retain the governed Activity Data Resolution & Aggregation contract family and make activity-data resolution part of run lineage, assurance and replay.

4.8.3. Chemical LCA: generated inventory data and uncertainty

Authority: peer-reviewed methodological review; not a normative PEF requirement.
Delta tags: QUALITY_DELTA, UNCERTAINTY_DELTA, PRODUCT_STRATEGY_DELTA, ASSURANCE_DELTA, SUPPLIER_DATA_DELTA

Köck et al. review 31 methods used to generate missing chemical LCI data or predict LCIA results, including knowledge engineering/data mining, process simulation, predictive modelling and computer-aided molecular design.¹⁴

The critical architecture point is that generated data must retain how it was generated.

ZAYAZ should distinguish at least conceptually between:

measured / observed data
reported primary data
authoritative database data
literature / mined data
process-simulation output
engineering estimate
proxy / analogue data
predictive model output
scenario-derived data

These labels are illustrative until governed; they are not a universal best-to-worst ranking. Eligibility depends on the method, intended use, applicability and available evidence.

For derived or predicted environmental evidence, lineage should preserve:

generation method / method family
model / tool / algorithm version
source / reference / training data refs
technology or manufacturing maturity
geographical applicability
temporal applicability
technological applicability
output scope: LCI vs direct LCIA result
parameter uncertainty
model uncertainty / estimation error
validation evidence
reproducibility artifact / executable method reference where available
replacement / refresh trigger

A particularly important boundary follows from the review: some predictive methods provide LCIA results but no LCI. Such an output may support early screening, but it must never satisfy a contract requiring process inventory or elementary flows.

Architecture delta: retain the governed Derived Inventory Evidence contract family. Progressive Assessment Context and TrustGate determine when derived evidence is acceptable, while Data Escalation should prioritize replacing high-materiality derived/proxy evidence when better primary/process data would materially improve the decision.

4.8.4. Auto-LCA: dependency-bounded incremental recalculation

Authority: peer-reviewed research architecture; not a PEF normative method or regulatory requirement.
Delta tags: PERFORMANCE_DELTA, INTEROPERABILITY_DELTA, SUPPLIER_DATA_DELTA, QUALITY_DELTA, ASSURANCE_DELTA, PRODUCT_STRATEGY_DELTA

Guo and Wang propose Auto-LCA, combining automated supply-chain acquisition, multilingual NLP, a structured product-carbon model and machine-learning completion of missing LCI parameters with provenance/confidence tags. The architecture propagates version-controlled carbon metadata across supply-chain tiers and performs update-driven recomputation of affected graph nodes rather than rebuilding the complete footprint after every change.¹⁵

Inferred or machine-generated LCI values fit the Derived Inventory Evidence model already accepted from Köck et al. They remain lower-authority evidence until the applicable policy and evidence state justify stronger use. A reported benchmark accuracy from one research paper does not change that assurance boundary.

More importantly, the paper strengthens an existing Roadmap 6 idea into a first-class implementation requirement:

A governed input change should invalidate and recalculate the dependent footprint subgraph — no more and no less — while preserving proof of why unaffected artifacts were reusable.

governed change event
      ↓
dependency traversal
      ↓
affected calculation/result artifacts
      ↓
invalidation + reuse plan
      ↓
bounded recomputation
      ↓
new result/version lineage
      ↓
material delta + assurance refresh

A factor, supplier contribution, BOM element, method profile or evidence replacement can have different dependency scopes. A method-version change may invalidate a much wider graph than one supplier activity update.

The paper's transferable “carbon header” concept does not justify a new ZAYAZ product identity or disclosure object: EPU, FootprintResult, disclosure projections, Carbon Passport/DPP and exchange contracts already provide the governed product/output boundary.

Architecture delta: elevate Dependency Impact & Incremental Recalculation from a portfolio-scale roadmap bullet into a bounded Hecate Need, replay requirement and cross-cutting acceptance criterion.

4.8.5. Chinese aquaculture N₂O dataset — multidimensional factor-resolution fixture

Authority: technical LCA dataset, version 3, published under CC BY 4.0; not a normative methodology.
Delta tags: FACTOR_DATA_DELTA, QUALITY_DELTA, INTEROPERABILITY_DELTA, RIGHTS_DELTA, WATCH

Zhang et al.'s dataset combines species-specific emission factors, provincial production data and cradle-to-grave lifecycle stages across 1980–2022, with mitigation scenarios and attached reproduction code.¹⁶

This is a strong stress test for the factor/dataset architecture because a valid lookup may depend simultaneously on:

species / process or product context
geography
lifecycle stage
reference year / time
scenario or pathway
source dataset version
factor role
unit / impact basis

However, the current Factor/Dataset model already requires process/technology context, geography, temporal semantics, lifecycle coverage, version/vintage, scenario lineage and provenance. ZAYAZ should not add a universal species column merely because one dataset uses species as a key; the resolver should map domain-specific classification dimensions through governed dataset semantics.

The attached reproduction code is also useful validation evidence. Where a dataset publishes executable transformation/reproduction logic, ZAYAZ should be able to retain a reference/hash and use it in adapter/reference-vector validation without treating external code as runtime authority.

Integration decision: WATCH / retain as a multidimensional Factor Resolver + adapter + rights/reproducibility fixture. No new canonical object is justified.

4.8.6. Saturday supplemental — process-based inventory for Portland clinker substitutes

Authority: peer-reviewed research discovered during the Saturday architecture review; not part of the primary Friday shortlist and not normative authority.
Delta tags: FACTOR_DATA_DELTA, QUALITY_DELTA, INTEROPERABILITY_DELTA, ASSURANCE_DELTA, PRODUCT_STRATEGY_DELTA

Edwards et al. assemble 36 inventory sets and disaggregate them into 57 unit-process datasets. They show why pre-aggregated emission factors are less transparent and flexible for contribution analysis, background-scenario testing and multi-impact assessment, and highlight poor temporal representativeness and incomplete foreground elementary flows in many source datasets.¹⁸

Dataset eligibility depends on whether its representation is fit for the requested analysis, not merely whether its numeric value and unit are compatible.

A pre-aggregated factor may be suitable for screening or a permitted reporting use while being unsuitable for process optimisation, hotspot attribution, background-scenario substitution or an LCIA requiring elementary flows.

Architecture delta: retain the governed Inventory Dataset Fitness Assessment accepted during the initial W38 Saturday review.

4.8.7. Saturday supplemental — prospective agrivoltaics

Authority: peer-reviewed research discovered during the Saturday architecture review; not part of the primary Friday shortlist and not a normative PEF requirement.
Delta tags: SCENARIO_DELTA, UNCERTAINTY_DELTA, PRODUCT_STRATEGY_DELTA, WATCH

Jouannais et al. perform spatially explicit prospective consequential LCA for agrivoltaics under different deployment logics and changing climate, crop, electricity and economic conditions.¹⁹

This remains an excellent stress test for the W36/W37 scenario architecture, but it does not expose a missing constitutional boundary.

Integration decision: WATCH / retain as a future prospective-scenario validation fixture.

4.8.8. EU EF normalisation / weighting surveillance

Authority: European Commission / JRC source surveillance.
Delta tags: NO_ACTION

The Friday brief explicitly checked for a new authoritative Environmental Footprint normalisation or weighting release during the W38 window. No new package was identified; the JRC/EPLCA Environmental Footprint page remained last updated on 7 July 2026.¹⁷

Integration decision: NO_ACTION. Preserve the existing governed EF method/version baseline; do not manufacture a normalization/weighting change where no authoritative release exists.

4.8.9. Practitioner supplement — PCRs as production infrastructure

Source type: experienced practitioner analysis / production insight; not normative authority.
Delta tags: METHOD_DELTA, ASSURANCE_DELTA, INTEROPERABILITY_DELTA, PERFORMANCE_DELTA, PRODUCT_STRATEGY_DELTA

A September 2026 Lifecycle Brief article by an EPD practitioner argues from production experience that PCRs are not merely documents referenced after modelling; they are reusable infrastructure that determines which assessment is being produced in the first place.²⁵

The practitioner describes the applicable rule landscape as a stack rather than a simple hierarchy. Depending on the product and programme, the applicable assessment can draw from:

• ISO framework rules;
• EN/core rules;
• complementary PCRs / product-group rules;
• programme-operator instructions and interpretations;
• harmonisation rules such as ECO Platform requirements;
• applicable legislation;
• product-specific defaults or stricter requirements.

The important architecture insight is that the effective rules for one product/programme/date may need to be assembled and resolved, rather than looked up through one category_rule_ref.

The article also highlights that rule selection can involve governed judgement. More than one PCR may be defensibly applicable, programme adoption can determine whether a complementary rule binds, and verifiers may need to review the selected rule basis and whether its defaults actually fit the product.

Architecture delta: introduce a governed Rule Stack Resolution capability and a Category Rule Resolution Receipt / Rule Stack Manifest contract family. This capability resolves the applicable rules before the Method Profile is frozen.

Conceptually:

product + intended declaration / use
        ↓
jurisdiction / programme context
        ↓
candidate rule sources
        ↓
applicability findings
        ↓
adoption / effective-date findings
        ↓
precedence / override / stricter-rule findings
        ↓
human judgement where rules leave valid choice
        ↓
resolved rule stack
        ↓
Method Profile
        ↓
calculation / verification / disclosure

This does not make practitioner interpretation normative. The actual rule contents, applicability, precedence and effective dates must come from authoritative sources captured and governed through Pergamum Pulse or another approved registry/projection path.

The practitioner insight also strengthens two existing ZAYAZ ideas:

1. Comparability is rule-stack-sensitive. Two declarations may share a broad methodology family while differing materially because the programme/PCR stack fixes different units, service-life assumptions, scenarios, boundaries or defaults.
2. Standardisation enables scalable automation. Once a resolved rule stack is governed and reusable, many products can reuse that infrastructure. A later rule change can then use dependency-bounded impact analysis to identify exactly which Method Profiles, calculations, verifications and disclosures require refresh.

Integration decision: accepted as a practitioner-derived architecture refinement. It is recorded separately from peer-reviewed, government and normative sources so source authority remains explicit.

4.9. 2026-W39 architecture integration — reconciled 10 October 2026

This cohort was supplied as an earlier Friday Research Intake and is reconciled here without replacing its ISO tag or source set. External research remains evidence, not ZAYAZ policy.

4.9.1. IEA Life Cycle Upstream Emissions Factors 2026

Authority: official technical dataset release; not a normative PEF method.
Delta tags: FACTOR_DATA_DELTA, RIGHTS_DELTA, INTEROPERABILITY_DELTA

The release distinguishes total upstream, fuel-cycle and transmission/distribution-loss adjustment factors.²⁶ Treating those values as interchangeable would create boundary overlap and double counting.

Integration decision: accepted. Factor/Dataset metadata and resolver evidence must identify factor scope, included/excluded stages and composition/decomposition relationships. Rights eligibility remains use- and output-specific; availability does not imply SaaS redistribution permission.

4.9.2. GLAM ecosystem-quality method

Authority: peer-reviewed method research; not normative PEF authority.
Delta tags: METHOD_DELTA, INTEROPERABILITY_DELTA, UNCERTAINTY_DELTA

The ecosystem-quality method exposes category, geography, realm and aggregation semantics that cannot safely be reduced to an unlabeled factor column.²⁷

Integration decision: accepted as an LCIA Method Package refinement. Packages must preserve indicator level, area-of-protection/safeguard subject, realm, spatial basis and aggregation/value-choice metadata.

4.9.3. Consensus resource-use framework

Authority: peer-reviewed method research; not normative PEF authority.
Delta tags: METHOD_DELTA, PRODUCT_STRATEGY_DELTA, WATCH

The resource-use framework makes explicit that average versus marginal perspectives and selected safeguard subjects are methodological choices.²⁸

Integration decision: accepted as method-package metadata and retained as WATCH for a future non-PEF validation fixture. It does not change the governed EF baseline.

4.9.4. Allocation variability in crop-processing co-products

Authority: peer-reviewed research; not normative authority.
Delta tags: METHOD_DELTA, UNCERTAINTY_DELTA

Cross-method allocation variation can exceed modeled parameter variation.²⁹ A Monte Carlo interval over one frozen allocation method does not represent uncertainty about the allocation choice itself.

Integration decision: accepted. Parameter, data, model, allocation/method-choice and scenario uncertainty must remain separately attributable; alternative governed allocation choices require separate runs or hypotheses.

4.9.5. Natural-language scenario editing for parameterised LCA

Authority: peer-reviewed software/method research; not normative authority.
Delta tags: ASSURANCE_DELTA, INTEROPERABILITY_DELTA, WATCH

The research keeps language-model assistance at the proposal layer and uses structured, deterministic validation and execution.³⁰

Integration decision: WATCH / validation fixture. This supports the existing constitutional boundary: schema-valid execution does not prove methodological correctness, and language models do not become method authority.

4.10. 2026-W40 architecture integration — reconciled 10 October 2026

This cohort was supplied as an earlier Friday Research Intake and is reconciled against the current roadmap and open pull requests. No overlapping PEF/LCA roadmap pull request was found.

4.10.1. French textile environmental-cost transition

Authority: national legal authority and official methodology context.
Delta tags: METHOD_DELTA, ASSURANCE_DELTA, INTEROPERABILITY_DELTA

French Environmental Code provisions attached transitional conditions to who could calculate or communicate textile environmental cost until 1 October 2026.³¹ The same numerical method may therefore have different valid execution or publication conditions across jurisdiction, claimant role, product scope and effective date.

Integration decision: accepted. Method and Disclosure Profiles must bind jurisdiction, legal authority, effective date, claimant/actor eligibility and publication context. These fields select governed rules; this roadmap does not encode French law itself.

4.10.2. Uncertainty-information interoperability

Authority: peer-reviewed technical analysis.
Delta tags: UNCERTAINTY_DELTA, INTEROPERABILITY_DELTA, QUALITY_DELTA

The analysis identifies ambiguity and contradictory documentation around lognormal parameterization across common LCI exchange formats.³²

Integration decision: accepted. ZAYAZ must preserve mathematical distribution semantics independently of source serialization, record the source field interpretation and transformation, and reject or route ambiguous/lossy mappings instead of silently guessing.

4.10.3. Finnish Food-LCA guidance development

Authority: peer-reviewed account of national technical guidance; not EU PEF normative authority.
Delta tags: METHOD_DELTA, INTEROPERABILITY_DELTA, WATCH

The work demonstrates a jurisdiction- and sector-specific rule set that intentionally differs from some PEF choices.³³

Integration decision: WATCH as a Rule Stack Resolution fixture. A regional method must not silently modify the PEF baseline; it needs its own governed authority, applicability and precedence evidence.

4.10.4. Firm-level supplier resolution and Scope 3 bias

Authority: peer-reviewed research; not normative PEF authority.
Delta tags: SUPPLIER_DATA_DELTA, QUALITY_DELTA, PRODUCT_STRATEGY_DELTA

Firm-, sector- and region-level aggregation can create systematic Scope 3 bias.³⁴

Integration decision: accepted as supporting evidence for the existing Data Escalation Planner, activity-resolution lineage and supplier-specific acquisition path. It does not justify a universal rule that finer data is always better; intended use and materiality still govern escalation.

4.10.5. PRIMAP-hist v2.8

Authority: official dataset release.
Delta tags: FACTOR_DATA_DELTA, RIGHTS_DELTA, WATCH

PRIMAP-hist v2.8 adds a new release/vintage with stated dataset variants and licensing conditions.³⁵

Integration decision: WATCH / adapter and rights fixture. Existing snapshot, checksum, supersession and rights architecture already covers the release. Dataset edition and licence variant must be pinned; no new canonical object is required.

4.11. 2026-W41 primary Friday Research Intake — integrated 10 October 2026

This is the primary handoff for this Saturday cycle. The exact 2026-W41 tag and source set are retained.

4.11.1. Direct product material-footprint calculation with ecoinvent

Authority: peer-reviewed research; not normative PEF authority.
Delta tags: FACTOR_DATA_DELTA, QUALITY_DELTA, INTEROPERABILITY_DELTA

The study finds the database usable for Raw Material Input under its method while missing unused-extraction information needed for Total Material Requirement.³⁶

Integration decision: accepted. Inventory Dataset Fitness must be evaluated for the requested indicator and its required flow set; success for one indicator cannot be generalized to another.

4.11.2. Process-level green manufacturing for chassis rails

Authority: peer-reviewed research using primary shop-floor data; not normative authority.
Delta tags: SUPPLIER_DATA_DELTA, PRODUCT_STRATEGY_DELTA, NO_ACTION

The study shows upstream steel dominance while retaining actionable manufacturing-process hotspots under EF and ReCiPe methods.³⁷

Integration decision: NO_ACTION on architecture. Retain as a golden-product validation fixture for contribution analysis, supplier escalation and method-package separation.

4.11.3. Proprietary phase-change material represented by proxy scenarios

Authority: peer-reviewed research; not normative authority.
Delta tags: UNCERTAINTY_DELTA, SCENARIO_DELTA, ASSURANCE_DELTA

Because a commercial material inventory was unavailable, the study evaluates several feedstock proxies rather than presenting one as truth.³⁸

Integration decision: accepted. Derived Inventory Evidence must preserve competing proxy hypotheses, selection rationale and result sensitivity. A representative estimate, if required, remains explicitly derived and cannot erase the alternatives.

4.11.4. Comparative LCA of additive construction

Authority: peer-reviewed systematic review; not normative authority.
Delta tags: METHOD_DELTA, ASSURANCE_DELTA, NO_ACTION

The review reinforces that functional unit, boundary and scenario choices can reverse comparative conclusions.³⁹

Integration decision: NO_ACTION on architecture. Existing Comparability Receipt, functional-unit sensitivity and rule-stack controls cover the finding; retain it as a negative-test source.

4.11.5. Carbon Footprint Radar 2026

Authority: industry survey and partner reporting; emerging product-strategy signal, not method authority.
Delta tags: SUPPLIER_DATA_DELTA, ASSURANCE_DELTA, PRODUCT_STRATEGY_DELTA, WATCH

The published partner pages report different response bases (507 analysed responses versus 556 companies surveyed), while both emphasize continuing Scope 3, product-footprint and verification gaps.⁴⁰

Integration decision: WATCH. Preserve publisher/version/provenance when using adoption evidence; do not convert survey percentages into architecture requirements. The signal supports supplier-data and assurance prioritisation already in the roadmap.

4.12. 2026-W42 primary Friday Research Intake — integrated 17 October 2026

This section preserves the exact 2026-W42 cohort and five-source handoff. The source types are kept distinct: official technical distribution material, peer-reviewed research, conference research and a versioned open dataset. None creates new normative PEF authority, and no new EF normalisation or weighting package was identified in the intake window.

4.12.1. Worldsteel datasets distributed through openLCA Nexus

Authority: official technical distribution update and source-provider dataset material; not normative method authority.
Delta tags: FACTOR_DATA_DELTA, INTEROPERABILITY_DELTA, QUALITY_DELTA, RIGHTS_DELTA, ASSURANCE_DELTA

The worldsteel 2026 source inventory was released in May from 2024 production data. The W42 development is a separate openLCA Nexus distribution in which the inventory was mapped to the openLCA reference system.⁴¹

A successful import proves neither semantic equivalence nor result parity. The source inventory identity, distribution/package identity, reference-flow mapping, normalized projection and conformance evidence must remain distinguishable.

Integration decision: accepted. Extend dataset/interoperability contracts with source-inventory identity, distribution representation/version, mapping manifest and reference-result conformance. Availability through Nexus does not establish unrestricted SaaS, derived-output or redistribution rights; no automatic ingestion is authorized.

4.12.2. Consequential agricultural LCA review

Authority: peer-reviewed critical review; research evidence, not normative PEF authority.
Delta tags: METHOD_DELTA, FACTOR_DATA_DELTA, SCENARIO_DELTA, UNCERTAINTY_DELTA, QUALITY_DELTA

The review confirms that attributional and consequential LCA answer different questions and use different inventory logic. Consequential studies depend on marginal suppliers, affected processes, temporal scope, market responses and wider structural uncertainty; the reviewed literature shows material documentation and uncertainty gaps.⁴²

Integration decision: accepted. The Method Profile must declare the inventory-modelling principle and purpose. Marginal-supplier or affected-technology resolution is modeled scenario/method evidence, never an observed supplier relationship. Consequential inventories cannot silently enter a PEF run whose governed method requires attributional accounting, and results from the two principles are not directly comparable without an explicit governed basis.

4.12.3. Multiple future lifecycles of steel and AAC structures

Authority: peer-reviewed original research; not normative authority.
Delta tags: SCENARIO_DELTA, METHOD_DELTA, FACTOR_DATA_DELTA, UNCERTAINTY_DELTA, ASSURANCE_DELTA, PRODUCT_STRATEGY_DELTA

The prospective consequential study shows that future recycling or recovery credits depend on future background systems and substitution assumptions. It also highlights recovered-material quality and the risk that present-day credits become invalid across later lifecycles.⁴³

Integration decision: accepted. Prospective circular transitions must bind recovered quantity and quality, feasible next use, scenario year, displaced process/technology, substitution ratio and governing allocation method. Gross burdens, avoided impacts and net results remain separately visible, and an avoided-impact benefit cannot be claimed more than once across linked product or organisational boundaries.

4.12.4. Automated BIM–LCA design workflow

Authority: conference research paper; not normative authority.
Delta tags: INTEROPERABILITY_DELTA, PRODUCT_STRATEGY_DELTA, PERFORMANCE_DELTA, RIGHTS_DELTA, NO_ACTION

The workflow embeds lifecycle results in BIM design objects and validates automated calculations against reference spreadsheets.⁴⁴

Integration decision: NO_ACTION on core architecture. EPU external identities/product configuration, governed CalculationRun lineage, MICE execution provenance, Replay and rights-aware disclosure already provide the required separation between a design object and calculation authority. Retain the paper as an external-design-object binding, recalculation and performance fixture; do not create a BIM-specific core engine.

4.12.5. End-of-life tyre system-boundary consistency dataset v2

Authority: versioned open research dataset under CC BY 4.0; not normative authority or factor data.
Delta tags: QUALITY_DELTA, METHOD_DELTA, ASSURANCE_DELTA, INTEROPERABILITY_DELTA, WATCH

The dataset distinguishes declared boundaries from effectively modeled boundaries, preserves missing information as not reported or not applicable, and applies its System Boundary Consistency Index to comparative studies.⁴⁵

Integration decision: accepted as a comparability and assurance refinement and retained as WATCH for conformance fixtures. ZAYAZ must preserve declared boundary, modeled coverage, coverage evidence and missing-process states. It does not adopt SBCI as an authoritative threshold, and the dataset is not admitted to the Factor Registry.

4.12.6. Canonical-spec review scope

The accepted refinements require focused review—not casual rewriting—of:

• EPU ProductSpecification, ActivityData, external identity, lifecycle-event, CalculationRun, ScenarioResult, evidence and claim boundaries;
• MICE/Computation Hub method, dataset, deterministic execution and result-lineage contracts;
• Dataset Registry, Factor Resolver and ILCD/eILCD adapter projection semantics;
• Pergamum Pulse governed authority/version/effective-time projections for methods, mapping packages and rights;
• TrustGate intended-use, comparison, avoided-impact and disclosure gates;
• Replay manifests for method principle, mapping version, scenario assumptions and boundary coverage;
• SSSR/USO/ZAR only after canonical fields/signals and lineage bindings are governed;
• Kernel/binding/policy review against the registered KISMET framework and contract specification; this roadmap grants no runtime authority.

---

4.13. 2026-W43 primary Friday Research Intake — integrated 24 October 2026

This section preserves the exact 2026-W43 cohort and five-source handoff. All five records are peer-reviewed research. The linked PEFDPP ontology artifact is a versioned research dataset/software package. None creates normative PEF, DPP or ZAYAZ authority. The JRC surveillance check identified no new EF normalisation or weighting package; EF 3.1 remains the referenced package.

4.13.1. PEFDPP ontology for PEF/DPP evidence exchange

Authority: peer-reviewed ontology research plus a versioned research artifact; not normative PEF or DPP authority.
Delta tags: INTEROPERABILITY_DELTA, ASSURANCE_DELTA, METHOD_DELTA, PRODUCT_STRATEGY_DELTA, RIGHTS_DELTA

The paper proposes a machine-readable OWL 2 DL representation for PEF inventories, modelling assumptions, data quality, Circular Footprint Formula parameters and results in a Digital Product Passport context.⁴⁶ The linked artifact includes an ontology, battery case, construction script and EF 3.1 results. The ontology/data are CC BY 4.0 and the code is MIT, while reproduction still requires separately licensed ecoinvent 3.12 data.

The research demonstrates representation, not automatic completeness or methodological validity. Its open-world semantics mean absence is not itself an invalidity finding, and the publication does not implement the closed validation profile needed to prove that an exchanged evidence package is complete for a governed use. Conceptual mappings to neighbouring DPP ontologies also do not establish semantic equivalence.

Integration decision: accepted. ZAYAZ must distinguish five claims: a result is machine-readable; its evidence package is complete for a declared profile; the calculation is reproducible under pinned dependencies and rights; the result is methodologically admissible; and it is independently verified. External ontology instances require a versioned mapping manifest, semantic-loss findings, deterministic profile validation and canonical-identity resolution. They cannot mint duplicate EPU, method, dataset, result or assurance identities.

4.13.2. Rebound effects in food-system LCA

Authority: peer-reviewed methodological research; not normative authority.
Delta tags: SCENARIO_DELTA, UNCERTAINTY_DELTA, METHOD_DELTA, ASSURANCE_DELTA

The practitioner survey identifies asymmetric treatment of consequential response mechanisms: substitution assumptions are routinely modeled while behavioural and market rebound effects are often omitted because evidence, guidance or modelling capacity is weak.⁴⁷

Integration decision: accepted as a scenario-completeness and uncertainty-symmetry refinement. A consequential scenario must inventory material displacement, behavioural, market and other response mechanisms as included, excluded, immaterial or unresolved; retain the evidence and materiality rationale; and expose important omissions. ZAYAZ does not require unsupported quantification, invent probability distributions or convert the paper into a PEF rule. Attributional PEF reporting remains isolated from consequential decision modelling.

4.13.3. Remanufactured electrical and electronic equipment

Authority: peer-reviewed systematic review; not normative authority.
Delta tags: METHOD_DELTA, ASSURANCE_DELTA, SCENARIO_DELTA, QUALITY_DELTA, SUPPLIER_DATA_DELTA, NO_ACTION

The review finds that use-phase omission, functional-lifespan assumptions and incomplete lifecycle coverage can undermine comparisons between remanufactured and new electrical/electronic equipment.⁴⁸

Integration decision: NO_ACTION on core architecture. The existing Comparability Receipt, functional-equivalence, service-life/replacement and declared-versus-modeled boundary requirements already cover the demonstrated gap. Retain the source as a remanufacturing fixture using remaining useful life, operating efficiency, replacement assumptions and equivalent service; missing use-phase evidence cannot be converted to not-applicable by convention.

4.13.4. Automotive DPP data priorities

Authority: peer-reviewed stakeholder research; not normative DPP authority.
Delta tags: SUPPLIER_DATA_DELTA, INTEROPERABILITY_DELTA, PRODUCT_STRATEGY_DELTA, QUALITY_DELTA, WATCH

The automotive vehicle-body case supports purpose-, product- and actor-sensitive DPP data priorities rather than one undifferentiated request set.⁴⁹ Its qualitative interview evidence is not publicly reproducible and its observed priorities are not universal mandatory fields.

Integration decision: WATCH / product-strategy fixture. Progressive Assessment Context, intended-use fitness, Data Authority Resolution, the Data Escalation Planner and No Ask Before Reuse already provide the architectural basis. A governed profile may vary required evidence by product category, lifecycle activity, actor role and intended use; AI or one sector study cannot infer or weaken the method-required evidence set.

4.13.5. Environmental and mechanical assessment of recycled concrete

Authority: peer-reviewed original research; not normative authority.
Delta tags: METHOD_DELTA, QUALITY_DELTA, SCENARIO_DELTA, PRODUCT_STRATEGY_DELTA, NO_ACTION

The study demonstrates that environmental impact and technical suitability are separate result families: a lower-impact material option may fail the required mechanical performance.⁵⁰

Integration decision: NO_ACTION on core architecture. Existing performance requirements, functional-equivalence findings and product-system compensation in the Comparability Receipt already require technical suitability before a comparative recommendation. Retain the concrete cases as fixtures. The paper-specific environmental-mechanical balance index is not adopted as EF normalisation, weighting or a ZAYAZ decision score.

4.13.6. Canonical-spec review scope

The accepted W43 refinements require focused review—not casual rewriting—of:

• EPU product/evidence/calculation/disclosure objects and external-identity mappings;
• EPU disclosure/DPP projection and supplier-data request fitness;
• MICE/Computation Hub run inputs, dependency pinning, deterministic result reproduction and exchange-package generation;
• Dataset Registry and Factor Resolver rights-preserving dependency manifests;
• Pergamum Pulse source, version, authority, licence and external-vocabulary projections;
• TrustGate completeness-profile validation, method-admissibility, verification and disclosure decisions;
• Replay manifests for the exact evidence package, mapping profile, dependencies, runtime and output hashes;
• SSSR/USO/ZAR only after governed exchange/result/finding signals and artifact bindings are admitted;
• The registered KISMET framework and contract specification define the kernel review boundary; this roadmap grants no runtime authority.

5. Normative PEF baseline that governs the roadmap

Research papers inform implementation, but research papers do not govern PEF.

The governing method baseline remains Commission Recommendation (EU) 2021/2279 and applicable valid PEFCR/OEFSR rules.⁵¹

The 2026 Commission transitional guidance on limited availability of EF-compliant datasets is especially important for factor resolution.⁵²

5.1. Secondary-dataset fallback policy

Where the transitional guidance applies and no valid PEFCR/OEFSR provides its own rules, ZAYAZ should model the Commission hierarchy as a governed policy rather than hard-coded branching:

1. EF-compliant secondary dataset available?
      YES → use according to applicable method rules
      NO
      ↓
2. ILCD-EL-compliant dataset available?
      YES → use; prefer one process-based database; record any database mixing
      NO
      ↓
3. no suitable dataset
      → omit according to the transitional guidance
      → record the missing process and material limitation
      → enforce required report disclosure / disclaimer policy

This is a secondary-data fallback hierarchy. It does not eliminate PEF primary-data requirements, Data Needs Matrix requirements or PEFCR-specific requirements.

5.2. Method version coexistence

ZAYAZ must never build EF 3.1 assumptions into table names or permanent field semantics.

The system should support:

method_profile = EF 3.1
method_profile = future EF method version
method_profile = valid historical PEFCR version
method_profile = revised PEFCR version

Historical results remain bound to the original profile. A method update creates a new calculation run; it never mutates the historical result.

5.3. Research methods versus PEF authority

ZAYAZ may support non-PEF LCIA methods or research methodologies for internal analysis, scenario work, product development or sensitivity testing.

Their availability in the platform must not imply that they are valid for a PEF claim.

The Method Profile and intended-use policy must therefore be capable of distinguishing:

supported method
PEF-authorised method for this profile
sensitivity-only method
research / experimental method
historical method

Exact status values must be governed rather than inferred from the examples above.

The same rule applies to research recommendations on activity-data aggregation, allocation, cut-off/CFF treatment or data-generation methods. They may trigger architecture review, fixtures or policy proposals; they do not automatically become runtime policy.

5.4. W38 authority review

The W38 cohort did not identify a verified new EU PEF normative requirement that supersedes the baseline above.

The Canadian Fuel LCA Model is authoritative for its own applicable Canadian programme/regulatory contexts and is valuable as a technical reference, but it does not govern EU PEF calculations.¹²

---

6. Target architecture

6.1. Layer 1 — governed knowledge and policy

Primary responsibility: define what the calculation is allowed to mean.

Inputs include:

• EU PEF Recommendation;
• PEFCRs / OEFSRs;
• EF method updates;
• Commission guidance;
• ISO or sector methods where supported;
• LCIA method documentation and characterization-factor releases;
• dataset methodology documentation;
• activity-data aggregation / quality requirements where governed;
• verification requirements;
• internal approved policies.

Pergamum Pulse should ingest and preserve these as governed knowledge with exact source fragments and effective/version semantics.

Operational registries then receive approved projections; runtime never scrapes a document at calculation time and treats extracted text as policy.

6.2. Layer 2 — method and data governance

This layer should contain governed contracts for:

• method profiles;
• category-rule profiles;
• LCIA Method Packages and category-specific characterization-factor sets;
• functional-unit rules;
• functional-equivalence and comparative-assessment rules;
• compensatory-process rules for product alternatives;
• system-boundary rules;
• allocation rules;
• recycling / EoL rules;
• electricity-model rules;
• temporal-factor resolution rules;
• activity-data resolution and aggregation rules;
• derived/proxy data-generation and applicability rules;
• inventory-dataset representation / fitness rules;
• LCIA method versions;
• normalization factors;
• weighting factors;
• dataset requirements;
• dataset release / vintage / snapshot semantics;
• factor-resolution rules;
• uncertainty profiles;
• progressive-assessment / maturity contexts;
• service-life / replacement assumptions where applicable;
• verification profiles;
• dataset rights / entitlement;
• ILCD/eILCD import and validation profiles.

6.3. Layer 3 — product system and evidence

EPU Product Graph provides the product-system state:

EPU
├── ProductDefinitionVersion
├── ProductSpecification / claims / evidence
├── CompositionVersion
│   ├── components
│   ├── materials
│   └── substances
├── production context
│   ├── facility
│   ├── manufacturing processes
│   └── activity data
│       ├── source / evidence
│       ├── observation resolution
│       └── derivation / aggregation lineage where applicable
├── supplier contributions
├── logistics / transport legs
├── packaging
├── use-stage context
├── lifecycle / maintenance / repair evidence
├── lifecycle / end-of-life context
└── evidence

Every calculation run binds to the exact graph state/effective-time view used.

Evidence-backed product characteristics such as declared/reference service life must remain distinguishable from context-specific modeled service-life assumptions used by a particular calculation or scenario.

Measured, reported, estimated, proxy and model-derived activity evidence must likewise remain distinguishable.

6.4. Layer 4 — deterministic LCI and LCIA computation

The computation layer should be decomposable into bounded responsibilities:

Goal & Scope validation
      ↓
Assessment maturity / intended-use context
      ↓
Comparability / functional-equivalence validation where applicable
      ↓
Product System Resolver
      ↓
Activity-data resolution / aggregation resolution
      ↓
Derived / proxy evidence fitness
      ↓
Service-life / replacement expansion where applicable
      ↓
LCI Builder
      ↓
Inventory Dataset Fitness Assessment
      ↓
Flow / unit normalization
      ↓
Activity / emission Factor Resolver
      ↓
LCIA Method Package Resolver
      ↓
Characterisation-factor resolution
      ↓
LCIA Characterisation
      ↓
Normalisation
      ↓
Weighting
      ↓
Single-score / relevance computation where method requires
      ↓
Hotspot / contribution analysis
      ↓
Interpretation package

This may ultimately use multiple MICE engines. The roadmap intentionally does not assign new MEIDs until the owning Component and engine boundaries are resolved through canonical architecture.

The separation between activity-data aggregation, inventory-dataset fitness, activity/emission-factor resolution and characterization-factor resolution is logical/semantic. It does not predetermine whether runtime implementation uses one service or several engines.

6.5. Layer 5 — uncertainty and scenarios

This layer performs:

• Monte Carlo uncertainty propagation;
• sensitivity analysis;
• functional-unit sensitivity;
• service-life / replacement sensitivity;
• activity-data aggregation / resolution sensitivity where material;
• derived-model / proxy-data uncertainty;
• alternative allocation models;
• alternative supplier/source models;
• EoL scenarios;
• time-resolved electricity/factor scenarios;
• prospective background systems;
• prospective technology states;
• decision robustness comparisons.

6.6. Layer 6 — assurance, replay and disclosure

This layer:

• creates the replay manifest;
• validates evidence/provenance completeness;
• validates product/assessment maturity for the intended use;
• validates activity-data resolution/aggregation fitness;
• validates derived/proxy evidence applicability;
• validates inventory-dataset representation fitness;
• validates comparative-equivalence conditions where claims compare alternatives;
• verifies method and LCIA-package eligibility;
• verifies dataset entitlement;
• identifies policy deviations/fallbacks;
• routes material findings;
• evaluates trust for intended use;
• supports independent verifier review;
• publishes only the allowed disclosure projection.

---

7. Proposed governed contracts

The names in this section describe required contract families. They are not new canonical IDs until registered through the applicable architecture/registry process.

7.1. Method Profile

Purpose: freeze the methodological interpretation of a run.

Minimum logical content:

method_profile:
  identity:
  version:
  authority_ref:
  effective_from:
  effective_to:
  applicability:
  resolved_rule_stack_ref:
  goal_scope_rules:
  inventory_modelling_principle:
  decision_consequence_context_rules:
  marginal_data_resolution_profile_ref:
  functional_unit_rules:
  functional_equivalence_rules:
  comparison_rules:
  compensatory_process_rules:
  system_boundary_rules:
  cut_off_rules:
  allocation_rules:
  recycling_rules:
  electricity_rules:
  temporal_factor_rules:
  activity_data_resolution_rules:
  service_life_rules:
  data_quality_rules:
  dataset_rules:
  lcia_package_ref:
  normalisation_profile_ref:
  weighting_profile_ref:
  interpretation_rules:
  verification_profile_ref:
  reporting_profile_ref:
  jurisdiction_authority_profile_ref:
  claimant_role_rules:
  publication_context_rules:

7.2. PEF Run Request

The repository currently references schemas/pef-run-request.schema.json, but that file is absent on main at the time of this roadmap.

The replacement should not be created as a thin calculator payload. It should bind:

run_request:
  tenant_ref:
  epu_ref:
  product_definition_version_ref:
  composition_version_ref:
  valid_time:
  method_profile_ref:
  resolved_rule_stack_ref:
  category_rule_ref:
  functional_unit_context:
  comparison_context_ref:
  progressive_assessment_context_ref:
  activity_data_resolution_context_ref:
  service_life_context_ref:
  intended_use:
  graph_view:
  data_cutoff_time:
  scenario_ref:
  uncertainty_profile_ref:
  verification_profile_ref:
  user_authorised_overrides: []

The names above remain conceptual until schema governance resolves the final contract.

The run request should normally reference governed product/evidence objects rather than duplicate the complete LCI in the request body.

7.3. Factor / Dataset contract extension

The existing Dataset Registry concept should be extended rather than replaced.

Required PEF/LCA metadata should include:

• provider and canonical source-inventory identity;
• source-inventory version and checksum;
• distribution / import package identity and version where distinct;
• mapping / normalized-projection identity and version;
• canonical ZAYAZ representation version and checksum;
• provider release / dataset vintage;
• provider publication timestamp where available;
• ZAYAZ capture / ingestion timestamp;
• provisional / revised / final state where provided by the source;
• supersession/revision lineage;
• observation/applicability period distinct from provider release;
• representation type / aggregation state;
• unit-process or system-process coverage where applicable;
• elementary-flow completeness / known omissions where available;
• decomposition / aggregation lineage;
• data-generation method and derivation provenance where applicable;
• source technology/manufacturing maturity where material;
• factor/process identity;
• factor family / role;
• EF compliance state;
• ILCD-EL compliance state where applicable;
• native format and native schema version;
• native model/artifact reference;
• validation profile/result;
• nomenclature and mapping profiles;
• source-to-distribution mapping manifest;
• mapping conformance reference vector/result;
• semantic-equivalence limitations and unresolved mappings;
• applicable PEFCR/category-rule binding where applicable;
• geographical representativeness;
• spatial resolution;
• temporal representativeness;
• temporal resolution;
• interval/series semantics where applicable;
• technological representativeness;
• data-quality admission profile/state where an applicable method or intended-use policy defines a minimum floor;
• quality-dimension / pedigree vector and mapping reference where applicable;
• precision/uncertainty metadata;
• lifecycle boundary coverage;
• factor scope and included/excluded lifecycle stages;
• composition/decomposition relationships and double-counting constraints;
• requested-indicator compatibility and required-flow coverage;
• flow/property/unit semantics;
• impact method compatibility;
• validity dates;
• licence, agreement variant and permitted-use references at ingestion, calculation and disclosure granularity;
• source documentation/provenance;
• supersession/deprecation status.

The same observation period appearing in two provider releases is not automatically the same governed dataset version.

A process-based LCI dataset and a pre-aggregated factor are not automatically substitutable simply because they produce the same unit at one output boundary.

7.4. Factor Resolution Receipt

Every non-trivial factor choice should produce an explainable receipt.

requested_requirement
requested_time_or_interval?
selected_factor_ref
selected_dataset_ref
selected_dataset_vintage?
policy_ref
method_profile_ref
selection_reason
candidate_factors[]
rejected_candidates[]
rejection_reasons[]
fallback_level
quality_assessment
data_quality_admission_decision?
data_quality_profile_ref?
quality_dimensions?
licence_decision
material_limitation?
resolved_at

This receipt is essential for the auditor use case:

Why did ZAYAZ use this Swedish electricity factor rather than a Nordic residual mix, generic European mix or another available factor?

If an auditor changes the selection, the override must preserve:

• the original selection;
• the alternative chosen;
• the authority of the reviewer;
• the evidence/reason;
• scope of the override;
• whether it is reusable as governed learning;
• the downstream recalculation lineage.

AI learning may propose future policy improvements, but a verifier correction must not silently rewrite global factor policy.

7.5. Uncertainty Profile

The uncertainty profile should define which uncertainty families are evaluated, distribution semantics, sampling rules, correlation rules, stopping criteria, reporting percentiles and replay semantics.

It must preserve the exact mathematical parameterization independently of source serialization, including centrality and dispersion definitions, units/transforms, source-field interpretation, mapping reference, conversion formula and any mapping loss or ambiguity. Parameter/data, model, allocation/method-choice, scenario and proxy-choice uncertainty must remain separately attributable.

These parameters are governance and must not live as untracked constants in an engine. Ambiguous or lossy uncertainty mappings must be rejected or routed for governed review rather than silently guessed.

7.6. Footprint Disclosure Profile

A disclosure profile should determine which parts of the complete calculation/evidence graph may be exposed to:

• internal product teams;
• procurement;
• customers;
• auditors/verifiers;
• regulators;
• DPP users;
• Carbon Passport users;
• public claims.

Rights and confidentiality can apply both to values and to graph topology.

The disclosure decision must also bind the applicable jurisdiction, legal authority/effective date, claimant or publisher role, product scope and communication channel where those conditions affect whether a result may be calculated, submitted or communicated.

7.7. Comparability Receipt

Comparative studies, product substitutions, procurement rankings and optimization recommendations should create a first-class record demonstrating whether alternatives are genuinely comparable.

Conceptual content:

comparison_id
products_or_scenarios[]
comparison_intent
primary_functional_unit
alternative_valid_functional_units[]
performance_requirements[]
functional_equivalence_findings[]
service_life_basis
declared_system_boundaries[]
modeled_system_boundaries[]
boundary_coverage_evidence[]
missing_processes[]
coverage_state: covered / missing / unknown / not_reported / not_applicable
system_boundary_alignment
inventory_modelling_principle_compatibility
compensatory_processes[]
method_profile_refs[]
resolved_rule_stack_refs[]
rule_stack_compatibility_findings[]
programme_compatibility_findings[]
dataset_compatibility_findings[]
uncertainty_overlap_finding?
comparability_decision
limitations[]
verification_state

A comparison may be methodologically computable while still being unsuitable for a comparative claim. That distinction should be explicit.

7.8. LCIA Method Package

Purpose: bind a compatible, versioned set of impact categories and characterization-factor semantics beneath a Method Profile.

Conceptual content:

lcia_method_identity
version
authority / provenance
impact_categories[]
category_indicator_level
characterisation_factor_set_refs[]
inventory-flow / stressor mapping
compartment / pathway dimensions
spatial semantics
temporal / time-horizon semantics
population / receptor semantics where applicable
primary / sensitivity factor-set status
uncertainty coverage
normalisation compatibility
weighting compatibility
applicability restrictions
rights / licence refs

A PEF Method Profile may authorize a specific EF LCIA package while another package is available only for research, sensitivity or other product-intelligence uses.

7.9. Progressive Assessment Context

Purpose: make the maturity and intended decision context of a product-footprint calculation explicit.

Conceptual content should be able to express:

product-development stage / maturity
intended decision
product-definition completeness expectation
composition/BOM completeness expectation
activity-data resolution expectation
permitted proxy / inference / derived-data policy
primary-data expectation
inventory-granularity expectation
uncertainty expectation
refresh / invalidation triggers
claim/disclosure eligibility

This contract must not create a second methodology. It describes evidence/product maturity and permitted use around a calculation executed under a separate Method Profile.

7.10. Service-Life / Replacement Model

Purpose: govern use-period assumptions that determine maintenance, repair, replacement or refurbishment quantities in whole-life calculations.

Conceptual content should distinguish:

reference / declared service-life evidence
context-adjusted modeled service life
reference study / use period
maintenance assumptions
repair assumptions
replacement rules
replacement quantity logic
regional / climatic / usage adjustment evidence
uncertainty / distribution
scenario linkage

The exact boundary between EPU product evidence and modeled calculation assumptions requires review before a canonical schema/object identity is created.

7.11. Activity Data Resolution & Aggregation Context

Purpose: preserve the resolution of observed activity data and every governed transformation used to produce calculation-ready activity values.

Conceptual content should be able to express:

source_activity_ref
source_observation_resolution
source_interval / cadence
source_spatial / process granularity
measurement scope
aggregation target resolution
aggregation method
aggregation window
calendar / rolling semantics
missing-interval handling
transformation refs[]
source-to-aggregate lineage
information-loss / hotspot-loss finding
intended-use fitness

A method or intended-use profile may require, permit or reject a particular aggregation level. Those requirements must be governed; the contract does not establish a universal monthly, annual or hourly rule.

7.12. Derived Inventory Evidence

Purpose: prevent estimated, mined, simulated, proxy or predictive environmental data from losing its generation provenance or being mistaken for measured primary inventory.

Conceptual content should distinguish:

evidence/data derivation class
generation method / method family
model / tool / algorithm version
input / reference / training-data refs[]
technology / manufacturing maturity context
geographical applicability
temporal applicability
technological applicability
output scope: LCI / LCIA / other derived quantity
parameter uncertainty
model uncertainty / estimation error
validation evidence
known limitations
replacement / refresh trigger
competing proxy / model hypotheses[]
hypothesis selection / weighting rationale
representative-estimate derivation, if any
result sensitivity across hypotheses

A direct predicted LCIA result cannot satisfy a contract that requires LCI flows merely because it predicts the same impact category.

7.13. Inventory Dataset Fitness Assessment

Purpose: determine whether a technically compatible dataset has sufficient representation, granularity and flow coverage for the intended calculation or decision.

Conceptual content should be able to express:

requested use / analysis purpose
requested indicator / method-package category
required elementary-flow set / coverage threshold
requested inventory representation
candidate dataset ref
representation type / aggregation level
unit-process coverage
foreground elementary-flow completeness
boundary / stage coverage
scenario-decomposition capability
contribution-analysis capability
impact-category coverage constraints
representativeness / pedigree findings
fitness decision
limitations / routing reason

This is distinct from general data quality. A highly reliable aggregated factor may still be unfit for a process-hotspot analysis that requires unit-process inventory.

---

7.14. Rule Stack Resolution / Category Rule Resolution Receipt

Purpose: determine which governed methodological and programme rules apply to a product assessment before the Method Profile is frozen.

Conceptual content should be able to express:

product / category scope
intended declaration / use
jurisdiction / market context
programme operator / programme context

candidate rule refs[]
candidate rule versions[]
governing framework refs[]
core-rule refs[]
complementary PCR / PEFCR refs[]
programme-rule / interpretation refs[]
harmonisation-rule refs[]
legal-rule refs[]

adoption status / applicability findings[]
effective / validity dates[]
precedence / override findings[]
stricter-requirement findings[]
selected rule stack[]
selection reason
human judgement required?
reviewer / verifier finding?
unresolved interpretations[]
resolved_at

The exact persistence model is intentionally unresolved. A single category_rule_ref may remain useful as a convenience or primary category-rule pointer, but it must not be treated as sufficient proof of the complete applicable rule basis where programme/core/complementary/adoption rules form a larger stack.

The resolved stack should be immutable for a historical run. A later PCR, programme-rule or legislative update creates a new rule-stack version / resolution and dependency-impact analysis; it never rewrites the rule basis of the historical calculation.

7.15. Dataset Translation / Projection Receipt

Purpose: prove how one authoritative source inventory became a particular distribution package and ZAYAZ-normalized projection without treating the technical representation as a new scientific source.

Conceptual content should be able to express:

source_inventory_ref / version / checksum
source_provider
distribution_provider
distribution_package_ref / version / checksum
source_and_distribution_rights_refs[]
native_format / source_reference_system
target_format / target_reference_system
flow / unit / property / compartment mappings[]
unresolved / lossy mappings[]
mapping_manifest_ref / version
conformance_profile_ref
reference_vectors[]
conformance_results[]
allowed intended uses
projection_created_at

A translated package may be operationally convenient while remaining semantically unfit or rights-ineligible. Mapping success and numerical execution are not substitutes for reference-result conformance.

7.16. Lifecycle Transition / Substitution Evidence

Purpose: make future reuse, recycling, recovery and avoided-impact assumptions replayable without converting scenario credits into present product facts.

Conceptual content should be able to express:

source product / material state ref
transition type
recovered quantity
recovered material quality / grade
feasible next application
scenario year / valid interval
future background scenario ref
displaced process / technology ref
substitution ratio and evidence
allocation / crediting method ref
gross transition burdens
avoided impacts / credits
net result
benefit ownership / prior-claim evidence
uncertainty and sensitivity
limitations

The exact canonical identity and persistence boundary remain unresolved. The contract family describes required evidence; it does not authorize a new object or crediting method.

7.17. Footprint Evidence Exchange / Reproducibility Receipt

Purpose: prove what an external footprint package represents and which stronger claims it can support without treating an ontology document or DPP payload as calculation authority.

Conceptual content should be able to express:

exchange package identity / version / checksum
producer and intended consumer
product / EPU external identity mappings
source ontology / schema / vocabulary refs and versions
canonical mapping manifest ref
included inventory, method, allocation, scenario and result evidence
required evidence profile ref
required / present / absent / unresolved evidence findings
semantic-loss and open-world absence findings
calculation run and replay manifest refs
pinned dataset / factor / software dependencies
reproduction environment and rights prerequisites
reference outputs and tolerances
reproduction attempt / result / variance findings
method-admissibility decision ref
independent-verification state / evidence ref
disclosure / confidentiality / licence decision refs
limitations

The receipt keeps machine_readable, profile_complete, reproducible, method_admissible and independently_verified as separate findings. A positive state for one never implies the others. The exact canonical artifact/schema identity, persistence boundary and transport contract remain unresolved governed debt.

8. Factor quality architecture

8.1. One factor identity, many quality dimensions

A factor should never be reduced to:

factor_code
value
unit

At minimum ZAYAZ needs to know:

What is it?
What factor family / role does it belong to?
Who published it?
Which provider release / vintage?
Which version / checksum?
What observation/applicability period does it describe?
Is it provisional, revised or final where the provider supplies that state?
What representation / aggregation level does it carry?
What process / technology does it represent?
Which geography and spatial resolution?
Which time period and temporal resolution?
Is it a scalar or a governed time series?
Which lifecycle stages/components are included?
Which impact method/GWP basis?
What source evidence supports it?
What PEF/ILCD compliance state does it have?
What quality/representativeness limitations exist?
What statistical uncertainty exists?
What rights permit ZAYAZ to use or expose it?
What supersedes it?

PEF/LCA also requires clear separation of factor roles. For example:

activity / emission factor
upstream life-cycle factor
characterisation factor
normalisation factor
weighting factor
allocation / conversion parameter

These may all be numeric governed reference data, but they are not interchangeable and should never be resolved through one undifferentiated lookup.

8.2. Data quality is not trust

PEF data quality, statistical uncertainty, source authority, dataset representation/fitness and TrustGate trust are separate dimensions.

A source can be authoritative but poorly representative for the product at hand.

A source can be statistically precise but unlicensed for client-facing use.

A supplier claim can be highly product-specific but unverified.

A factor can describe the correct observation period but come from a superseded provider vintage.

A pre-aggregated factor can be high quality for reporting yet unsuitable for process optimisation because it does not expose the inventory structure needed by that use.

TrustGate should consume these distinctions, not collapse them prematurely.

8.3. Quality-aware factor resolution

Factor resolution should evaluate candidates against the method requirements and product context.

Conceptually:

hard constraints
  - factor role compatibility
  - method compatibility
  - required lifecycle coverage
  - unit/flow compatibility
  - geography eligibility
  - spatial resolution eligibility
  - temporal eligibility
  - temporal resolution eligibility
  - inventory representation / fitness requirement where applicable
  - dataset-vintage policy
  - minimum data-quality / evidence admission policy where applicable
  - licence eligibility
  - PEFCR mandated dataset/rule
        ↓
policy-compliant candidates
        ↓
quality evaluation
  - technological representativeness
  - geographical representativeness
  - temporal representativeness
  - representation / aggregation limitations
  - provider revision / vintage status
  - precision/uncertainty
  - verification / provenance
        ↓
selected factor
        ↓
selection receipt + alternatives

The selection algorithm must be deterministic under a frozen policy profile.

8.4. Native dataset preservation and normalized projection

For ILCD/eILCD and other structured lifecycle datasets, ZAYAZ should preserve the native source artifact independently of any internal normalized representation.

Native source artifact
      ↓ hash + rights + provenance + provider vintage
Native-format validation
      ↓
Nomenclature / semantic mapping
      ↓
Normalized ZAYAZ projection
      ↓
Dataset Registry binding
      ↓
Runtime eligibility

A mapping correction or a new internal projection must not mutate the original source artifact.

8.5. Provider releases are immutable calculation inputs

Frequently refreshed providers may issue a new monthly/quarterly/annual release that contains revised values for periods already published.

ZAYAZ should therefore treat:

provider release A / observation month X

and:

provider release B / observation month X

as distinct governed source snapshots when their bytes, methodology or values differ.

A later release may supersede an earlier source for new calculations while historical replay remains bound to the exact snapshot used originally.

8.6. Dataset representation is a fitness dimension, not a simple quality hierarchy

ZAYAZ should distinguish conceptually among representations such as:

unit-process LCI
partly aggregated process dataset
fully aggregated system process
scalar emission / lifecycle factor
direct LCIA result

Exact canonical vocabulary is unresolved.

These representations answer different questions. A scalar factor can be appropriate for a governed use while being incapable of supporting process contribution analysis, background substitution or additional impact categories. Conversely, unit-process detail may impose unnecessary collection/computation cost where a governed reporting method explicitly accepts aggregation.

The resolver should therefore ask fit for what purpose?, not merely which representation is more detailed?

---

9. Life Cycle Inventory architecture

9.1. Separate foreground and background data

ZAYAZ should explicitly distinguish:

• foreground product/activity data controlled or supplied by the client/value chain;
• background lifecycle datasets/factors;
• inferred/proxy/derived data;
• modeled scenario data.

This distinction affects quality, uncertainty, rights, assurance and supplier-data escalation.

9.2. Preserve product structure

The LCI should not become one flat table detached from the EPU.

Material impact should remain attributable to the product graph path that caused it:

EPU
 → composition version
 → component
 → material
 → supplier / facility
 → process / activity
 → factor / dataset
 → impact

This is what allows ZAYAZ to answer:

• which component dominates climate change impact?
• which supplier data gap matters most?
• why did footprint version 4 differ from version 3?
• which factor change caused the delta?
• what would happen if supplier X changes electricity source?

9.3. Allocation must be an artifact

Allocation is sufficiently decision-material that it should not be hidden in an engine trace.

The existing EPU AllocationDecision should record:

• shared process/input context;
• allocation method;
• governing method rule;
• allocation basis;
• parameters;
• affected products/co-products;
• evidence;
• reviewer/override where applicable;
• version and replay identity.

Alternative allocation scenarios can then be calculated without rewriting authoritative history.

W38 battery research reinforces the materiality of this decision but does not justify inventing a new allocation object or hard-coding the paper authors' preferred method.¹³

9.4. Comparative functional equivalence belongs in the product system

When alternative products deliver different service lives, technical performance or supporting requirements, those differences must become part of the compared product systems rather than explanatory prose after the calculation.

Examples include:

• different product quantities required to deliver the same function;
• coatings or barriers required for one alternative;
• different replacement frequencies;
• altered maintenance;
• different packaging or logistics;
• different use-stage energy requirements;
• different end-of-life constraints.

The Comparability Receipt should reference the exact product-system additions used to establish equivalence.

9.5. Service life must be explicit when it changes lifecycle quantities

Where a product, component or material may be maintained, repaired or replaced inside the modeled study period, service-life assumptions can change the effective LCI quantities.

The calculation should therefore be able to traverse conceptually:

product / component
      ↓
reference / declared service-life evidence
      ↓
calculation-context adjustment
      ↓
modeled service life
      ↓
maintenance / replacement schedule
      ↓
expanded lifecycle quantities
      ↓
impact results

The reference/declared value and the context-adjusted modeled value must remain distinguishable.

A changed modeled service life creates a new scenario/run; it must not rewrite product evidence or previous calculations.

9.6. Progressive LCI must preserve what was unknown

Early product-development LCAs may intentionally use generic datasets, design requirements, ranges or provisional component assumptions.

The LCI should preserve which inputs were:

known / governed
provisional
proxy
derived / estimated
scenario-derived
unresolved

using existing governed evidence/state semantics where possible.

As the design matures, replacement of a proxy with product-specific evidence must create traceable delta/recalculation lineage rather than making the earlier result appear as though the better data had always existed.

9.7. Activity-data aggregation must preserve the source resolution

A calculation-ready activity quantity may be derived from more detailed observations.

Conceptually:

hourly / event / batch / process observations
      ↓
governed aggregation transform
      ↓
daily / monthly / annual / factory-level quantity
      ↓
calculation input

The aggregate must retain its lineage to the source observations, aggregation window and transform. A report using an annual or monthly aggregate must not erase the evidence needed to reproduce a process-engineering calculation at finer resolution when the original data is available and permitted.

Spatial/process aggregation is equally important: a factory total may reproduce a total footprint while making process hotspots impossible to identify.

9.8. Derived inventory evidence must preserve generation provenance

When measured process data is unavailable, ZAYAZ may need to use literature mining, engineering estimates, process simulation, proxy/analogue data or predictive models according to the governing profile.

Those values should enter the LCI with explicit derivation lineage and uncertainty, not as anonymous numbers.

The system must preserve whether a model generated:

• actual inventory flows;
• a parameter used to derive inventory flows;
• or a direct impact prediction.

A direct impact prediction cannot be back-filled into the LCI as if its elementary flows were known.

9.9. Aggregated factors are not inventories

A pre-aggregated emission or impact factor can hide the unit processes, background flows or elementary emissions needed for another analysis.

Therefore:

aggregate factor
≠
process-based LCI

unless a governed adapter/source explicitly provides the underlying inventory and lineage.

The LCI Builder should surface when the requested analysis requires a representation that the available dataset does not provide rather than creating false detail through inference.

---

10. LCIA architecture

PEF requires the platform to retain more than one final score.⁵¹

The calculation chain should preserve the full hierarchy:

Elementary / inventory flows
        ↓
Classification
        ↓
Characterisation-factor set resolution
        ↓
Characterisation
        ↓
Characterised impact-category results
        ↓
Normalisation
        ↓
Normalised impact-category results
        ↓
Weighting
        ↓
Weighted impact-category results
        ↓
Single overall score where applicable
        ↓
Most-relevant categories / stages / processes

Each stage should be reproducible from version-pinned method data.

10.1. Do not hard-code normalization and weighting

Normalization factors and weighting values are governed method data.

They require:

• method/version identity;
• effective period;
• source authority;
• exact factor values;
• impact-category mapping;
• provenance;
• change/supersession handling.

When a future EF method updates characterization, normalization or weighting, ZAYAZ should be able to run the same product under both profiles and explain the delta.

10.2. Impact result identity

Every ImpactCategoryResult should preserve enough lineage to identify conceptually:

calculation_run_ref
impact_category
lcia_method_package_ref
method_version
indicator_level
characterisation_factor_set_ref
relevant spatial / pathway context where applicable
relevant time horizon where applicable
characterised_value
normalised_value?
weighted_value?
unit
functional_unit_basis
life_cycle_stage_contributions[]
process_contributions[]
component_contributions[]
factor_refs[]
uncertainty_ref?
quality_summary

Exact persistence fields must be defined in the applicable schema/contract work, not inferred from this roadmap.

10.3. Environmental footprint and circularity are complementary, not interchangeable

PEF/LCA results should be capable of appearing alongside circularity, recycled-content and resource-recovery metrics from the same EPU while retaining independent methodology and provenance.

A high circularity result must not automatically improve a PEF score, and a low PEF result must not imply circularity.

The product intelligence layer should instead support joined interpretation:

Environmental footprint
+
Circularity
+
Resource efficiency
+
Evidence / assurance
=
multidimensional product sustainability view

Any future composite score combining these dimensions would require its own governed methodology and Scoring Constitution treatment.

10.4. LCIA packages must prevent invalid factor mixing

A method package may contain impact categories with different characterization dimensions and different valid factor sets.

Runtime must therefore prevent errors such as:

• using characterization factors from a different method release without explicit compatibility;
• mixing midpoint and damage factors as though they were the same indicator;
• silently mixing time horizons;
• discarding required spatial/exposure-pathway dimensions;
• using a sensitivity factor set as the primary governed result;
• applying a factor to an incompatible inventory flow or compartment.

A sensitivity run may intentionally use another factor set or method package, but that is a new governed run/scenario with explicit lineage.

10.5. LCIA aggregation preserves methodological value choices

When an LCIA package aggregates across geography, realm, safeguard subject, area of protection or average/marginal resource perspectives, ZAYAZ must retain those choices as method-package semantics. An aggregated score must not conceal which characterization set, perspective or weighting/aggregation rule produced it.

10.6. LCIA cannot recover inventory flows that were never represented

If an available dataset exposes only a climate-change factor or pre-aggregated impact result, ZAYAZ must not imply that other impact categories can be computed with the same methodological fidelity.

Inventory Dataset Fitness should therefore validate whether the source representation exposes the elementary flows and process detail required by the selected LCIA Method Package and intended analysis.

Where only a direct LCIA prediction exists, the result must retain that scope rather than being projected backward into fictitious inventory flows.

10.7. Declared boundary is not modeled boundary

A method or report may declare a lifecycle boundary while the executed inventory omits processes inside it. ZAYAZ must therefore distinguish:

declared lifecycle modules / processes
modeled lifecycle modules / processes
coverage evidence
known missing processes
unknown / not reported / not applicable states

A calculation may remain usable with a disclosed limitation, but the gap must participate in fitness, comparability and TrustGate decisions. Missing evidence must not be inferred from customary LCA practice.

---

11. Uncertainty, sensitivity and decision robustness

11.1. Uncertainty should propagate, not merely annotate

Where input distributions exist, ZAYAZ should be able to propagate them through the footprint model and calculate uncertainty on the output.

The implementation should support correlation where scientifically required. Treating all inputs as independent can be as misleading as ignoring uncertainty entirely.

11.2. Sensitivity should drive data acquisition

Sensitivity results should feed the Data Escalation Planner.

Monte Carlo / sensitivity
       ↓
input contribution to output variance
       +
hotspot contribution to impact
       +
data-quality / representation gap
       ↓
ranked evidence / supplier-data improvement target

This creates a valuable feedback loop:

calculate → quantify uncertainty → identify information with highest value → acquire better evidence → recalculate → measure uncertainty reduction

11.3. Robust ranking

When comparing products or scenarios, ZAYAZ should detect when apparent ranking differences are smaller than modeled uncertainty.

Instead of reporting:

Product A is 3% better than Product B.

ZAYAZ may need to report:

The current evidence does not support a robust ranking; the distributions materially overlap. The largest uncertainty driver is supplier electricity data for component X.

That is more useful for decision-making and assurance than false numerical precision.

11.4. Functional-unit sensitivity

Where more than one valid comparison basis exists, ZAYAZ should be able to calculate the result under each governed basis and report whether the conclusion changes.

This is not permission to select the most favorable basis. The primary basis remains governed by the applicable method/category rule and study objective.

A sensitivity view can answer:

Does the product ranking change by functional unit?
Which life-cycle contributions cause the ranking change?
Is one basis methodologically primary?
Are alternative bases informative or claim-eligible?

A material ranking reversal should become an interpretation/assurance finding.

11.5. Service-life uncertainty

Where service life materially drives maintenance or replacement quantities, a single fixed value can create false precision.

The uncertainty framework should be capable of propagating:

• uncertainty in reference/declared service life;
• context-specific adjustment uncertainty;
• maintenance frequency;
• replacement timing/frequency;
• reference study period assumptions.

Sensitivity output should identify when better durability/service-life evidence would materially change the result and may therefore become a Data Escalation target.

11.6. Derived-model and aggregation uncertainty

Derived data can carry uncertainty from both its source parameters and the generation model itself. ZAYAZ should preserve those separately where the source/method provides them.

Aggregation can also suppress observed variability. The platform should not automatically convert a difference between hourly/daily/monthly results into a statistical uncertainty distribution, but it should be able to record resolution sensitivity and identify when the chosen aggregation materially changes the result or hotspot interpretation.

Where a proxy/predictive model reports estimation error, that error belongs in uncertainty/evidence lineage rather than being discarded when the estimate enters the LCI.

11.7. Method-choice, allocation and proxy-hypothesis uncertainty

Parameter distributions within a frozen model do not cover structural choices. Where more than one governed allocation method, methodological interpretation or proxy hypothesis is plausible, ZAYAZ should represent them as separate attributable runs/hypotheses and report whether the decision changes. A single blended estimate must not erase the alternatives or their authority.

11.8. Serialization-independent uncertainty semantics

LCI adapters must normalize uncertainty into explicit mathematical semantics before computation. The normalized representation retains source-format fields, the interpretation applied, conversion provenance and loss/ambiguity findings. Unknown centrality or dispersion semantics are not repaired by assumption.

---

11.9. Consequential response-mechanism completeness

A consequential scenario should preserve the material response mechanisms considered around a decision, including displacement/substitution, behavioural responses, market responses and other indirect effects where relevant.

For each mechanism, the scenario evidence should distinguish:

included / quantified
included / qualitative
excluded / immaterial
excluded / evidence unavailable
unresolved
not applicable

The state requires a materiality rationale, evidence and uncertainty/limitation disclosure. An uncertain mechanism is not silently removed merely because it is difficult to quantify, but ZAYAZ also does not fabricate values or probability distributions. The governing Method Profile decides which mechanisms are required or permitted.

12. Prospective LCA and temporal architecture

Prospective LCA makes bitemporal/versioned architecture essential.

For every scenario, ZAYAZ should be able to distinguish:

• what product state is valid in the modeled future;
• what ZAYAZ currently knows about that future assumption;
• which factor/dataset projection is used;
• which scenario family produced it;
• when the scenario was created;
• whether the assumption was later superseded.

12.1. Foreground/background time consistency gate

A prospective run should validate that foreground and background assumptions are temporally coherent.

Example finding:

Foreground manufacturing technology: modeled for 2035
Background electricity dataset: observed 2024 mix
Scenario policy: prospective 2035
Decision: ROUTE / require explicit justification or approved fallback

The point is not to forbid every mixed-time analysis. It is to prevent accidental inconsistency from appearing as a coherent prospective result.

12.2. Scenario overlays

Scenario data belongs in scenario views. It must never mutate authoritative actual-state EPU edges.

A product team should be able to compare:

CURRENT_GOVERNED
vs
2030_BASELINE
vs
2030_LOW_CARBON_GRID
vs
2030_SUPPLIER_SWITCH
vs
2030_RECYCLED_CONTENT_TARGET

with shared lineage back to the same baseline product definition.

12.3. Dynamic time-resolved factors

Temporal modelling is not limited to future scenarios. Current operational footprints may depend on when an activity occurred.

A factor resolver should therefore support, where methodologically appropriate:

activity_interval
activity_time_zone
required_factor_resolution
available_factor_resolution
series_version
provider_release / vintage
interval_factor
aggregation_rule
missing_interval_policy

A yearly average and an hourly factor series are distinct governed calculation bases. The method profile decides which one is valid for the intended result.

Time-resolved factor capability also creates a bridge from retrospective PEF/LCA into operational carbon-aware optimization without changing actual historical activity data.

12.4. Three temporal identities must not be conflated

Factor governance should distinguish:

1. activity time
2. factor observation/applicability time
3. provider release / dataset-vintage time

A fourth system-time dimension records when ZAYAZ captured/accepted the artifact.

These dimensions are all relevant to audit and replay and must not be compressed into one year or updated_at field.

12.5. Activity-data resolution is separate from factor resolution

W38 adds another distinction:

activity event / observation time
activity source resolution
activity aggregation window / target resolution
factor resolution
factor applicability interval

For example, monthly activity data multiplied by hourly factors does not magically create an hourly product footprint. Conversely, hourly activity data collapsed to an annual total loses operational timing information even if hourly factor series remain available.

The Method Profile / intended-use context must govern compatible combinations rather than allowing runtime to imply precision that the activity evidence does not contain.

12.6. Attributional and consequential modelling are isolated method principles

The Method Profile must declare whether a run represents attributed product-system burdens, consequences of a decision or another governed modelling principle. The selected principle changes system-boundary logic, data roles and factor eligibility.

A marginal supplier or affected technology in a consequential scenario is a modeled assumption with evidence and uncertainty. It must never overwrite or masquerade as the observed supplier/product relationship in EPU.

A PEF-authorised result cannot silently consume a consequential inventory unless its governing rule stack and Method Profile explicitly permit that principle. Attributional and consequential outputs require separate lineage and are not directly comparable merely because their units and impact method match.

12.7. Future circular credits require transition and ownership evidence

Prospective reuse, recycling or recovery claims must resolve the recovered material's quantity and quality, feasible next application, future scenario year, displaced production technology, substitution ratio and governing allocation/credit method.

ZAYAZ must preserve:

gross transition burdens
avoided-impact credit
net scenario result
credit owner / beneficiary
prior-claim evidence

A physical recovery event and an avoided-impact credit are different claims. The same benefit cannot be counted again across later product lives or organisational boundaries without the governing method explicitly defining the allocation and ownership.

---

13. Rights and dataset entitlement

13.1. Rights check before factor use

The factor resolver should evaluate both methodological eligibility and rights eligibility.

Conceptual decision:

Is this the scientifically/methodologically eligible factor?
        ↓
YES
        ↓
Is this tenant/run/output permitted to use it under the licence?
        ↓
YES → eligible
NO  → reject candidate and record rights reason

The rights decision should be visible in the factor-resolution receipt without exposing confidential contract terms to unauthorized users.

13.2. Prevent derived-data leakage

A SaaS system must consider whether an output can allow reconstruction or redistribution of licensed source data.

Disclosure profiles therefore need to interact with dataset rights.

Potential controls include:

• result-only exposure;
• aggregation thresholds;
• suppression of source factor values;
• no downloadable factor tables;
• tenant/user/location restrictions;
• publication approval gates;
• usage logging;
• licence-expiry handling.

These controls must come from the actual licence/agreement, not generic assumptions.

Derived data and model outputs must also preserve the rights inherited from source/reference/training datasets where the applicable agreements impose such restrictions. Exact rights inheritance remains governed by the relevant licence/agreement and must not be assumed generically.

An exchange ontology, schema or script may be openly licensed while the inventory needed to reproduce its example remains separately restricted. Exchange and reproducibility receipts must therefore identify the rights needed to inspect the package, execute the calculation, access dependencies and disclose results as separate decisions.

Rights eligibility must distinguish at least ingestion, internal calculation, tenant access, derived-output exposure, downloadable redistribution and public communication when the applicable agreement distinguishes them. A general source citation or public download page is not evidence of permission for every SaaS use.

---

14. TrustGate and verifier architecture

TrustGate's constitutional question is:

Can this information be trusted sufficiently for its intended purpose?

PEF is an ideal use case because the same calculation may be adequate for internal hotspot screening but inadequate for a public comparative claim.

14.1. Intended-use trust profiles

Illustrative purposes:

INTERNAL_SCREENING
PRODUCT_DEVELOPMENT_DECISION
SUPPLIER_ENGAGEMENT
PROCUREMENT_DECISION
MANAGEMENT_DECISION
CUSTOMER_PCF_EXCHANGE
REGULATORY_DISCLOSURE
PUBLIC_ENVIRONMENTAL_CLAIM
INDEPENDENTLY_VERIFIED_PEF

These labels are conceptual until governed. They demonstrate why trust cannot be one universal threshold.

14.2. PEF assurance evidence

TrustGate should be capable of evaluating evidence such as:

• method profile authority and validity;
• LCIA Method Package eligibility and version;
• applicable PEFCR/category rule;
• product-definition / assessment maturity;
• product scope completeness;
• activity-data source resolution and aggregation lineage;
• derived/proxy evidence generation method and applicability;
• inventory-dataset representation / fitness;
• comparative-equivalence/comparability receipt where applicable;
• factor-resolution policy conformance;
• dataset release/vintage/replay state;
• dataset compliance/fallback level;
• required disclaimer state;
• supplier evidence status;
• service-life/replacement evidence where material;
• data-quality findings;
• uncertainty findings;
• allocation decisions;
• rights/entitlement state;
• calculation replay verification;
• human overrides;
• verifier findings.

TrustGate assesses trust. It does not recalculate the PEF method and it does not determine scientific truth.

14.3. Auditor correction as governed evidence

When a verifier changes a factor, allocation, boundary interpretation or evidence classification:

1. preserve the original run;
2. record the finding and authority;
3. create an amended governed decision/override;
4. create a new calculation run;
5. calculate and expose the delta;
6. retain both histories;
7. allow AI to propose a reusable policy improvement;
8. require governance before that improvement affects future global/tenant behavior.

This supports learning without allowing one correction to become unreviewed architecture.

14.4. Comparative-claim gate

Comparative outputs require a stronger gate than independent product results.

Where products differ materially in functionality, durability, service life, supporting processes or valid functional basis, TrustGate should route or reject comparative claims until the method's equivalence requirements are satisfied or the limitations are explicitly accepted by the governing profile.

14.5. Progressive-assessment gate

An early design LCA may be trusted sufficiently to choose between design alternatives while being unsuitable for external disclosure.

TrustGate should therefore evaluate the combination of:

assessment maturity
intended use
proxy / inference / derivation state
data completeness
activity-data resolution
inventory representation / granularity
uncertainty
verification state

A later increase in product maturity does not automatically upgrade an earlier calculation. The calculation must be re-executed against the appropriate product state/evidence and receive a new trust assessment.

14.6. Data-resolution and representation gate

A dataset can be trusted as authentic and still be insufficiently detailed for the intended purpose.

Examples:

annual factory total → may support governed reporting use
                       but not process-hour hotspot optimisation

pre-aggregated climate factor → may support a permitted screening use
                               but not multi-impact LCIA requiring elementary flows

predicted LCIA result → may support early chemical screening
                        but not a run contract requiring LCI

TrustGate should consume the underlying Method Profile / Progressive Assessment / Dataset Fitness decisions. It must not invent data-detail thresholds locally.

14.7. Jurisdictional calculation and publication gate

Before a regulated or public result is calculated, submitted or communicated, TrustGate must resolve the applicable jurisdiction, authority/version, effective date, actor/claimant role, product scope and communication channel. A result that is numerically reproducible may still be ineligible for a particular claimant or publication context.

The gate consumes governed legal/method profiles and evidence; it does not embed legislation as engine code. Historical decisions replay against the authority state used at the time.

---

14.8. Evidence-exchange completeness and reproducibility gate

Before an exchanged footprint or DPP environmental package supports a governed use, TrustGate should evaluate separately:

1. representation/schema conformance;
2. completeness against the selected evidence profile;
3. dependency availability and rights-aware reproducibility;
4. method/rule-stack admissibility for the intended use;
5. independent verification or attestation state.

Open-world semantic representation cannot turn an absent required field into a positive completeness result. A package may be accepted for discovery or internal analysis while being rejected for reproduction, regulated reporting or comparative/public claims. The decision preserves missing/unresolved fields, mapping loss, reproduction findings and the exact validation profile.

15. Replay model

Every PEF run should generate a replay manifest capable of reconstructing the constitutional execution.

Minimum conceptual content:

calculation_run_id
run_request_hash
product_state_refs[]
graph_view + effective time
progressive_assessment_context_ref?
activity_data_resolution_context_ref?
activity source refs / source resolutions
aggregation transformation refs[]
derived evidence refs[]
derivation model / tool versions
resolved_rule_stack_ref + version/hash + effective-date context
method_profile_ref + version
lcia_method_package_ref + version
category_rule_ref + version
comparison_context_ref?
comparability_receipt_ref?
service_life_context_ref?
policy_bundle_refs[]
compute_method_refs[]
engine / implementation identities
input/evidence refs[]
footprint evidence exchange package refs[] + checksums
exchange mapping / completeness-profile refs[]
reproduction environment / dependency / rights findings[]
dependency snapshot / invalidation manifest where incremental recomputation is used
reused prior artifact refs[] + reuse justification where applicable
dataset refs[] + versions + checksums
inventory dataset fitness assessments[]
provider release / vintage refs[]
source capture timestamps / hashes
native dataset artifact refs[]
factor refs[]
factor-resolution receipts[]
time-series factor refs[] where applicable
allocation decisions[]
unit conversions[]
characterisation factor-set refs[]
normalisation profile
weighting profile
uncertainty profile
PRNG / seed where applicable
scenario refs[]
human overrides[]
rights decisions[]
software/runtime provenance
output hashes

Historical replay must use the historical product/activity state, aggregation transforms, derived-data model versions, factors/methods/provider snapshots and dataset representations — not silently substitute newer or more detailed data.

---

16. Pergamum Pulse role

Pergamum Pulse should become the governed source of truth for what PEF/LCA rules mean and when they apply, not the calculator itself.

16.1. Source-to-runtime chain

Commission Recommendation / guidance / PCR / PEFCR / programme rule / method publication
        ↓
PP Source Object + immutable capture
        ↓
Knowledge Document / Source Fragment
        ↓
Knowledge Assertion
        ↓
review / governed knowledge
        ↓
Change Candidate
        ↓
Change Decision
        ↓
Projection Manifest
        ↓
method / factor / policy registry update
        ↓
new runtime version

ZARA should be able to traverse the path backwards when explaining a calculation rule.

16.2. PEF change surveillance

Pergamum Pulse should monitor at least:

• Commission Environmental Footprint method changes;
• PEFCR/OEFSR lifecycle changes;
• PCR/core-rule/complementary-rule lifecycle changes and programme adoption/interpretation changes;
• EF-compliant dataset guidance;
• ILCD/eILCD schema, tooling and compatibility changes;
• LCIA method and characterization-factor updates;
• normalization/weighting updates;
• activity-data collection / aggregation requirements introduced by authoritative methods;
• emissions-factor and lifecycle-dataset releases/revisions where authoritative surveillance is available;
• verification guidance;
• product-specific EU legislation that adopts or modifies lifecycle methods;
• authoritative dataset methodology changes.

A regulatory/method/data change should create impact analysis against:

• method profiles;
• LCIA Method Packages;
• activity-data resolution rules;
• dataset bindings, representations and vintages;
• import/mapping profiles;
• factor policies;
• compute methods;
• active product footprints;
• disclosure profiles;
• verification rules.

This is how ZAYAZ avoids the dangerous pattern of an updated law, method or reference dataset being noticed only after clients have produced stale footprints.

---

17. SSSR, USO and ZAR implications

17.1. SSSR

PEF/LCA needs physical signal addressability for product/activity/factor/result data, but this roadmap must not invent signal IDs.

Required future signal semantics are likely to include events/findings such as:

• footprint calculation requested/completed/failed;
• method profile resolved;
• LCIA package resolved;
• assessment maturity resolved/changed;
• activity-data aggregation performed / rejected;
• activity-data resolution insufficient for intended use;
• derived/proxy data used / superseded;
• inventory-dataset fitness accepted / routed;
• comparability assessment completed/failed;
• factor selected/fallback used;
• provider factor dataset revised/superseded;
• time-resolved factor series resolved/incomplete;
• service-life assumption material;
• dataset quality insufficient;
• factor rights rejected;
• supplier primary data requested/received;
• uncertainty threshold finding;
• method version changed;
• footprint delta material;
• verification required/completed;
• product graph change requires recalculation.

17.2. USO

USO should classify the governed runtime data according to the existing ontology rather than receive a special PEF-only parallel code system.

The mapping exercise should cover:

• product input/activity data;
• activity-data resolution / aggregation context;
• derived/proxy evidence;
• method/profile inputs;
• LCIA package/factor-set inputs;
• assessment-maturity context;
• comparison/equivalence context;
• service-life/replacement context;
• inventory-dataset representation / fitness;
• factor/dataset references;
• computation execution;
• uncertainty/scenario inputs;
• product footprint results;
• assurance/verification outputs.

No new USO codes are defined in this roadmap.

17.3. ZAR

PEF execution should use ZAR for immutable contract/artifact identity where ZAR is the canonical identity layer for the applicable schema/method artifact.

Candidate artifact families include:

• run request schema;
• method-profile schema;
• LCIA Method Package schema;
• progressive-assessment-context schema;
• activity-data resolution/aggregation schema;
• derived-inventory-evidence schema;
• inventory-dataset-fitness schema;
• service-life/replacement schema;
• comparability-receipt schema;
• factor-resolution receipt schema;
• uncertainty-profile schema;
• footprint-result schema;
• replay-manifest schema.

Exact ZAR identities must be registered through current ZAR governance, not invented here.

---

18. CMID / metric implications

PEF creates metrics across multiple impact categories, lifecycle stages, quality dimensions and result levels.

The platform should not manufacture CMIDs simply to make the first implementation compile.

Potential metric families requiring governed review include:

• characterised result by impact category;
• normalized result by impact category;
• weighted result by impact category;
• PEF single overall score where applicable;
• contribution by lifecycle stage;
• contribution by process/component/supplier;
• data-quality dimensions;
• uncertainty range/percentiles;
• primary-data share;
• derived/proxy-data share where decision-useful;
• EF-compliant dataset share / fallback share;
• unresolved/omitted process materiality;
• material over-aggregation / insufficient-granularity findings where exposed as metrics rather than state;
• assessment maturity / evidence completeness where exposed as metrics rather than state;
• separate circularity/resource-efficiency metrics where those are already governed elsewhere.

---

19. Existing persistence and migration decision

The existing table relationship registry shows fact_pef_run linked to zyz_mice_fume_input and zyz_mice_fume_result.

That is too narrow to assume as the target full PEF architecture because full PEF must represent:

• many product graph inputs;
• activity-data source resolution and aggregation lineage;
• derived/proxy data-generation provenance;
• multiple lifecycle stages;
• many factors and datasets;
• inventory-dataset representation / fitness findings;
• provider dataset vintages/snapshots;
• temporal factor series where applicable;
• LCIA Method Packages and factor sets;
• multiple impact categories;
• allocations;
• method profiles;
• assessment maturity context;
• service-life/replacement assumptions where applicable;
• comparison/equivalence context;
• factor selection receipts;
• uncertainty/scenario results;
• evidence and rights;
• footprint evidence exchange packages, completeness profiles and reproduction findings;
• replay manifests.

Recommended decision:

1. preserve the existing prototype until its actual implementation use is understood;
2. migrate the related historical PDF/specification material according to doc-transfer.mdx where applicable;
3. do not add new full-PEF semantics to the prototype merely because it already carries the PEF name;
4. define the target CalculationRun / result / telemetry contract;
5. map existing fact_pef_run semantics into the target model;
6. migrate, reuse or deprecate only after compatibility and Hecate-readiness review.

---

20. Recommended roadmap

Roadmap 0 — Constitutional and method foundation

Outcome: ZAYAZ can define exactly what a PEF/LCA calculation means before writing the calculator.

Deliverables:

• approve this roadmap as the architecture direction;
• migrate/reconcile the historical specifications for PEF-ME, LCA-OPTI, PEFX and ZARA-MO according to the governed documentation-transfer process;
• resolve ownership boundaries for those identities after migration against current architecture;
• define the Rule Stack Resolution / Category Rule Resolution Receipt contract family;
• define authoritative applicability, programme-adoption, precedence/override and effective-date semantics for rule stacks;
• define the PEF/LCA Method Profile contract, including attributional/consequential modelling-principle isolation;
• define marginal-data and affected-process resolution evidence for permitted consequential scenarios;
• define LCIA Method Package semantics and method/package authority separation;
• define category-rule binding semantics;
• define functional-equivalence and comparability semantics;
• define progressive-assessment / product-maturity context semantics;
• define activity-data resolution / aggregation semantics and ownership boundary;
• define derived/proxy inventory-evidence semantics;
• define inventory-dataset representation / fitness semantics;
• define service-life / replacement assumption boundaries;
• define calculation/run envelope semantics;
• define FootprintResult/ImpactCategoryResult binding to EPU;
• define Factor Resolution Receipt contract;
• define Comparability Receipt contract;
• define factor/data-quality/uncertainty distinctions;
• define provider dataset vintage/snapshot semantics;
• define rights binding for datasets;
• define native ILCD/eILCD preservation and mapping principles;
• define source-inventory versus distribution/import-package identity and translation-conformance evidence;
• define lifecycle-transition/substitution evidence and avoided-impact claim ownership;
• define footprint evidence-exchange, completeness, reproducibility, method-admissibility and verification-state boundaries;
• define external ontology/vocabulary mapping and canonical-identity resolution rules;
• select the first governed battery EPU specimen;
• specify forbidden architectural shortcuts for Hecate implementation packets.

Exit criterion: a developer can explain the product-state, maturity, activity-data resolution/derivation, method, LCIA package, inventory representation, comparison, lifecycle assumption, factor, dataset vintage, calculation, result and replay identity chain without inventing an object or relationship.

Roadmap 1 — Factor & Dataset Governance Foundation

Outcome: ZAYAZ can resolve factors and inventory datasets deterministically, transparently, interoperably and legally.

Deliverables:

• extend Dataset Registry metadata for PEF/LCA;
• represent inventory dataset type / aggregation / process granularity;
• represent elementary-flow completeness / known omissions where available;
• represent data-generation method and derived-data provenance;
• represent provider release/vintage and immutable source snapshots;
• preserve source-inventory identity separately from distribution/import package and normalized projection identity;
• require versioned mapping manifests and reference-result conformance before translated data become eligible;
• distinguish observation period from provider release and ZAYAZ capture time;
• represent provisional/revised/final states where provider metadata supports them;
• represent factor/process identity and factor role;
• represent lifecycle coverage;
• represent factor scope, included/excluded stages and composition/decomposition constraints;
• prevent double counting when direct, upstream, fuel-cycle and transmission/distribution adjustments overlap;
• represent requested-indicator compatibility and required-flow coverage;
• implement scalar and time-series factor semantics;
• implement geography/spatial and time/temporal resolution metadata;
• implement EF / ILCD compliance metadata;
• implement representativeness/data-quality metadata;
• implement governed minimum data-quality admission rules separately from candidate ranking;
• retain applicable pedigree/DQI dimensions and their uncertainty mapping where a method/profile uses them;
• implement serialization-independent uncertainty metadata with explicit centrality/dispersion semantics, mapping provenance and ambiguity findings;
• bind datasets to Pergamum rights/licence/agreement objects at calculation and disclosure granularity;
• create governed factor-resolution policy bundles;
• implement inventory-dataset fitness assessment;
• implement factor candidate/selection receipt;
• implement source/version/checksum freeze;
• implement native ILCD/eILCD artifact preservation;
• implement ILCD/eILCD validation and normalized projection boundary;
• implement translation/projection receipts for supported external distributions;
• prepare IEA adapter architecture without activating client use until appropriate licence/agreement exists;
• ingest/validate open or otherwise permitted baseline datasets required for the golden specimen.

Exit criterion: for every selected factor/dataset, ZAYAZ can explain why it is methodologically preferred, what representation/granularity it provides, which temporal/spatial basis was used, which provider vintage/snapshot supplied it, what native data/mapping produced it, and why the intended use is permitted and fit.

Roadmap 2 — Golden PEF Calculation

Outcome: one product can be calculated end-to-end using a governed, replayable PEF-compatible method profile.

Recommended specimen: a battery product EPU with a versioned BOM and sufficient supplier/material/electricity/EoL complexity to exercise the architecture.

Deliverables:

• goal/scope validation;
• functional-unit/reference-flow handling;
• progressive-assessment context for at least one early-design and one production-state fixture;
• comparison/equivalence handling for applicable test cases;
• declared-versus-modeled boundary coverage assessment with explicit missing/not-reported/not-applicable states;
• product-system resolution from EPU;
• controlled multi-resolution activity-data fixture demonstrating deterministic aggregation lineage and hotspot effects;
• explicit allocation/multifunctionality fixture governed by the Method Profile / AllocationDecision;
• at least one derived/proxy evidence fixture with competing hypotheses, selection rationale and preserved generation/uncertainty lineage;
• service-life/replacement expansion where applicable to the specimen/test fixtures;
• LCI construction;
• one machine-readable evidence-exchange package with profile-completeness and independent reproduction fixtures;
• inventory-dataset fitness validation;
• unit/flow normalization;
• activity/emission factor resolution;
• LCIA Method Package resolution;
• characterization-factor resolution;
• LCIA characterization;
• normalization;
• weighting;
• relevance/hotspot analysis;
• result objects linked to the EPU graph;
• method/factor/evidence lineage;
• replay manifest;
• machine-readable report package;
• comparison against a manually verified reference calculation;
• at least one controlled comparative case proving the Comparability Receipt behavior.

Exit criterion: the complete footprint can be replayed from frozen governed inputs and an auditor can traverse any material result to method, LCIA factor set, activity source/aggregation lineage, derived-data generation where applicable, factor/dataset representation/vintage and evidence.

Roadmap 3 — Data Escalation & Supplier Primary Data

Outcome: ZAYAZ actively improves product footprints instead of merely calculating them.

Deliverables:

• hotspot and structural contribution analysis;
• data-quality gap analysis;
• resolution / over-aggregation gap analysis;
• derived/proxy data replacement opportunities;
• inventory representation / flow-completeness gap analysis;
• sensitivity-aware data prioritization;
• assessment-maturity-aware data prioritization so early design does not demand unnecessary claim-grade evidence;
• Data Authority Resolution;
• FOGE generation of minimal unresolved supplier questions;
• EPU Supplier Contribution integration;
• TrustGate validation of returned evidence;
• automatic dependency analysis and recalculation proposal;
• before/after uncertainty, resolution and quality comparison.

Exit criterion: ZAYAZ can show that a specific supplier request was generated because it is the highest-value unresolved data improvement for the current product decision/maturity context — including when the deficiency is granularity/derivation rather than a missing field — and can quantify what improved after receipt.

Roadmap 4 — Probabilistic, Temporal & Prospective LCA

Outcome: ZAYAZ can express uncertainty, time-varying factors and future environmental performance without false precision or state corruption.

Deliverables:

• governed uncertainty profiles;
• Monte Carlo propagation;
• parameter/data, model, allocation/method-choice, scenario and proxy-choice uncertainty kept separately attributable;
• source-format uncertainty interoperability with ambiguous-mapping rejection;
• derived-model / estimation uncertainty support;
• sensitivity decomposition;
• correlation support where required;
• robust comparison/ranking checks;
• functional-unit sensitivity;
• activity-data resolution / aggregation sensitivity;
• service-life / replacement sensitivity;
• time-resolved factor-series execution where methodologically permitted;
• dataset-vintage/revision sensitivity where relevant;
• scenario identity and overlays;
• explicit modelling-principle identity and attributional/consequential isolation;
• marginal-supplier/affected-technology assumptions with uncertainty and evidence;
• response-mechanism inventory covering included, excluded, immaterial and unresolved displacement, behavioural and market effects;
• lifecycle-transition/substitution evidence with gross burdens, avoided credits and net results separated;
• recovered-material quality, feasible next use and anti-double-claim checks;
• foreground/background time-consistency validation;
• linked scenario-assumption coherence fixtures;
• future dataset/factor profiles;
• RIF integration;
• LCA-OPTI bounded scenario optimization;
• prospective result explanation through ZARA.

Exit criterion: scenario results never overwrite actual state, stochastic results are replayable according to their declared profile, time-resolved calculations preserve both activity and factor resolution, provider snapshots remain frozen, and ZAYAZ can explain which inputs dominate both impact and uncertainty.

Roadmap 5 — Assurance, Verification, Circularity Context & Exchange

Outcome: ZAYAZ can distinguish an internal screening footprint from an externally defensible/verified footprint and can present footprint alongside complementary product-sustainability dimensions without conflation.

Deliverables:

• intended-use assurance profiles;
• jurisdiction-, authority-, claimant- and publication-context gates for regulated/public outputs;
• progressive-assessment maturity gate;
• activity-data resolution / aggregation fitness gate;
• derived/proxy evidence applicability gate;
• inventory-dataset representation / fitness gate;
• comparative-claim assurance gate;
• declared-versus-modeled boundary coverage gate;
• attributional/consequential comparison restriction;
• avoided-impact ownership and prior-claim gate;
• TrustGate PEF evidence package;
• evidence-exchange profile validation separating representation, completeness, reproducibility, method admissibility and verification;
• external ontology mapping/conformance fixture without duplicate canonical identities;
• verification workflow and findings;
• governed human override path;
• calculation delta after correction;
• report/disclosure profile;
• parallel footprint + circularity/resource-efficiency projection from EPU where applicable;
• Carbon Passport integration;
• DPP projection where applicable;
• external design-object result binding and recalculation fixture without transferring calculation authority to the design system;
• PEFX exchange-contract reconciliation;
• rights-aware external outputs.

Exit criterion: a public/customer/verifier-facing output cannot be produced unless the product/assessment maturity, activity-data resolution, derivation state, inventory representation, method, LCIA package, evidence, comparison basis where applicable, rights, replay and assurance state meet the policy for that intended use.

Roadmap 6 — Method Evolution & Portfolio Scale

Outcome: PEF becomes a continuously governed platform capability across large product portfolios.

Deliverables:

• multiple EF/method versions in parallel;
• multiple LCIA Method Package versions in parallel;
• PEFCR-specific profiles;
• provider dataset-vintage impact analysis;
• activity-data resolution / derivation change impact analysis;
• inventory-representation change impact analysis;
• change impact analysis from Pergamum Pulse, including rule-stack/PCR/programme-rule changes;
• controlled portfolio recalculation;
• dependency-bounded incremental recalculation with explicit invalidation and reuse evidence;
• rule-stack/factor/method/LCIA-package/BOM/supplier-data/evidence delta attribution;
• deterministic proof that unaffected cached/sub-results remain reusable under the frozen dependency/policy state;
• product-family reuse of shared calculations where scientifically valid;
• caching without loss of provenance;
• exchange-profile and external-vocabulary version impact analysis;
• batch/portfolio observability;
• method migration reports.

Exit criterion: when a method, LCIA package, activity-data derivation/resolution or dataset release/representation changes, ZAYAZ can identify exactly which product results are affected, estimate materiality, recompute intentionally and preserve the historical result lineage.

---

21. Hecate-ready implementation packets

After Roadmap 0 approval, implementation work should be split into bounded Needs rather than one build PEF epic.

Recommended Need families:

Need family	Human outcome	Required deterministic evidence
Rule Stack Resolution	Resolve the authoritative rule basis for one product/programme/intended use before the Method Profile is frozen.	Multi-source applicability fixture; programme-adoption fixture; precedence/override fixture; ambiguous-choice fixture with reviewer evidence; effective-date replay; historical stack immutability.
Method Profile	Represent PEF method/category-rule choices as governed versioned data.	Schema validation; resolved-rule-stack binding; modelling-principle isolation; invalid attributional/consequential combinations rejected; version freeze/replay.
Marginal Data Resolution	Resolve a consequential scenario's affected supplier/technology without representing it as an observed supplier relationship.	Candidate/evidence trace; temporal scope; market/model basis; uncertainty; alternative marginal candidates; EPU actual-state isolation.
LCIA Method Package	Bind method-specific impact categories and characterization-factor sets without invalid cross-method mixing.	EF reference fixture; non-PEF GLAM fixture; midpoint/damage/time-horizon incompatibility tests; sensitivity-run lineage.
Progressive Product LCA	Make early-design LCA useful without representing provisional evidence as claim-grade.	Stage/maturity fixtures; proxy-policy tests; design-state change forces new run; disclosure gate rejects insufficient maturity.
Activity Data Resolution & Aggregation	Preserve source observation resolution and governed aggregation transformations for calculation-ready activity data.	Hourly/daily/monthly aggregation fixtures; calendar/rolling-window fixture; process/factory aggregation fixture; deterministic lineage; hotspot-loss finding; replay.
Derived Inventory Evidence	Use estimated/mined/simulated/predictive evidence without losing how it was generated or overstating its scope.	Measured-vs-derived fixture; model/tool/version lineage; applicability mismatch route/reject; uncertainty retained; direct-LCIA output cannot satisfy LCI requirement; replacement trigger.
Inventory Dataset Fitness	Prevent pre-aggregated factors or incomplete inventories from being used for analyses that require process/flow detail or a particular indicator.	Process-LCI vs aggregate-factor fixtures; indicator-specific required-flow coverage; screening-use positive case; hotspot/multi-impact negative case; explainable fitness decision.
Uncertainty Interoperability	Preserve mathematical uncertainty semantics across source formats without guessing ambiguous parameter meanings.	Known-distribution reference vectors; source-field interpretation; lossless conversions; ambiguous lognormal mapping rejected/routed; conversion and replay evidence.
Jurisdictional Method & Disclosure Profile	Select the applicable legal/method and publication conditions by jurisdiction, effective date, claimant and channel.	Effective-date transition fixture; permitted/prohibited claimant cases; historical replay; authority/version evidence; disclosure rejection reason.
Service-Life & Replacement Model	Expand lifecycle quantities from governed service-life and maintenance/replacement assumptions.	Reference-life fixture; context-adjustment fixture; replacement-count reference vector; uncertainty/sensitivity test; product evidence remains immutable.
Comparability Receipt	Prove that compared products/scenarios use valid functional equivalence and aligned boundaries.	Positive/negative equivalence fixtures; compensatory-process lineage; unsupported comparative claim rejected/routed.
Factor Registry Extension	Represent PEF/LCA factor metadata, quality, uncertainty, temporal/spatial resolution and lifecycle coverage.	Dataset/factor fixtures validate; unit/flow/time mismatches rejected; minimum-quality admission fixture; DQI/pedigree vector retained where applicable; version/checksum retained.
Factor Dataset Snapshot & Vintage	Preserve provider-release identity independently of observation period and historical replay.	Two releases covering same period remain distinct; immutable source hash; old run replays against original snapshot; superseding release creates impact-analysis candidate.
ILCD/eILCD Adapter	Preserve and validate native lifecycle dataset/model artifacts and create governed normalized projections.	Native schema validation; source hash retained; mapping lineage; round-trip/reference fixtures where appropriate.
Dataset Translation / Projection	Preserve source inventory, distribution package and normalized projection as distinct versioned artifacts with semantic-conformance evidence.	Source/distribution hashes; mapping manifest; flow/unit/compartment mapping; unresolved-loss findings; cross-representation reference-result parity; rights checks.
Rights Binding	Prevent use/exposure outside dataset rights.	Positive and negative tests for ingestion, calculation, tenant access, derived-output exposure, download and public communication; prohibited disclosure blocked.
Factor Resolver	Select the correct allowed activity/emission factor under frozen policy and time context.	Candidate trace; minimum-quality admission before ranking; deterministic receipt; required fallback behavior; temporal interval/vintage test; rejected alternatives recorded.
EPU LCI Resolver	Assemble product-system inputs from exact graph state.	Historical/as-of graph tests; BOM version test; source-resolution/derivation state surfaced; missing/provisional evidence surfaced.
LCIA Characterization	Compute impact-category results under a pinned LCIA Method Package.	Reference-vector parity tests per category; factor-set compatibility tests.
Normalization & Weighting	Apply versioned method data.	Reference-vector tests; method-version comparison; no hard-coded weights.
Footprint Result	Persist/emit product-level calculation lineage.	Traversability to input/method/LCIA package/activity aggregation/derived evidence/factor/evidence; immutable historical result.
Uncertainty Engine/Profile	Propagate governed input uncertainty.	Fixed-seed replay; distribution tests; derived-model error fixture; sensitivity output; correlation fixture.
Data Escalation Planner	Rank which missing or insufficient data should be acquired next.	Explainable priority reasons; no request for already-resolved data; over-aggregation/derived-data materiality fixture; maturity-aware request policy; before/after quality result.
Dependency Impact & Incremental Recalculation	Recompute only the calculation/result subgraph affected by a governed product, supplier, factor, method or evidence change while proving safe reuse of unaffected artifacts.	Single-node and multi-node invalidation fixtures; method-wide invalidation fixture; dependency-closure proof; unchanged-node reuse proof; new-run/result lineage; no stale result survives.
Supplier PEF Contribution	Acquire only unresolved governed product data.	Access-control tests; evidence lineage; dependency recalculation trigger.
Temporal Factor Execution	Apply governed time-resolved factors to timestamped/interval activity.	Activity/factor resolution compatibility; interval alignment tests; provider-vintage pinning; missing data policy; average-vs-hourly differentiation; replay.
Prospective Scenario	Model future product/background states safely.	Scenario/actual-state separation; time-consistency findings; linked climate/market/energy assumption fixture; historical scenario replay.
Lifecycle Transition / Substitution	Model future reuse/recycling/recovery without treating scenario credits as present product facts or double claiming them.	Recovered-quality and next-use fixture; future displaced-process resolution; substitution sensitivity; gross/credit/net separation; prior-claim rejection; replay.
Boundary Coverage Assessment	Compare declared lifecycle scope with processes actually modeled and evidence available.	Complete, missing, unknown, not-reported and not-applicable fixtures; comparison routing; no inference from customary practice.
Footprint Evidence Exchange & Reproducibility	Exchange a machine-readable footprint package while proving completeness and reproducibility separately from method admissibility and verification.	External ontology fixture; canonical mapping manifest; required/present/absent evidence matrix; open-world absence negative test; dependency and rights manifest; independent reproduction/reference-output test; separate assurance states.
Consequential Response Completeness	Preserve which material displacement, behavioural and market mechanisms were included, excluded, immaterial or unresolved.	Positive/negative mechanism fixtures; materiality rationale; qualitative uncertainty path; omitted-material-effect routing; no fabricated distributions; attributional/PEF isolation.
PEF Trust Profile	Gate use according to maturity/evidence/resolution/representation/method/rights/replay.	TrustGate pipeline evidence; purpose-specific decision tests; aggregate-vs-engineering fixture; derived-vs-primary fixture; provisional-vs-claim-grade fixture; override trail.
PEF Disclosure / Exchange	Project approved result for external use.	Rights-aware projection; schema conformance; no source-data leakage.

Hecate should bind each Need to the exact source commit and section of this roadmap and to any later canonical contracts created from it.

---

22. Cross-cutting acceptance criteria

The following criteria should remain true across the complete capability.

AC-01 — Method determinism

Given the same frozen product state, method profile, LCIA Method Package, activity-data transforms, datasets/factors, policy bundle and deterministic engine versions, ZAYAZ reproduces the same deterministic footprint result.

AC-02 — Complete material lineage

Every material ImpactCategoryResult can traverse to:

CalculationRun
→ method profile
→ LCIA Method Package / characterization factor set
→ relevant product/activity input
→ source resolution / aggregation / derivation where applicable
→ factor
→ dataset/version/vintage/representation
→ source/evidence
→ allocation where applicable

AC-03 — Historical immutability

A later method, activity-data refinement, factor, dataset vintage/representation, supplier submission or product update never mutates a historical footprint result.

AC-04 — Explainable factor choice

For every material selected factor, ZAYAZ can show:

• selected candidate;
• policy used;
• relevant context;
• spatial/temporal basis where relevant;
• provider release/vintage where relevant;
• dataset representation limitations where relevant;
• rejected alternatives;
• fallback level;
• quality state;
• rights state.

AC-05 — Rights enforcement

A scientifically valid factor cannot be used or externally exposed where the applicable licence/agreement prohibits the intended use.

AC-06 — DQ / uncertainty separation

Data-quality metadata, dataset fitness, source trust and statistical/model uncertainty remain separately queryable and separately explainable.

AC-07 — Scenario isolation

Modeled future/alternative states never overwrite the governed actual-state Product Graph.

AC-08 — Reproducible uncertainty

Probabilistic calculations declare replay semantics. Where exact seeded replay is the governed profile, the same frozen execution reproduces the same sample-based result.

AC-09 — No-ask-before-reuse

Supplier data requests do not ask for fields already resolvable with sufficient validity, authority, quality, resolution, representation and permission for the intended use.

AC-10 — Material data prioritisation

Data-improvement recommendations explain why the requested input is expected to materially improve the calculation or decision.

AC-11 — Method-change impact analysis

A changed PEF rule/method/LCIA-package version can be mapped to affected profiles, factors, computations and product results before portfolio recalculation.

AC-12 — Trust is purpose-specific

A footprint may be accepted for internal screening/product development while being routed/rejected for public communication. The decision explains the policy, maturity, evidence, resolution and representation difference.

AC-13 — Auditor correction lineage

A human/verifier correction creates governed evidence and a new result lineage. It never silently rewrites the original calculation.

AC-14 — Hecate does not guess architecture

Every implementation Need resolves its module/component/engine/contract/registry boundary or stops for architecture resolution.

AC-15 — Comparative equivalence

A comparative claim cannot be approved unless the comparison basis, functional equivalence, service-life assumptions, compensatory processes and boundary alignment satisfy the governing comparison profile or an explicit governed limitation is recorded.

AC-16 — Temporal factor identity

A time-resolved calculation preserves the exact factor series/version, provider release/vintage, interval mapping and aggregation policy used. An annual-average result is distinguishable from an hourly or other time-resolved result.

AC-17 — Native lifecycle dataset lineage

A normalized ZAYAZ dataset derived from ILCD/eILCD or another structured lifecycle source retains an immutable reference to the native source artifact, validation result and mapping/aggregation lineage.

AC-18 — Multidimensional sustainability separation

Circularity/resource-efficiency metrics may be presented alongside PEF/LCA results but never silently modify the PEF result unless an applicable governed methodology explicitly requires it.

AC-19 — LCIA package integrity

A calculation cannot silently mix characterization-factor sets, indicator levels, time horizons or required spatial/pathway dimensions that are incompatible with the selected LCIA Method Package.

AC-20 — Progressive assessment integrity

A result calculated under an early/provisional product-development context remains explicitly provisional for uses requiring greater product/evidence maturity. Later product maturity requires a new calculation/trust assessment; it does not upgrade the old result in place.

AC-21 — Dataset-vintage replay

If a provider revises values for an already-covered observation period, historical calculations replay against the original captured artifact/hash unless an explicit new calculation is requested.

AC-22 — Service-life lineage

A modeled service-life or replacement assumption is traceable to its evidence, adjustment/scenario logic and uncertainty state. Changing it creates a new run/scenario and never mutates the underlying product evidence.

AC-23 — Activity-data resolution lineage

Every material aggregated activity input is traceable to its source observation resolution, aggregation window/method and transformation lineage. A later finer-resolution input creates a new run rather than rewriting the historical aggregate.

AC-24 — Derived-data provenance integrity

Estimated, mined, simulated, proxy or predictive evidence retains its generation method, model/tool version, applicability and uncertainty/validation state. A direct LCIA prediction cannot satisfy an LCI requirement.

AC-25 — Inventory representation fitness

A pre-aggregated factor or incomplete inventory cannot satisfy a governed requirement for process-based LCI, elementary flows, contribution analysis or multi-impact coverage unless the source actually provides the required representation and lineage.

AC-26 — Purpose-specific resolution fitness

Different activity-data resolutions may be valid for different governed purposes, but the selected resolution must satisfy the applicable Method Profile / intended-use policy. ZAYAZ never implies temporal or process precision that the source activity data does not contain.

---

AC-27 — Data-quality admission before selection

Where the applicable profile defines a minimum data-quality/evidence floor, a candidate below that floor cannot be selected merely because its value, label, geography or unit otherwise matches. The admission decision, applicable quality dimensions and any uncertainty mapping remain replayable.

AC-28 — Dependency-bounded incremental recalculation

A governed change invalidates all and only dependent calculation/result artifacts under the frozen dependency and policy state. Unaffected artifacts may be reused only when their dependency fingerprints remain valid, and the new run preserves the invalidation/reuse plan and result delta lineage.

---

AC-29 — Rule-stack resolution integrity

A PEF/EPD-like assessment that depends on category/programme rules cannot proceed from a bare product-category lookup alone. ZAYAZ preserves the authoritative sources, versions, programme/adoption context, applicability findings, precedence/override decisions and any governed human judgement used to form the resolved rule stack.

AC-30 — Rule-stack-sensitive comparability

A comparative claim cannot assume methodological comparability merely because two results share the same broad standard or impact method. Where category/programme rule stacks differ, ZAYAZ evaluates whether the relevant functional unit, system boundary, service life, scenarios, allocation, LCIA method and reporting/verification requirements remain compatible before supporting the comparison.

AC-31 — Factor-scope composition integrity

A calculation cannot combine direct, upstream, fuel-cycle or transmission/distribution factors whose included stages overlap unless an explicit governed composition rule proves that double counting is prevented.

AC-32 — Indicator-specific dataset fitness

Dataset eligibility is evaluated against the requested indicator and required flow set. Fitness for one indicator does not imply fitness for another.

AC-33 — Uncertainty semantic fidelity

An uncertainty distribution used in computation retains explicit mathematical centrality/dispersion semantics and source-to-normalized mapping provenance. Ambiguous or lossy mappings are rejected or routed.

AC-34 — Structural uncertainty separation

Allocation/method choice, scenario and proxy-hypothesis uncertainty remain distinguishable from parameter/data uncertainty and are not hidden inside one Monte Carlo interval.

AC-35 — Competing proxy visibility

Where more than one proxy is materially plausible, ZAYAZ preserves the alternatives, selection rationale and result sensitivity; a representative estimate never masquerades as measured primary evidence.

AC-36 — Jurisdictional publication eligibility

A numerically valid result cannot be communicated where the applicable jurisdiction, effective date, claimant role, product scope or channel conditions prohibit it.

AC-37 — Rights-operation specificity

Permission to obtain or internally calculate with a dataset does not imply permission to expose source values, derived outputs, downloads or public claims.

AC-38 — Dataset translation identity and conformance

A source inventory, third-party distribution package and ZAYAZ-normalized projection remain distinct versioned artifacts. Production eligibility requires mapping provenance and governed semantic/reference-result conformance, not merely successful import.

AC-39 — Modelling-principle isolation

Attributional and consequential calculations declare their modelling principle and cannot silently exchange inventories, factor roles or system-boundary logic. A consequential scenario cannot produce a PEF-authorised claim unless the governing rule stack explicitly permits it.

AC-40 — Marginal-assumption provenance

A marginal supplier or affected technology retains its evidence, temporal scope, model basis, alternatives and uncertainty and never appears as an observed EPU supplier relationship.

AC-41 — Future circular-credit integrity

A prospective reuse/recycling/recovery credit binds the recovered material quality, next application, scenario time, displaced process, substitution ratio and allocation method. Gross burdens, credits and net result remain separable, and prior benefit claims are detectable.

AC-42 — Declared/modelled boundary fidelity

A run and comparison distinguish declared system boundaries from processes actually modeled. Missing, unknown, not-reported and not-applicable states remain distinct; absent evidence is never filled from customary practice.

AC-43 — Evidence-exchange claim separation

A machine-readable footprint package does not imply that required evidence is complete, the calculation is reproducible, the method is admissible or the result is independently verified. Each state is separately decided and traceable.

AC-44 — External ontology identity integrity

An external ontology/vocabulary mapping resolves to existing canonical identities or records unresolved debt. It cannot mint duplicate EPU, method, dataset, result, assurance, signal or artifact identities.

AC-45 — Rights-aware reproducibility

A reproduction claim identifies the exact datasets, software, versions, execution context and rights prerequisites. Public ontology or code licensing never implies access to restricted calculation dependencies or permission to disclose their contents.

AC-46 — Consequential mechanism visibility

A consequential scenario preserves material displacement, behavioural, market and other response mechanisms as included, excluded, immaterial, unresolved or not applicable with evidence and limitations. Difficult quantification does not erase a material omission, and absence of evidence does not authorize invented values.

AC-47 — Technical suitability separation

Environmental results, technical performance constraints and any decision/optimization index remain separate. A lower environmental result cannot support a product recommendation when the alternative fails the governed functional or technical requirements.

---

23. Test strategy

23.1. Reference-vector tests

Maintain small, transparent PEF fixtures for which expected intermediate and final results are independently known.

Test each stage independently:

• source activity quantities;
• governed activity aggregation;
• LCI quantities;
• derived/proxy input handling;
• inventory-dataset fitness;
• service-life/replacement expansion where applicable;
• unit conversions;
• factor selection;
• dataset-vintage selection;
• temporal factor mapping where applicable;
• LCIA Method Package resolution;
• characterization-factor selection;
• characterization;
• normalization;
• weighting;
• allocation;
• stage aggregation;
• hotspot ranking.

23.2. Golden-product replay test

The battery golden specimen should become an end-to-end regression fixture with frozen evidence, source activity resolution/aggregation, method, LCIA package and dataset versions/vintages.

23.3. Factor resolver negative tests

Examples:

• correct geography but wrong lifecycle coverage;
• correct geography but invalid spatial resolution;
• correct dataset but wrong time interval/resolution;
• correct numeric unit but insufficient inventory representation for requested use;
• correct observation period but disallowed/superseded provider vintage under current-run policy;
• correct method but expired validity;
• method-compatible but licence-prohibited;
• preferred factor missing, valid fallback available;
• only prohibited fallback available;
• dataset mix requiring disclosure;
• unit mismatch;
• future factor accidentally used in historical run.

23.4. Uncertainty tests

Test:

• deterministic zero-uncertainty baseline;
• known synthetic distributions;
• fixed-seed replay;
• correlated inputs;
• sensitivity ranking;
• derived-model estimation error;
• activity-resolution sensitivity;
• service-life distribution;
• overlapping scenario distributions;
• unstable ranking detection;
• functional-unit ranking reversal.

23.5. Temporal and dataset-vintage tests

Test:

• product definition change;
• BOM change;
• activity source-resolution change;
• factor version change;
• same observation period published in two provider releases;
• later provider correction does not mutate historical replay;
• factor temporal-resolution change;
• hourly factor interval mapping;
• method version change;
• as-of valid time;
• as-known-at historical state;
• future scenario view;
• expired evidence.

23.6. Rights tests

Test both factor use and output projection. A result that was allowed under an internal-use licence must not automatically become publishable.

23.7. Comparability tests

Test alternatives with:

• equal technical performance;
• unequal service life;
• additional coatings/barriers;
• different product quantity required per function;
• different valid functional units;
• boundary mismatch;
• uncertainty overlap.

The comparison gate should distinguish calculation possible from comparative claim supportable.

23.8. ILCD/eILCD interoperability tests

Test:

• native schema validation;
• invalid source rejection;
• source hash preservation;
• model aggregation lineage;
• nomenclature mapping;
• mapping version change;
• normalized projection regeneration without source mutation.

23.9. LCIA Method Package tests

Use at least one governed EF package fixture and one non-PEF method fixture such as GLAM solely to test architecture generality.

Test:

• valid factor-set selection by impact category;
• midpoint versus damage mismatch rejection;
• time-horizon mismatch rejection;
• required spatial/pathway dimension preservation;
• cross-method factor mixing rejection;
• sensitivity package creates a distinct run;
• non-PEF method cannot produce a PEF-authorised claim unless a governing profile explicitly permits it.

23.10. Progressive-assessment tests

Test a product as it advances from early design to production state.

Verify:

• early proxy inputs remain visibly provisional;
• accepted early-design use is permitted by intended-use policy;
• claim-grade disclosure is rejected when maturity/evidence is insufficient;
• design/BOM maturity changes create a new run;
• resolved evidence replaces proxies only in the new lineage;
• Data Escalation asks only for evidence proportionate to the current decision/maturity context.

23.11. Service-life / replacement tests

Test:

• reference service life from evidence;
• context adjustment without source-evidence mutation;
• maintenance/replacement expansion over a fixed study period;
• boundary conditions where no replacement occurs;
• changed service life creates new scenario/run;
• uncertainty propagation and sensitivity ranking;
• EPU lifecycle events remain actual-state evidence and are not confused with modeled future replacements.

23.12. Activity-data resolution and aggregation tests

Test a controlled battery-production activity dataset at multiple resolutions.

Verify:

• source observations remain immutable;
• daily/monthly/annual aggregates reproduce the defined aggregation policy;
• rolling and calendar windows are distinguishable;
• process-level to factory-level aggregation retains lineage;
• hotspot ranking can change without corrupting the underlying observations;
• intended-use policy can accept one resolution and route/reject another;
• replay uses the original aggregation transform/version.

The tests should not hard-code the specific aggregation recommendation of any research paper unless an approved method profile adopts it.

23.13. Derived inventory evidence tests

Test:

• measured primary activity data;
• engineering estimate;
• process-simulation output;
• literature/data-mined proxy;
• predictive LCIA result.

Verify:

• generation method/model/tool/version and inputs remain traceable;
• geographical/temporal/technology applicability mismatch is routed/rejected according to policy;
• model/parameter uncertainty is retained where supplied;
• a predictive LCIA result cannot be used as process LCI;
• replacement with primary evidence creates a new lineage and triggers dependency analysis.

23.14. Inventory dataset fitness tests

Test:

• unit-process LCI;
• partly aggregated process dataset;
• fully aggregated system process;
• scalar lifecycle/emission factor;
• direct LCIA result.

Verify that:

• a permitted screening use can accept an aggregate representation where policy allows;
• process-hotspot analysis rejects/routes a dataset without required process detail;
• multi-impact LCIA rejects/routes a source lacking required elementary flows;
• scenario substitution does not pretend to modify background processes hidden inside an opaque aggregate factor;
• fitness decisions remain explainable and replayable.

---

23.15. Data-quality admission tests

Test:

• candidate above and below the governed minimum quality floor;
• quality admission is evaluated before candidate ranking;
• DQI/pedigree dimensions remain separately queryable;
• quantitative uncertainty overrides/defaults follow the selected profile rather than a hidden engine constant;
• changing the quality/admission profile creates a new governed run/decision rather than rewriting history.

23.16. Dependency-bounded recalculation tests

Test:

• one supplier activity update invalidates only its dependent calculation/result paths;
• one factor correction invalidates all dependent results using that exact factor/version and no unrelated results;
• BOM/composition change propagates through the affected product subtree;
• method/LCIA-package change can invalidate the broader governed calculation scope;
• unaffected cached/sub-results are reused only when dependency fingerprints remain unchanged;
• replacement of a derived/proxy input with primary evidence produces a new result and explicit delta;
• no stale TrustGate/disclosure state survives a material dependent recalculation.

23.17. Multidimensional factor and reproducibility fixture

Use a rights-permitted multidimensional dataset such as the W38 aquaculture fixture to test simultaneous resolution across domain/process context, geography, lifecycle stage, reference year, scenario/pathway and source version. Where reproduction code is supplied, verify source/hash lineage and reference outputs without making external code runtime authority.

---

23.18. Rule-stack resolution tests

Test:

• one product with a single unambiguous applicable PCR/rule stack;
• a core rule plus adopted complementary PCR;
• a complementary rule that exists but is not adopted by the selected programme;
• two defensibly applicable PCRs requiring documented governed choice;
• product-specific rule overriding a general rule;
• stricter-requirement case where apparent hierarchy alone is insufficient;
• PCR/programme-rule version change across effective dates;
• historical calculation replay against the original resolved rule stack;
• comparability check where two EPD-like results use materially different rule stacks;
• dependency-impact analysis when a rule-stack component changes.

The fixtures must use authoritative rule artifacts or controlled synthetic equivalents. Practitioner commentary may motivate the tests but is not itself runtime policy.

23.19. Factor-scope and decomposition tests

Test direct, upstream, fuel-cycle and transmission/distribution factors independently and in permitted compositions. Reject overlapping stage coverage and require the receipt to explain exclusions and composition.

23.20. Indicator-specific fitness tests

Use one dataset that satisfies RMI-style required flows but lacks flows required for a TMR-style indicator. Accept the former and reject/route the latter without changing the dataset's general quality score.

23.21. Uncertainty interoperability tests

Use controlled normal/lognormal reference vectors across supported source formats. Verify centrality/dispersion meaning, transformation provenance and round-trip behavior; reject deliberately ambiguous mappings.

23.22. Allocation and proxy-hypothesis tests

Run multiple governed allocation choices and multiple plausible proxy inventories. Preserve each result lineage, show decision sensitivity and prevent a representative estimate from overwriting the hypotheses.

23.23. Jurisdictional calculation/disclosure tests

Test authority and effective-date transitions, claimant-role eligibility, product scope and communication channel. Verify that calculation and disclosure permissions can differ and that historical decisions replay.

23.24. Dataset translation and conformance tests

Use one authoritative source inventory and at least two technical representations. Preserve source/distribution/projection hashes, validate flow/unit/property/compartment mappings, run reference vectors and reject an import whose schema succeeds but whose result parity or semantic mapping fails.

23.25. Attributional/consequential isolation tests

Run controlled attributional and consequential variants for the same decision context. Verify method-principle identity, factor-role eligibility, system-boundary differences and result lineage; reject a consequential inventory in a PEF profile that does not authorize it.

23.26. Marginal-data resolution tests

Test identified and ambiguous marginal suppliers/technologies, alternative candidates, temporal scope, market-model evidence and uncertainty. Prove that scenario assumptions do not mutate EPU actual supplier relationships.

23.27. Future lifecycle-transition and credit tests

Test reuse, high-grade recycling, cascading and recovery across future years. Resolve recovered quality, next use and future displaced processes; preserve gross burdens/credits/net results; reject stale background factors and duplicate benefit ownership.

23.28. Boundary-coverage assurance tests

Test declared and modeled boundaries that fully align, omit a known process, contain an unknown, report no information, or mark a process not applicable. Route invalid comparisons and verify no absent field is inferred from customary practice. Use the W42 tyre dataset only as a rights-permitted fixture; do not make its SBCI formula runtime authority.

23.29. External design-object binding test

Bind an EPU configuration and governed CalculationRun result to a controlled BIM-like external object. Verify source attribute change triggers dependency analysis/new result, lifecycle modules and provenance remain attached, and the external system cannot become calculation authority.

23.30. Footprint evidence-exchange assurance tests

Use the W43 PEFDPP ontology/battery package only as a rights-permitted external fixture. Verify schema/ontology parsing, canonical mapping, required/present/absent evidence findings, dependency/license manifest, independent reference-result reproduction where dependencies are available, and separate machine-readable/completeness/reproducibility/admissibility/verification decisions. An OWL-open-world absence must fail or route a closed completeness profile when the field is required.

23.31. External ontology mapping tests

Map controlled external product, flow, method and result terms to canonical ZAYAZ references. Reject duplicate identity minting, ambiguous mappings and semantic loss that exceeds the governed profile. Version changes create new mapping/conformance evidence and never rewrite the external source or prior receipt.

23.32. Consequential response-completeness tests

Model one decision with substitution/displacement plus behavioural and market-response mechanisms. Test quantified, qualitative, immaterial, evidence-unavailable, unresolved and not-applicable states; route a material undisclosed exclusion; preserve uncertainty without fabricating distributions; prove that the scenario cannot enter an attributional PEF claim.

23.33. Remanufacturing equivalence fixture

Compare new and remanufactured electrical/electronic equipment using remaining useful life, equivalent service, operating efficiency, replacement assumptions and modeled use phase. Reject or qualify a comparison that omits a material use-phase process or treats missing evidence as not applicable.

23.34. Purpose-specific product-data and technical-performance fixtures

Use the W43 automotive DPP case to test governed actor/product/intended-use evidence profiles without weakening method requirements. Use the recycled-concrete case to prove that environmental metrics, mechanical constraints and study-specific decision indices remain separate and that a technically inadmissible option cannot become a ZAYAZ recommendation.

---

24. Observability

PEF/LCA observability should answer both engineering and sustainability questions.

Operational metrics should include conceptually:

• calculation success/failure rate;
• execution latency by product graph size;
• calculation volume by assessment maturity/intended use;
• activity-data resolution mismatch / routing frequency;
• aggregation transformations by source/target resolution;
• material hotspot changes attributable to aggregation sensitivity;
• derived/proxy data proportion and materiality;
• inventory-dataset fitness rejection/routing frequency;
• data-quality admission rejection/fallback frequency;
• factor-resolution fallback frequency;
• provider dataset revision/supersession frequency;
• dataset translation/import conformance failure and mapping-loss frequency;
• source/distribution/projection version drift;
• time-series factor coverage gaps;
• unresolved factor count;
• factor-scope overlap / double-count prevention findings;
• requested-indicator / required-flow fitness failures;
• uncertainty mapping ambiguity / loss findings;
• competing-proxy conclusion sensitivity;
• jurisdiction/claimant/publication gate rejections;
• LCIA package compatibility failures;
• dataset-rights rejection count;
• ILCD/eILCD import/validation failure rate;
• primary/secondary/proxy data proportions;
• uncertainty-run cost and sample count;
• supplier-request completion rate;
• comparative-equivalence findings;
• service-life sensitivity findings;
• attributional/consequential principle mismatch findings;
• marginal-supplier ambiguity and sensitivity findings;
• future substitution-credit magnitude, prior-claim and double-count findings;
• declared-versus-modeled boundary coverage gaps by state;
• exchange-package schema, completeness, mapping-loss, reproducibility, method-admissibility and verification findings by intended use;
• consequential response mechanisms by included/excluded/unresolved state and materiality;
• recalculations triggered by product/activity-resolution/derivation/factor/method/dataset-vintage changes;
• dependency invalidation breadth, recomputed-node count and proven-safe reuse ratio;
• verifier finding frequency and category;
• replay drift events.

Do not expose confidential licensed factor values or sensitive activity/source data in logs.

---

25. Key risks and architectural controls

Risk	Why it matters	Architectural control
Monolithic PEF engine	Method, data and policy become inseparable and hard to evolve.	Separate governed profiles/registries from execution engines.
Single category_rule_ref treated as the complete methodology basis	Programme/core/complementary/adoption/interpretation rules can be omitted, producing the wrong assessment under an apparently valid PCR.	Rule Stack Resolution + authoritative applicability/adoption/precedence evidence + verifier-visible receipt.
Programme interpretation or PCR adoption changes silently	Historical and current declarations can appear comparable despite being produced under different effective rule stacks.	Versioned rule-stack resolution + effective-date semantics + dependency impact analysis.
LCIA method reduced to one factor table	Category-specific spatial, pathway, indicator or time-horizon semantics can be lost or mixed incorrectly.	Governed LCIA Method Package + compatibility validation.
Factor scopes composed without stage accounting	Direct, upstream, fuel-cycle and network-loss adjustments can overlap and double count.	Explicit included/excluded stages + decomposition relationship + scope-overlap rejection.
Dataset declared universally fit after one successful indicator	A source may support one indicator while lacking flows required by another.	Indicator-specific Inventory Dataset Fitness + required-flow coverage evidence.
Uncertainty fields converted by label alone	Mean/geometric mean/log-space parameters can be confused across formats and corrupt distributions.	Serialization-independent mathematical semantics + mapping provenance + ambiguity rejection.
Method or proxy alternatives collapsed into one interval	Structural uncertainty disappears behind parameter sampling and can reverse conclusions.	Separate governed runs/hypotheses + attributable sensitivity.
Jurisdiction or claimant context ignored	A valid calculation may be communicated by an ineligible actor or outside the effective rule context.	Jurisdictional Method/Disclosure Profile + TrustGate publication gate.
Hidden activity-data aggregation	A total can look stable while process/time hotspots and engineering signals disappear.	Activity Data Resolution & Aggregation context + immutable source observations + replayable transforms.
Research aggregation recommendation hard-coded as policy	A useful case-study recommendation can be mistaken for a legal/method requirement.	Method authority separation; only governed profiles define required resolution/windows.
Derived/predictive data masquerades as measured LCI	Creates false provenance and may invent process/flow detail the model never produced.	Derived Inventory Evidence + explicit LCI/LCIA output scope + applicability/uncertainty gate.
Pre-aggregated factor masquerades as process inventory	Hotspot, scenario and multi-impact analysis can appear more detailed than the underlying data permits.	Inventory Dataset Fitness Assessment + representation-aware resolver.
Factor chosen by nearest label	Produces plausible but methodologically wrong results.	Context-aware Factor Resolver + receipt.
Quality used only as a ranking score with no admission floor	A superficially good match can be selected even when evidence is below the minimum acceptable quality for the intended use.	Governed data-quality admission before candidate ranking + replayable quality dimensions.
Provider revision silently overwrites old factor	Breaks replay and obscures which data vintage produced the historical result.	Immutable source snapshot + provider-vintage identity + impact analysis.
Annual average used where time resolution matters	Can hide material operational carbon variation.	Governed temporal-resolution rules + activity/factor resolution compatibility.
DQR used as uncertainty	Hides statistical uncertainty and creates false precision.	Separate quality and uncertainty contracts.
Latest factor silently replaces historical factor	Breaks audit/replay.	Version/vintage pinning + immutable CalculationRun.
Early-design LCA presented as claim-grade	Provisional assumptions can appear more authoritative than the underlying product knowledge permits.	Progressive Assessment Context + purpose-specific TrustGate gate.
Supplier questionnaire explosion	Low response and unnecessary burden.	Data Escalation Planner + No Ask Before Reuse + maturity-aware acquisition.
Service-life assumptions hidden in model defaults	Replacement/maintenance quantities can materially change whole-life results without visible evidence.	Governed service-life/replacement model + uncertainty + lineage.
Invalid product comparison	Same unit can hide different functionality, lifetime or compensatory processes.	Comparability Receipt + comparative-claim gate.
Scenario overwrites actual state	Destroys product truth/history.	EPU scenario overlay semantics.
Licensed data leaks through SaaS	Contractual/IP exposure.	Rights binding + disclosure projection gate.
Native EF/ILCD data flattened without lineage	Loses interoperability, source semantics and auditability.	Preserve native artifact + versioned normalized projection.
Distribution package treated as the scientific source	A mapping/import version can obscure the authoritative inventory version and rights chain.	Distinct source/distribution/projection identity + translation receipt + reference-result conformance.
Schema-valid import assumed semantically equivalent	Units, flows, compartments or providers can map incorrectly while the file still loads.	Mapping manifest + lossy/unresolved findings + governed cross-representation reference vectors.
Consequential inventory enters attributional/PEF execution	Marginal/affected-process assumptions can replace accounting data and change the question being answered.	Method-principle identity + factor-role eligibility + incompatible-profile rejection.
Marginal supplier recorded as actual supplier	Scenario evidence corrupts product truth and supplier lineage.	Marginal Data Resolution evidence + EPU actual-state isolation.
Future recycling credit uses today's displaced process	Long-horizon benefits can be overstated as background systems decarbonize or material quality changes.	Scenario-year displaced-process resolution + recovered-quality/next-use evidence + sensitivity.
Avoided benefit claimed across multiple product lives	Circular scenarios can double count one substitution benefit across actors or transitions.	Benefit ownership/prior-claim evidence + gross/credit/net separation.
Declared boundary accepted without modeled coverage	A nominally complete study may omit material processes and support an invalid comparison.	Boundary Coverage Assessment + explicit missing/unknown/not-reported/not-applicable states.
Machine-readable package treated as complete or verified	An ontology/DPP payload can parse successfully while omitting required evidence or lacking reproducible dependencies.	Separate representation, completeness, reproducibility, admissibility and verification decisions + closed evidence profile.
External ontology creates duplicate canonical identities	Equivalent products, flows, methods or results fragment lineage and governance.	Versioned mapping manifest + canonical registry resolution + unresolved-debt routing.
Open code/ontology assumed to make the calculation reproducible	Restricted inventories, runtime dependencies or disclosure rights may still block independent reproduction.	Dependency/right manifest + operation-specific rights checks + explicit reproduction result.
Consequential scenario includes benefits but hides response mechanisms	Selective inclusion can overstate decision benefits and understate uncertainty.	Response-mechanism inventory + materiality/evidence rationale + exclusion/uncertainty findings.
Circularity silently modifies footprint	Creates undocumented composite methodology.	Parallel governed result families.
LLM becomes method authority	Hallucination/non-reproducible compliance.	Pergamum → governed registry → deterministic compute; ZARA explains/orchestrates only.
One auditor correction changes global policy	Local evidence becomes accidental governance.	Override lineage + proposal/review before policy learning.
EF method update forces data migration	Historical outputs become unstable.	Method-version coexistence.
Portfolio recalculation is all-or-nothing	Expensive and operationally noisy.	Dependency graph + impact analysis + dependency-bounded incremental recomputation.
Incremental recomputation invalidates too little or reuses stale artifacts	A fast update can silently leave obsolete product results or assurance state in place.	Dependency-closure proof + invalidation/reuse manifest + stale-result negative tests.

---

26. What should happen to the weekly shortlist from now on

The Friday research stream should become a continuous architecture intake for this roadmap.

Each Friday brief receives an ISO cohort tag:

YYYY-Www

Example:

2026-W38

Every retained item is then classified into one or more implementation delta types:

METHOD_DELTA
FACTOR_DATA_DELTA
QUALITY_DELTA
UNCERTAINTY_DELTA
SUPPLIER_DATA_DELTA
SCENARIO_DELTA
ASSURANCE_DELTA
RIGHTS_DELTA
INTEROPERABILITY_DELTA
PERFORMANCE_DELTA
PRODUCT_STRATEGY_DELTA
NO_ACTION
WATCH

For each item, the weekly implementation analysis should answer:

1. Cohort — which YYYY-Www weekly intake introduced the item?
2. Finding — what is genuinely new?
3. Authority — research insight, technical guidance, normative method or legal requirement?
4. ZAYAZ relevance — which existing capability does it change?
5. Architecture delta — new contract, rule, dataset metadata, engine capability, test or no change?
6. Affected canonical docs — which ZAYAZ specifications need review?
7. Data impact — factors, datasets, schemas, evidence or rights?
8. Computation impact — deterministic, uncertainty, temporal, scenario or optimization?
9. Assurance impact — TrustGate/verifier/replay consequences?
10. Priority — now / next / watch?
11. Roadmap placement — which Roadmap 0–6 work package should absorb it?
12. Integration status — proposed / accepted / implemented / watch / superseded?

26.1. Weekly intake lifecycle

The recommended lifecycle is:

Friday research shortlist
        ↓
YYYY-Www cohort assigned
        ↓
architecture-delta analysis
        ↓
NO_ACTION / WATCH ──────────────> weekly brief only / validation fixture where useful
        │
        └── meaningful delta
               ↓
         canonical roadmap update
               ↓
         affected-spec review
               ↓
         Hecate Need where implementation is justified
               ↓
         implementation / validation

This prevents the roadmap from becoming a bibliography while preserving a clear lineage from research discovery to architectural change.

26.2. Versioning rule

This document should be versioned when a weekly finding materially changes the approved architecture, governed contracts, implementation sequence or acceptance criteria.

Minor observations can remain in the research brief until they cross that threshold.

A source appearing in multiple weeks should retain its original cohort tag and receive an additional update note only when a substantive new version, dataset release, correction or implementation consequence appears.

---

27. Approved architectural decisions — 5 September 2026

The following ten decisions are approved as the architectural baseline for this roadmap.

1. EPU Product Graph is the canonical product-system substrate for PEF/LCA.
2. PEF is a cross-module capability, not a new top-level ZAYAZ Module.
3. Method rules are governed profiles consumed by compute engines; engines do not define PEF policy.
4. Factor resolution produces a first-class explainable receipt.
5. Dataset rights/licensing is evaluated as part of factor eligibility and disclosure.
6. Data quality, statistical uncertainty, source authority and TrustGate trust remain separate dimensions.
7. Supplier primary-data acquisition is hotspot/sensitivity driven and reuses the EPU Supplier Contribution model.
8. Prospective/scenario LCA uses EPU scenario overlays and never mutates actual product state.
9. Existing PEF-ME, LCA-OPTI, PEFX and fact_pef_run assets are historical inputs to be re-evaluated, not blindly expanded. PEF-ME, LCA-OPTI and PEFX were created before much of the current ZAYAZ architecture. Their legacy/PDF material shall be transferred into current Docusaurus specifications using the governed documentation-transfer process, made Hecate-ready, and then evaluated against this roadmap, the EPU series and other applicable canonical ZAYAZ specifications. fact_pef_run shall be evaluated in the same architectural reconciliation as the persistence model is defined. The outcome may be update, narrowing, decomposition, reuse or deprecation of implementation semantics while preserving governed identity where applicable.
10. The first implementation is one governed golden product vertical slice, then the architecture scales to product portfolios.

These decisions allow Roadmap 0 to move from conceptual framing into canonical contract definition without requiring a second redesign of the PEF/LCA capability.

27.1. W37 accepted architecture refinements — 12 September 2026

The W37 cohort does not overturn the ten approved decisions. It refines their implementation consequences:

1. A Method Profile selects a governed LCIA Method Package; LCIA category/factor semantics are not collapsed into one generic factor table.
2. Product-development maturity and intended decision context are governed independently of environmental methodology.
3. Dataset observation period, provider release/vintage and ZAYAZ capture time are separate identities relevant to factor eligibility and replay.
4. Service-life and replacement assumptions become governed whole-life calculation inputs when they materially affect quantities, while authoritative product evidence remains immutable.
5. New external analyses do not create new ZAYAZ architecture when the existing product graph/factor model already represents the required semantics; such work may instead become a validation fixture.

These refinements remain subject to canonical contract/object-boundary review before implementation identifiers or persistence structures are created.

27.2. W38 accepted architecture refinements — reconciled 19 September 2026

The W38 cohort further refines the data and computation boundary without changing the baseline module/component model:

1. A governed data-quality admission floor is distinct from later candidate ranking, uncertainty and TrustGate trust. Where an applicable profile defines a minimum evidence/quality level, candidates below it are ineligible even if other lookup dimensions match.
2. Activity data has its own governed observation-resolution and aggregation lineage, separate from factor temporal/spatial resolution.
3. Derived/proxy/predictive environmental evidence must preserve how it was generated, its applicability, uncertainty, validation and reproducibility evidence, and whether it represents LCI or only a derived LCIA result.
4. Inventory representation and granularity are purpose-sensitive fitness dimensions: a pre-aggregated factor is not equivalent to process-based LCI.
5. Dependency-bounded incremental recalculation is a governed correctness requirement, not merely a performance optimisation. A change must invalidate all and only dependent artifacts while proving the safe reuse of unaffected results.
6. Method and intended-use profiles govern required data resolution/representation; research recommendations about aggregation, multifunctionality or generated-data hierarchies do not become runtime policy automatically.
7. Domain-specific factor dimensions should be modeled through governed dataset/applicability semantics rather than proliferating universal columns for every source-domain key.
8. External methods/datasets that the current architecture already represents should become validation fixtures rather than trigger unnecessary new objects.
9. Practitioner production experience can reveal architecture gaps when it is treated as evidence, not authority. W38 adds governed Rule Stack Resolution because authoritative PCR/programme sources confirm the practitioner's observation that the applicable rule basis is assembled, versioned, programme-dependent and sometimes judgement-bearing.

The primary W38 findings now follow the exact Friday shortlist supplied after the initial Saturday run. The clinker-inventory and agrivoltaics papers remain explicitly labelled as Saturday supplemental sources.

27.3. W39 accepted architecture refinements — reconciled 10 October 2026

1. Factor scope, included/excluded stages and decomposition relationships are eligibility semantics; composition must prevent double counting.
2. LCIA packages preserve realm, safeguard/area-of-protection, spatial and average/marginal aggregation choices.
3. Allocation and method-choice uncertainty remain separately attributable from parameter uncertainty.
4. Natural-language model editing remains proposal-only and subject to deterministic validation and governed method authority.

27.4. W40 accepted architecture refinements — reconciled 10 October 2026

1. Method and disclosure applicability may depend on jurisdiction, effective date, claimant role, product scope and publication channel.
2. Uncertainty is normalized by mathematical meaning, not field-name similarity; ambiguous mappings are rejected or routed.
3. Supplier-resolution evidence strengthens existing escalation and activity-resolution controls without creating a universal finer-is-better rule.
4. Dataset release identity and licence variant remain pinned independently of scientific suitability.

27.5. W41 accepted architecture refinements — 10 October 2026

1. Inventory Dataset Fitness is indicator-specific and evaluates the required flow set.
2. Competing proxy hypotheses and their conclusion sensitivity remain visible; a representative estimate cannot erase them.
3. Process-level hotspot and comparative-method studies validate existing architecture and do not create new canonical objects when no gap exists.
4. Industry adoption surveys remain product-strategy signals with source/version provenance, not normative architecture inputs.

These refinements add no module, Component, Engine, CMID, SSSR signal or persisted schema identity. Registration and lifecycle decisions remain governed debt.

27.6. W42 accepted architecture refinements — 17 October 2026

1. Source inventory, distribution package and normalized projection are separate versioned identities. Translation requires a mapping manifest and semantic/reference-result conformance before production eligibility.
2. Attributional and consequential modelling principles remain isolated. The Method Profile determines the calculation question, system-boundary logic and eligible factor roles.
3. Marginal suppliers and affected technologies are modeled evidence, not product truth. They remain outside EPU actual supplier relationships and retain temporal/model/uncertainty lineage.
4. Future circular credits are time- and transition-dependent. Recovered material quality, next use, future displaced process, substitution ratio and allocation method are explicit; gross burdens, credits and net results remain separable.
5. Declared and modeled system boundaries are different claims. Coverage evidence and missing/not-reported/not-applicable states participate in comparability and assurance.
6. BIM-linked LCA does not justify a new core engine. External design objects consume governed EPU configurations/results and cannot become calculation authority.

These refinements add no new Module, Component, Engine, CMID, SSSR signal, KISMET kernel/binding, policy identity, schema identity or persistence contract.

---

27.7. W43 accepted architecture refinements — 24 October 2026

1. Machine-readable representation, evidence-profile completeness, reproducibility, method admissibility and independent verification are separate claims. Exchange packages preserve the evidence and decision behind each state.
2. External ontology mappings cannot create parallel ZAYAZ truth. Versioned mapping manifests resolve canonical identities, retain semantic loss and route unresolved concepts as governed debt.
3. Open-world absence is not positive completeness evidence. Governed uses require deterministic validation against a closed evidence profile while preserving unknown and unresolved states.
4. Consequential scenarios preserve response-mechanism completeness and uncertainty symmetry. Displacement, behavioural and market effects are included, excluded, immaterial or unresolved with evidence; ZAYAZ does not fabricate missing values.
5. Remanufacturing, actor-specific DPP priorities and environmental-mechanical optimisation do not create new core objects. They remain conformance/product-strategy fixtures under existing comparability, data-fitness and technical-performance separation.

These refinements add no new Module, Component, Engine, CMID, SSSR signal, KISMET kernel/binding, policy identity, schema identity, artifact type, transport contract or persistence contract.

28. Open governed debt

The following gaps are intentionally visible because current canonical architecture does not support guessing them:

• owning Component for PEF-ME after governed migration/reconciliation;
• owning Component for LCA-OPTI after governed migration/reconciliation;
• final responsibility boundary for PEFX after governed migration/reconciliation;
• canonical PEF run-request contract;
• canonical Rule Stack Resolution / Category Rule Resolution Receipt identity/schema;
• canonical rule-source families and authoritative precedence/adoption/effective-date semantics for PCR/PEFCR/programme stacks;
• exact boundary between deterministic rule resolution and governed human judgement when multiple valid rules remain;
• programme-operator identity/mapping and programme-rule lifecycle model;
• canonical method-profile schema/registry identity;
• canonical LCIA Method Package schema/registry identity and relationship to existing compute-method/dataset registries;
• exact activity/emission-factor versus characterization-factor resolver implementation boundary;
• canonical Progressive Assessment Context identity/schema;
• exact mapping from product-development maturity into TrustGate intended-use policy;
• exact boundary for ActivityData source-resolution / aggregation metadata between EPU product evidence and computation/run contracts;
• canonical data-quality admission profile identity and vocabulary, including whether pedigree/DQI dimensions reuse an existing data-quality contract;
• governed vocabulary/registry for derived-data generation methods and derivation classes;
• exact Derived Inventory Evidence identity/schema and whether it reuses a broader evidence/derivation contract;
• inventory dataset representation/granularity vocabulary and fitness-policy identity;
• whether Inventory Dataset Fitness is persisted as a receipt/finding or remains part of run resolution evidence;
• mapping between Progressive Assessment Context and activity-resolution / inventory-granularity requirements;
• governed semantics for calendar, rolling and method-specific activity aggregation windows;
• exact policy for direct predicted LCIA results in screening/optimization use cases;
• canonical dependency/invalidation graph contract for footprint recomputation and proof-of-reuse semantics;
• service-life/reference-life object boundary between EPU ProductSpecification / Claim / evidence and modeled run/scenario assumptions;
• service-life/replacement schema/registry identity if a distinct governed contract is required;
• canonical Comparability Receipt identity/schema;
• factor-resolution policy registry identity;
• provider dataset vintage/snapshot identity and supersession semantics within Dataset Registry;
• temporal factor-series contract;
• ILCD/eILCD adapter contract and mapping registry identity;
• PEF/LCA CMID set;
• SSSR signal mappings;
• target persistence/FK mapping from current fact_pef_run prototype;
• exact TrustGate intended-use profiles and governed thresholds;
• exact uncertainty/replay profiles;
• canonical uncertainty mathematical-semantics and source-format mapping vocabulary, including ambiguous/lossy conversion findings;
• canonical factor-scope/decomposition vocabulary and overlap policy;
• canonical required-flow-set identity and coverage thresholds for indicator-specific dataset fitness;
• canonical proxy-hypothesis/representative-estimate contract boundary;
• canonical jurisdiction/authority/claimant/publication-context profile identity and relation to Pergamum Pulse and TrustGate;
• canonical inventory-modelling-principle vocabulary and attributional/consequential compatibility policy;
• canonical marginal-data/affected-process resolution evidence boundary and relation to EPU actual supplier state;
• source-inventory versus distribution/import-package versus normalized-projection identity within Dataset Registry;
• canonical Dataset Translation / Projection Receipt identity/schema and conformance-profile registry;
• governed reference-flow/unit/property/compartment mapping vocabulary and parity thresholds;
• canonical lifecycle-transition/substitution evidence boundary, including benefit ownership and prior-claim semantics;
• governed recovered-material quality/grade and feasible-next-use vocabularies;
• canonical declared-versus-modeled boundary coverage contract and missing/unknown/not-reported/not-applicable vocabulary;
• review boundary for kernels/bindings/policies under the registered KISMET framework and contract specification;
• canonical Footprint Evidence Exchange / Reproducibility Receipt identity, schema, persistence and CSI transport boundary;
• governed evidence-completeness profiles by method/intended use, including deterministic treatment of external open-world representations;
• canonical external ontology/vocabulary mapping registry and semantic-loss policy;
• exact reuse boundary between PEF exchange/reproducibility evidence and existing TrustGate validation evidence/replay artifacts;
• governed consequential response-mechanism vocabulary, materiality policy and scenario/uncertainty ownership boundary;
• dataset/software entitlement evidence required to assert independent reproduction without disclosing restricted dependencies;
• dataset licence agreements required for commercial multi-tenant factor sources, including operation-specific permissions for calculation, derived output and redistribution.

---

29. Source reports and papers

The roadmap source registry is organised by weekly cohort. Future items should be added only when they create a meaningful architecture, data, computation, assurance, rights, interoperability or product-strategy delta, or when a WATCH item is retained because it is a particularly valuable future validation fixture.

29.1. 2026-W36

29.2. Normative / implementation baseline

29.3. 2026-W35

The exact text of the 28 August 2026 automation output is not available to this authoring session. The cohort below is therefore reconstructed from authoritative public releases in that week and becomes the canonical 2026-W35 roadmap intake unless later reconciled against the recovered original report.

29.4. 2026-W37

The exact text of the 11 September 2026 Friday automation output is not available to this architecture-integration session. The cohort below is therefore reconstructed from authoritative and peer-reviewed sources published or updated during 9–11 September 2026.

29.5. 2026-W38

The exact Friday shortlist for 18 September 2026 was supplied after the initial Saturday architecture integration and reconciled into version 0.4.1 on 19 September 2026. The primary Friday cohort is Canada, Husmann et al., Köck et al., Auto-LCA, and the aquaculture dataset, plus the explicit JRC/EF surveillance result. Edwards et al. and Jouannais et al. are retained as clearly labelled Saturday supplemental sources.

Primary Friday cohort

Saturday supplemental architecture-review sources

Practitioner supplemental source

29.6. 2026-W39

The exact Friday cohort supplied for this integration is retained. Items are classified by authority in section 4.9; none is treated as PEF normative authority.

29.7. 2026-W40

The exact Friday cohort supplied for this integration is retained. Legal authority, official dataset material and research evidence are kept distinct.

29.8. 2026-W41

This is the primary Friday Research Intake for the 10 October 2026 Saturday integration. The source set is retained exactly; the partner survey pages are one intake item and remain jointly cited.

29.9. 2026-W42

This is the exact primary Friday Research Intake for the 17 October 2026 Saturday integration. The source set and cohort tag are preserved; no source is treated as normative PEF authority.

29.10. 2026-W43

This is the exact primary Friday Research Intake for the 24 October 2026 Saturday integration. The cohort tag and five-source set are preserved. All five papers are peer-reviewed research rather than normative PEF/DPP authority; the PEFDPP Zenodo package is a linked versioned research artifact. No new Commission/JRC EF normalisation or weighting package was identified.

---

---

Footnotes

1. Sara Pinto et al., “Harmonisation of life cycle assessment practices in Horizon Europe battery technology projects,” Environmental Impact Assessment Review, Vol. 121, September 2026, 108574. https://doi.org/10.1016/j.eiar.2026.108574 ↩ ↩²

2. Zhiyuan Yang et al., “From EEIO hotspot screening to supplier-specific Scope 3 data prioritization: a public-data framework for low-carbon transmission and distribution equipment procurement in China,” Vol. 31, September 2026, 200364. https://doi.org/10.1016/j.rcradv.2026.200364 ↩ ↩² ↩³

3. Mohammad Ali Rajaeifar et al., “Prospective life cycle assessment for photovoltaic electricity systems: Key issues and recommendations,” Renewable and Sustainable Energy Reviews, Vol. 237, September 2026, 117059. https://doi.org/10.1016/j.rser.2026.117059 ↩ ↩²

4. “Probabilistic Whole Life Cycle Greenhouse Gas Displacement Factors for Timber Frame House External Walls,” Building and Environment, available online 20 August 2026, 115158. https://doi.org/10.1016/j.buildenv.2026.115158 ↩ ↩²

5. International Energy Agency, Emissions Factors 2026, scheduled for release 25 September 2026. https://www.iea.org/data-and-statistics/data-product/emissions-factors-2026 ↩ ↩² ↩³

6. International Energy Agency, Life Cycle Upstream Emissions Factors 2026, scheduled for release 25 September 2026. https://www.iea.org/data-and-statistics/data-product/life-cycle-upstream-emissions-factors-2026 ↩ ↩² ↩³

7. Peter Fantke et al., “A Global Consensus Life Cycle Impact Assessment Method (GLAM): impacts on human health,” The International Journal of Life Cycle Assessment, Vol. 31, Article 171, published 9 September 2026. https://doi.org/10.1007/s11367-026-02742-w ↩ ↩²

8. Jonas Keller, Matthias Müller and Michael Held, “A V-model for LCA: scheduling life cycle assessment within product development,” The International Journal of Life Cycle Assessment, Vol. 31, Article 174, published 11 September 2026. https://doi.org/10.1007/s11367-026-02746-6 ↩ ↩²

9. International Energy Agency, MODS & IEA Data Services Group Package / Emissions Factors Package, September 2026 release schedule showing the 11 September 2026 update and monthly/quarterly emissions-factor integration. https://www.iea.org/data-and-statistics/data-product/mods-iea-data-services-group-package ↩ ↩²

10. Sara Sadeghi, Marzieh Riahinezhad, Elnaz Esmizadeh and Thomas Park, “The overlooked impact of materials’ reference service life on the whole-building life cycle assessment results,” The International Journal of Life Cycle Assessment, Vol. 31, Article 173, published 11 September 2026. https://doi.org/10.1007/s11367-026-02731-z ↩ ↩²

11. International Energy Agency, “Assessing emissions from LNG supply and abatement options,” published 10 September 2026. https://www.iea.org/reports/assessing-emissions-from-lng-supply-and-abatement-options ↩ ↩²

12. Environment and Climate Change Canada, Fuel Life Cycle Assessment Model Methodology, September 2026, published 14 September 2026. https://www.canada.ca/en/environment-climate-change/services/managing-pollution/fuel-life-cycle-assessment-model/methodology.html ↩ ↩² ↩³

13. Jana Husmann, Johanna Holsten, Gabriela Ventura Silva et al., “Life cycle assessment of battery cell production in the context of the European Union batteries regulation: the influence of data aggregation and multifunctionality handling,” Journal of Industrial Ecology, published 14 September 2026. https://doi.org/10.1007/s44498-026-00169-y ↩ ↩² ↩³

14. Bianca-Maria Köck, Kurt Varmuza, Walter Wukovits et al., “Life cycle assessment of chemicals: data generation and uncertainty,” Monatshefte für Chemie - Chemical Monthly, published 16 September 2026. https://doi.org/10.1007/s00706-026-03527-5 ↩ ↩²

15. Shixiong Guo and Xinzhi Wang, “Automated Product Carbon Footprint Estimation via Low-Latency Neural Language Processing in Multilingual, Real-Time Supply Chains,” Big Data, OnlineFirst, published 9 September 2026. https://doi.org/10.1177/2167647X261481461 ↩ ↩²

16. Yunjie Zhang et al., “Flavor-enhancing Amino Acid Demand Has Driven a Multi-decade Rise in Chinese Aquacultural N₂O Emission Intensity,” Mendeley Data, Version 3, published 15 September 2026, CC BY 4.0. https://doi.org/10.17632/w2zcybcyhg.3 ↩ ↩²

17. European Commission / Joint Research Centre / EPLCA, Environmental Footprint, last updated 7 July 2026 at the time of the W38 surveillance check. https://eplca.jrc.ec.europa.eu/EnvironmentalFootprint.html ↩ ↩²

18. Pippa Edwards, Wilson Ricardo Leal da Silva, Paul Fennell et al., “Toward process-based inventory data for Portland clinker substitutes,” Journal of Industrial Ecology, published 18 September 2026. https://doi.org/10.1007/s44498-026-00186-x ↩ ↩²

19. Pierre Jouannais, Lia Rapella, Philippe Drobinski et al., “Future Mediterranean agrivoltaics: prospective life cycle assessment under climatic and socio-economic scenarios,” npj Climate Action, published 18 September 2026. https://doi.org/10.1038/s44168-026-00425-8 ↩ ↩²

20. Ewa Katarzyna Lagodzka, Fabio Sporchia and Massimo Pizzol, “Best practices for comparative LCA of bio-based alternatives to fossil-based products,” The International Journal of Life Cycle Assessment, Vol. 31, Article 162, published 25 August 2026. https://doi.org/10.1007/s11367-026-02681-6 ↩

21. Mauro Moresi, “Eco-Designing Convenience Food: A Monte Carlo Product Environmental Footprint Assessment of Dry, Fresh, and Instant Pasta Systems,” Sustainability, 18(17), 8712, published 25 August 2026. https://doi.org/10.3390/su18178712 ↩

22. Niraj Gohil, Nawshad Haque and Amro M. Farid, “Dynamic Carbon-Aware Operation of Electrolytic Hydrogen Production in Australia: A Spatio-Temporal Life Cycle Assessment,” Sustainability, 18(17), 8716, published 25 August 2026. https://doi.org/10.3390/su18178716 ↩

23. Matthew Rumsa, Michele John, Wahidul Biswas et al., “Advancing environmental assessment of recycled resources: the role of product declarations and circularity metrics in green(er) steel,” The International Journal of Life Cycle Assessment, Vol. 31, Article 161, published 24 August 2026. https://doi.org/10.1007/s11367-026-02727-9 ↩

24. European Commission / European Platform on Life Cycle Assessment / Life Cycle Data Network, EF studies development and LCDN developer tooling, including extended-ILCD (eILCD) model support, XML schemas, life-cycle-model datasets, validation tooling and EF study resources. https://knowledge4policy.ec.europa.eu/european-platform-life-cycle-assessment-eplca/life-cycle-data-network-lcdn/ef-studies-development_en and https://knowledge4policy.ec.europa.eu/european-platform-life-cycle-assessment-eplca/topic/lcdn-developer-tools_en ↩

25. Lifecycle Brief, “PCRs are the hidden infrastructure behind EPDs — We set out to make the calculation fast. The harder problem turned out to be the rules,” practitioner reference article, last reviewed September 2026. Used as production insight and architecture input, not normative authority. https://lifecyclebrief.beehiiv.com/p/pcrs-are-the-hidden-infrastructure-behind-epds ↩

26. International Energy Agency, Life Cycle Upstream Emissions Factors 2026, released 25 September 2026. https://www.iea.org/data-and-statistics/data-product/life-cycle-upstream-emissions-factors-2026 ↩

27. Peter Fantke et al., “A global consensus life cycle impact assessment method — GLAM: impacts on ecosystem quality,” The International Journal of Life Cycle Assessment, published September 2026. https://doi.org/10.1007/s11367-026-02748-4 ↩

28. Mark A. J. Huijbregts et al., “Consensus-based framework for the impact assessment of natural resource use in life cycle assessment: generalized impact pathways and recommended methods for abiotic resource use,” The International Journal of Life Cycle Assessment, published September 2026. https://doi.org/10.1007/s11367-026-02733-x ↩

29. “Transparent and harmonized allocation factors for crop-processing co-products in U.S. dairy rations,” The International Journal of Life Cycle Assessment, published September 2026. https://doi.org/10.1007/s11367-026-02750-w ↩

30. “A natural-language interface for parameter-level scenario analysis in parameterised life cycle assessment models,” Journal of Industrial Ecology, published September 2026. https://doi.org/10.1007/s44498-026-00163-4 ↩

31. République française, Code de l'environnement, Article D541-244, version carrying the transitional condition through 1 October 2026; see also Article D541-245. https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000052217942/2026-08-22 and https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000052217944/2026-10-08 ↩

32. Reinout Heijungs, “Interoperability of uncertainty information in LCI databases,” The International Journal of Life Cycle Assessment, published 2026. https://doi.org/10.1007/s11367-026-02755-5 ↩

33. Sanna Hietala et al., “Development of environmental footprint product category rules for Finnish food sector in alignment with Product Environmental Footprint (PEF) method,” The International Journal of Life Cycle Assessment, published 29 September 2026. https://doi.org/10.1007/s11367-026-02757-3 ↩

34. “Systematic bias in Scope 3 emissions accounting: evidence from firm-level supply networks,” npj Environmental Social Sciences, published 2026. https://doi.org/10.1038/s44432-026-00017-1 ↩

35. Johannes Gütschow, Daniel Busch and Mika Pflüger, The PRIMAP-hist national historical emissions time series (1750–2025) v2.8, Zenodo, 2026. https://doi.org/10.5281/zenodo.22876287 ↩

36. Christian Buschbeck, Manuel Bickel, Jens Teubler et al., “Re-evaluating ecoinvent’s suitability for direct product material footprint calculation,” Journal of Industrial Ecology, published October 2026. https://doi.org/10.1007/s44498-026-00183-0 ↩

37. “A life cycle-based Green Manufacturing framework for environmental decision-making: an application to heavy-duty vehicle chassis frame rail manufacturing,” The International Journal of Advanced Manufacturing Technology, published October 2026. https://doi.org/10.1007/s00170-026-19254-4 ↩

38. “Life-cycle analysis of bio-based phase change materials in recycled-aggregate mortars: sourcing sensitivity and trade-offs,” Materials and Structures, published October 2026. https://doi.org/10.1617/s11527-026-03301-3 ↩

39. “Life Cycle Assessment of 3D-Printed Construction: A Systematic Review of Methods, Boundaries, and Comparative Outcomes,” Buildings, 16(19), 3969, published October 2026. https://doi.org/10.3390/buildings16193969 ↩

40. SGS and Sami, Carbon Footprint Radar 2026, partner release pages published October 2026. https://www.sgs.com/en-us/whitepapers/carbon-footprint-radar-2026-form and https://www.sami.eco/en/blog/results-carbon-footprint-radar ↩

41. GreenDelta/openLCA, “worldsteel datasets are now available on Nexus,” published 15 October 2026; World Steel Association, “worldsteel releases 2026 LCI database,” published 20 May 2026; and the openLCA Nexus distribution record. https://www.openlca.org/worldsteel-datasets-are-now-available-on-nexus/, https://worldsteel.org/media/press-releases/2026/worldsteel-releases-2026-lci-database/, and https://nexus.openlca.org/database/worldsteel ↩

42. Christina Forsthuber, Daria Blizniukova and Matthias Finkbeiner, “Consequential life cycle assessment of agricultural products: state of the art and research needs,” The International Journal of Life Cycle Assessment, published 12 October 2026. https://doi.org/10.1007/s11367-026-02759-1 ↩

43. Aleksandra Kręt-Grześkowiak and Sławomir Rowiński, “Quantifying Environmental Impacts Across Multiple Future Lifecycles of Steel and AAC Structures: Results, Uncertainties, and Methodological Challenges,” Resources, 15(10), 130, published 10 October 2026. https://doi.org/10.3390/resources15100130 ↩

44. Danielle Freitas and Helena Gervásio, “An Automated BIM–LCA Framework to Environmental Decision-Making in the Structural Design,” ReSBE 2026 conference proceedings, published 15 October 2026. https://doi.org/10.1007/978-3-032-34930-9_158 ↩

45. Marisleide Souza, João Luiz Calmon and Diego Lima Medeiros, “Dataset of harmonized methodological data supported by study classification and system boundary consistency assessment for End-of-Life Tire Management LCA,” Mendeley Data, Version 2, published 14 October 2026, CC BY 4.0. https://doi.org/10.17632/fy8wbgj8zm.2 ↩

46. Berend Mintjes et al., “Integrating Product Environmental Footprint and Digital Product Passports: an Ontology for Traceable and Reusable Environmental Performance Information,” Journal of Circular Economy, 4(3), published 23 October 2026, DOI 10.55845/hanesd36; and Mintjes et al., “PEFDPP ontology and battery case study,” Zenodo Version 1.0.0, published 7 October 2026, DOI 10.5281/zenodo.23217060. https://doi.org/10.55845/hanesd36 and https://doi.org/10.5281/zenodo.23217060 ↩

47. Niina Sundin et al., “Rebound effects in food-system life cycle assessments: insights from practitioners,” The International Journal of Life Cycle Assessment, Vol. 31, Article 191, published 20 October 2026. https://doi.org/10.1007/s11367-026-02764-4 ↩

48. Keteki Anand, Yvonne Ryan-Fogarty and Colin Fitzpatrick, “Life cycle assessment of remanufactured electrical and electronic equipment: a systematic literature review of reported methodological choices,” Journal of Remanufacturing, Vol. 16, Article 19, published 21 October 2026. https://doi.org/10.1007/s13243-026-00175-0 ↩

49. Raphael Müller, Daniela Fendt and Vanessa Heinrich, “Enabling a Circular Economy through a Digital Product Passport in the Automotive Industry: Essential Data Points for Enhancing R-Strategies,” Journal of Circular Economy, 4(3), published 20 October 2026. https://doi.org/10.55845/9rrg5n15 ↩

50. Anastasia Jesica, David Law and Rebecca J. Gravina, “Quantifying the Relationship Between Environmental–Mechanical Parameters of Structural Concrete Incorporating Recycled Materials: A Decision Framework for Optimized Selection,” International Journal of Concrete Structures and Materials, Vol. 20, Article 101, published 19 October 2026. https://doi.org/10.1186/s40069-026-00981-7 ↩

51. European Commission, Commission Recommendation (EU) 2021/2279 of 15 December 2021 on the use of the Environmental Footprint methods to measure and communicate the life cycle environmental performance of products and organisations. https://eur-lex.europa.eu/eli/reco/2021/2279/oj/eng ↩ ↩²

52. European Commission, Directorate-General for Environment, “Guidance on the implementation of Commission Recommendation 2021/2279 in the context of lower availability of EF-compliant datasets,” 2026, DOI 10.2779/4650573; see also the Commission's 14 July 2026 transitional guidance summary. https://op.europa.eu/en/publication-detail/-/publication/8fe38f0b-4829-11f1-8095-01aa75ed71a1/language-en and https://green-forum.ec.europa.eu/news/transitional-guidance-limited-availability-ef-compliant-datasets-2026-07-14_en ↩