Skip to main content
Jira progress: loading…

S2-ADJ

Scope 2 Market / Location Adjustment

1. Identity​

Loading identity…

Depends on module:

Canonical computation and modeling domain for ESG calculations, simulations, extrapolation, aggregation, normalization, and decision-grade metric synthesis. Provides governed, auditable compute services to other modules (e.g., Reporting, Risk, Net Zero, ZARA).
Domain:
computation-hub
Category:
analytics-modeling
Classification:
module
Lifecycle status:
active
Semver:
1.0.0
Introduced in:
v0.3
Governance
AI risk level:
high
Trust threshold:
0.9
Human review required:
true
Verifier involved:
false
Audit required:
true
Ownership
Primary owner:
Platform
Architecture board:
true
White-label allowed:
true
Entrypoints
Docs:
/computation-hub
UI:
/app/computation-hub
API:
/api/computation-hub
Dependencies
Modules
  • sis
  • input-hub
Unresolved tokens
  • BUME
  • SEM
  • VTE
Engines (declared)
  • DICE
  • DaVE
  • VTE
  • SEM
  • BUME
Micro-engines (from registry)
Micro-engines (declared)
None
Signals
USO
  • DATA.COMPUTATION
  • DATA.VALIDATION
  • DATA.EXTRAPOLATION
  • MODEL.SIMULATION
  • MODEL.UNCERTAINTY
CSI
  • CSI_COMPUTATION_HUB
SSSR tags
  • computation
  • modeling
  • simulation
  • monte-carlo
  • bayesian
  • extrapolation
  • aggregation
  • normalization
  • validation
  • mice
Workflows & Outputs
Workflows
  • MicroEngineRouting
  • RuleBasedComputeDispatch
  • ScenarioModeling
  • UncertaintyQuantification
  • AggregationAndRollups
  • NormalizationAndBenchmarking
  • ExtrapolationAndGapFilling
  • ComputeAuditAndReplay
Outputs
  • computed_metrics
  • scenario_ranges
  • confidence_intervals
  • normalized_values
  • validation_findings
  • trust_scored_compute_outputs
Audit
Ledger:
ALTD
Replay supported:
true
PII policy:
no_pii_in_omr
Tags

  • Purpose: Converts Scope 2 emissions between location-based and market-based accounting methods in accordance with the GHG Protocol Scope 2 Guidance and ESRS E1 requirements.

  • Typical usage:

    • Reporting both Scope 2 (location-based and market-based)
    • Applying contractual instruments (EACs, GOs, RECs)
    • Producing adjusted Scope 2 values for aggregation and intensity

Versioning policy

  • MEID is stable.
  • Methodological logic, datasets, and factors are versioned and governed via ZAR.

2. Contract References (ZAR)​

2.1. Input Schema​

  • ZAR Address: schema.compute.ghg.scope2.adjust.inputs.v1_0_0

Required conceptual fields

  • scope2_location: scalar or time-series (mandatory)
  • scope2_market: scalar or time-series (optional; may be derived)
  • electricity_consumption: scalar or time-series (mandatory if deriving market-based)
  • instrument_portfolio: optional list of contractual instruments
  • target_method: LOCATION | MARKET
  • alignment: BY_YEAR | BY_INDEX (default BY_YEAR)

2.2. Options Schema​

  • ZAR Address: schema.compute.ghg.scope2.adjust.options.v1_0_0

Common options:

  • instrument_priority: ordered list (e.g. ["EAC","PPA","RESIDUAL"])
  • residual_mix_policy: DEFAULT_GRID | COUNTRY_RESIDUAL | ERROR
  • allow_partial_coverage: boolean (default true)
  • rounding: optional digits

2.3. Output Schema​

  • ZAR Address: schema.compute.ghg.scope2.adjust.output.v1_0_0

Outputs include:

  • scope2_location
  • scope2_market
  • scope2_adjusted (equals the value for target_method)
  • coverage_ratio
  • metadata (instrument usage, residual mix applied, policy flags)

3. Accepted Input Shapes​

A. Direct adjustment (market already provided)

{
  "scope2_location": [[2025, 5000]],
  "scope2_market": [[2025, 3200]],
  "target_method": "MARKET"
}

B. Derivation using electricity + instruments

{
  "scope2_location": [[2025, 5000]],
  "electricity_consumption": [[2025, 100000]],
  "instrument_portfolio": [
    {
      "type": "EAC",
      "volume_mwh": 40000,
      "emission_factor": 0.0
    }
  ],
  "target_method": "MARKET"
}

C. Time-series, multi-year

{
  "scope2_location": [[2025, 5000], [2026, 4800]],
  "electricity_consumption": [[2025, 100000], [2026, 98000]],
  "target_method": "MARKET",
  "alignment": "BY_YEAR"
}

All inputs MUST be normalized internally to:

Map<period, { location, electricity, instruments[] }>

4. Compute Semantics (Normative)​

4.1. Location-based emissions​

Location-based Scope 2 is treated as authoritative input and MUST NOT be modified.

S2_LOCATION(t) = provided scope2_location(t)

4.2. Market-based derivation (core logic)​

For each period t:

  1. Apply contractual instruments (in priority order):
  • Instruments reduce electricity volume at their associated emission factor
  • Total covered volume MUST NOT exceed total electricity consumption unless explicitly allowed
  1. Residual mix application:
  • Remaining electricity volume is multiplied by residual mix emission factor
  • Residual mix source determined by residual_mix_policy
  1. Sum components:
S2_MARKET(t) =
  Σ instrument_volume_i(t) × EF_i
+ residual_volume(t) × EF_residual

4.3. Coverage ratio​

coverage_ratio(t) = covered_electricity(t) / total_electricity(t)

Reported in metadata and output.

4.4. Adjusted output​

  • If target_method = LOCATION → scope2_adjusted = scope2_location
  • If target_method = MARKET → scope2_adjusted = scope2_market

5. Methodological Rules (Normative)​

  • Instruments MUST be valid for the reporting period
  • Double counting of instruments is forbidden
  • Zero-emission instruments (e.g. EACs) MUST be explicitly declared
  • If allow_partial_coverage = false and coverage_ratio < 1 → error

Metadata MUST record:

  • instruments applied
  • residual mix used
  • coverage ratio
  • policies triggered

6. Alignment Rules​

BY_YEAR

  • Electricity, location emissions, and instruments must align by year
  • Missing data handled per schema/options

BY_INDEX

  • Ordered alignment (discouraged for Scope 2)

7. Validation & Error Model​

Invariants

  • Electricity consumption ≥ 0
  • Instrument volumes ≥ 0
  • Covered volume ≤ total electricity (unless explicitly allowed)
  • Emission factors finite

Error codes (suggested)

  • SCOPE2_INSTRUMENT_OVERALLOCATION
  • SCOPE2_RESIDUAL_MIX_MISSING
  • SCOPE2_INVALID_INSTRUMENT
  • SCOPE2_ALIGNMENT_MISMATCH

Errors MUST include:

  • engine cmi_short_code
  • period
  • instrument identifier (if applicable)

8. Dependencies​

MEID_CALC_GHG_SCOPE2_ADJ depends on:

  • residual mix datasets (country / grid)
  • schema resolver (ZAR)
  • unit conversion utilities
  • optional contractual instrument registry

Declared in ZAR via dependencies.

9. Federation & Audit Requirements​

To reproduce Scope 2 adjustment externally, the export MUST include:

  • Engine identity (cmi or zar_code)
  • Engine build proof (execution_ref + build_hash)
  • Input/options/output schemas
  • Location-based Scope 2 values
  • Electricity consumption data
  • Instrument portfolio details
  • Residual mix source + emission factors

Provenance MUST show:

… → MEID_CALC_GHG_SCOPE2_ADJ → …

with cmi_short_code present in USO tails.

10. Performance Notes​

  • Complexity: O(n×i)O(n × i) where ii = instruments
  • Memory: O(n)O(n)
  • Suitable for batch and regulatory reporting (not high-frequency streaming)

11. Methods Served (v1)​

  • GHG.scope2.location.abs
  • GHG.scope2.market.abs
  • GHG.scope2.adjusted.abs

Downstream engines consuming this output:

  • MEID_CALC_GHG_AGGR
  • MEID_CALC_GHG_INT
  • MEID_CALC_TARGET_GAP
  • MEID_SCEN_GHG_ALIGN


GitHub RepoRequest for Change (RFC)