What are Interventions and why are they useful?

Once constraints are identified, the HCM allows operators to explore strategies to resolve them through the Intervention Module. This module models changes to both system-wide and local conditions, enabling comparative analysis of mitigation options against the base case. The Intervention Module is a separate module within the Energy Workbench platform, designed to work seamlessly with the HCM. Contact Zepben to enable this module.

For a practical walkthrough of the base work package requirements, configuration, and common pitfalls, see How to run an Intervention Work Package.

note

The Intervention Module is intended to run either on a single year or a range of contiguous years, not on multiple non-contiguous years. Attempting to do so will not result in an error, but will likely produce unexpected results.

For example:

• Valid: {2026}, or {2026,2027,2028,2029,2030}
• Invalid: {2026,2030}

The Intervention Module produces results using the same framework as the core HCM, allowing direct comparison of constraint patterns before and after applying mitigation strategies.

Systemic Interventions

Systemic interventions are applied across the entire network. Examples include:

• Phase rebalancing (phaseRebalanceProportions)
• Load reshaping (loadReshaping) - e.g. controlled load power shifting, tariff redesign
• Dynamic voltage management (dvms)

Local Interventions

Local interventions are targeted at specific locations. Examples include:

• Installation of community batteries (COMMUNITY_BESS)
• LV STATCOMs (Static Synchronous Compensators) (LV_STATCOMS)
• Off-load tap optimisation (DISTRIBUTION_TAP_OPTIMIZATION) - static, once-per-year tap changes on distribution transformers based on historical voltage patterns from the base work package
• Distribution transformer OLTC retrofit (DISTRIBUTION_TX_OLTC) - installation of on-load tap changers on distribution transformers, enabling dynamic voltage regulation at the LV level

How Candidate Generation and Allocation Works

Local interventions (COMMUNITY_BESS, LV_STATCOMS, DISTRIBUTION_TAP_OPTIMIZATION, DISTRIBUTION_TX_OLTC) use a two-stage process to identify and deploy solutions at problem locations.

Process Flow

Base Work Package Results
         ↓
Does location exceed thresholds (as defined in intervention_candidate_criteria)? ──No──> Skip
         ↓ Yes
      Candidate Created (stored in intervention_candidates)
      (location, year, severity)
         ↓
      Ranked by Severity
      (most severe constraints as per criteria = rank 1, next = rank 2, etc.)
         ↓
      Allocated by Year
      (up to limit per year, as per intervention config `allocationLimitPerYear`)
         ↓
      Rerun Work Package with changes made
         ↓
Intervention Work Package results 

How It Works

1. Candidate Generation

• Analyzes base work package results for each measurement zone and year
• Creates candidate if location exceeds ALL specified thresholds in intervention_candidate_criteria (DISTRIBUTION_TAP_OPTIMIZATION is the exception - its thresholds come from the work package config values rather than the intervention_candidate_criteria table, see Interventions Options)
• Tags candidate with the earliest year the threshold is exceeded

2. Ranking

• COMMUNITY_BESS: Sum of gen_exceeding_normal_thermal_voltage_cecv + load_exceeding_normal_thermal_voltage_vcr
• LV_STATCOMS: Sum of gen_exceeding_normal_voltage_cecv + load_exceeding_normal_voltage_vcr
• DISTRIBUTION_TX_OLTC: Sum of gen_exceeding_normal_voltage_cecv + load_exceeding_normal_voltage_vcr (same as LV_STATCOMS)
• DISTRIBUTION_TAP_OPTIMIZATION: Weighted score from voltage deviation percentiles and hours outside limits
• Lower rank number = more severe = higher implementation priority

3. Allocation

• Deploys interventions to highest-ranked candidates first
• Respects allocationLimitPerYear constraint
• Phases deployment across years based on available capacity

Example

Candidates found:
- Location A: 2026, severity 150 → Rank 2
- Location B: 2027, severity 200 → Rank 1
- Location C: 2026, severity 100 → Rank 3

With allocationLimitPerYear = 2:
- 2026: Install at A, C (B not yet eligible; 2026 limit filled)
- 2027: Install at B

Key Points:

• Candidates are generated from base work package analysis (not discovered during solve)
• Worst problems addressed first within yearly deployment constraints
• Year assignment determines when intervention becomes active in simulation

Combining Interventions

There are two distinct ways to combine interventions: chaining work packages via parentWorkPackageId, and stacking multiple intervention blocks within a single work package.

Chaining via parentWorkPackageId

parentWorkPackageId can point at any prior work package, not just a non-intervention baseline. This means you can, for example, set parentWorkPackageId on an intervention work package.

Each work package's network model is built independently: the network is always sourced fresh (never inherited from another work package's simulated output), and only that work package's own applied intervention(s) are present in its simulation. Chaining parentWorkPackageId only carries forward metrics - if running an intervention work package off an existing intervention work package, the second work package only looks at the network_performance_metrics_enhanced results to decide where its own interventions should go. The first work package's actual applied changes (equipment placed, taps changed, etc.) are not present in the second.

This means:

• Comparing independent interventions against the same baseline (supported): Each is a clean before/after comparison against a baseline non-intervention work package.
• Chaining to target a second intervention at residual problems (supported, but not cumulative): The second work package will site its own intervention(s) using the first work package's post-intervention metrics, but its results only reflect its own intervention(s) applied to the base network - not the first work package's changes plus its own.

Stacking Interventions

A single work package's intervention block can combine one candidate intervention (candidateIntervention) with any combination of phaseRebalanceProportions, dvms, and loadReshaping. All of the interventions set are applied to the same network and simulated together, giving a genuinely cumulative result - unlike chaining, which only carries metrics forward between separate simulations.

Two candidate interventions (e.g. COMMUNITY_BESS and LV_STATCOMS) cannot be stacked in the same work package, since candidateIntervention only accepts one. To combine two candidate interventions, chain them via parentWorkPackageId instead (not cumulative, see above).