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.

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 (PHASE_REBALANCING)
• Controlled load power shifting (CONTROLLED_LOAD_HOT_WATER)
• Tariff redesign (TARIFF_REFORM)
• 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

Chaining / Stacking Interventions

baseWorkPackageId can point at any prior work package, not just a non-intervention baseline. This means you can, for example, set baseWorkPackageId 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 is present in its simulation. Chaining baseWorkPackageId only carries forward metrics if running an intervention work package off an exisitng intervetion work package, the second work package only looks at the network_performance_metrics_enhanced results to decide where the second interventions should go. The first intervetion work packages actual applied changes (equipment placed, taps changed, etc.) are not present.

What this means in practice

• 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 intervetion work package will site its own intervention using the previous post-intervention metrics, but its results only reflect intervention B on the base network - not A and B together.
• Getting the true combined effect of two intervention types (not currently supported): a work package's configuration only accepts a single intervention block. There is no supported way today to run one work package with two intervention types applied simultaneously to the same network, so a genuinely cumulative A+B result isn't obtainable under the current architecture.