# [Research Discussion] Exploring explainable and interrogable optimisation in EMHASS

[MMicieli]

Background

EMHASS optimises energy schedules using forecasts, electricity prices, system constraints and configured objectives. While the resulting plans show what the optimiser has decided, understanding why a particular decision was made can require considerable manual analysis.

This is particularly challenging when a decision appears counterintuitive, or when successive MPC optimisations produce different schedules despite seemingly similar conditions.

Existing EMHASS discussions highlight different aspects of this challenge:

• [Discussion #294](Option to to minimize splitting the power on phases the deferrable loads to a minimum #294) — Understanding an unexpected deferrable-load schedule required manually evaluating an alternative.
• [Discussion #1005](Is it normal for MPC optimization results to differ so dramatically even when it's run often? #1005) — Substantially different MPC schedules produced similar economic outcomes, illustrating the importance of equivalent or near-equivalent solutions.
• [Issue #984](MPC plan buying high and selling low from grid #984) — Apparently irrational electricity trading behaviour was traced to incorrectly aligned forecast timestamps.
• [Issue #1093](Battery won't charge past ~50-60% during peak solar, surplus gets curtailed #1093) — Unexpected battery charging and PV curtailment behaviour prompted investigation of the objective function and terminal SOC treatment.

These examples demonstrate that unexpected behaviour can originate from valid optimisation trade-offs, model assumptions, input errors or implementation defects.

The question is whether we can make those distinctions easier to investigate, using evidence from the optimisation process itself.

Research concept

Could EMHASS optimisation decisions become explainable and interrogable through deterministic, mathematically defensible methods, without relying on LLM-generated reasoning?

The broader concept would allow users and developers to investigate questions such as:

• Why this decision? What factors influenced the selected action?
• Why not another action? Would an alternative have produced a better, worse or equivalent outcome?
• What changed? Why did successive MPC optimisations produce different schedules?
• Was the decision necessary? Was it uniquely preferable, or one of several equally valid solutions?
• What explains unexpected behaviour? Can we distinguish valid optimisation results from incorrect inputs, model limitations or defects?

For example, instead of only observing that EMHASS discharged a battery, a user might investigate why discharging was preferable to retaining energy for later, considering the complete optimisation horizon rather than just the current electricity price.

The intention is not simply to produce descriptive text. It is to explore whether explanations can be verified against the mathematical problem EMHASS actually solved.

Feasibility and research questions

This is not necessarily straightforward.

Optimisation does not always provide a single causal explanation. Multiple schedules may be economically equivalent, solver tolerances can affect the selected solution, and an active constraint does not necessarily establish why an action was chosen.

Some questions may already be answerable from existing EMHASS outputs. Others might require additional information or controlled evaluation of alternative solutions.

The initial research should therefore establish:

1. Mathematical feasibility: What forms of explanation and decision interrogation are possible, reliable and meaningful for EMHASS's optimisation models?
2. Existing capabilities: What information is already available through EMHASS, its optimisation libraries and current diagnostics?
3. Relevant research: Are there established approaches from explainable mathematical optimisation, mixed-integer programming or model predictive control that could be applied?
4. Practical value: Would these capabilities improve troubleshooting, model validation, user understanding or development?
5. Architectural implications: If feasible, which capabilities would belong in EMHASS and which could be implemented externally, without unnecessary complexity or performance overhead?

Related work includes [Discussion #931](#931) and [Discussion #1157](#1157), where read-only scenarios and isolated optimisation have been considered. These may provide useful groundwork, although no particular architecture is assumed.

An important research requirement would be distinguishing verified mathematical conclusions, reasonable interpretations and questions that cannot be answered reliably.

Proposed R&D approach

I propose approaching this as an iterative research initiative, rather than starting with a feature specification.

The initial stage would use this Discussion to gather perspectives, identify relevant research and establish the concept's fundamental feasibility and limitations.

If a promising direction emerges, I intend to develop an isolated local proof of concept, using reproducible optimisation scenarios and historical evidence to investigate what can actually be explained and interrogated.

Research would continue alongside the PoC, with findings, limitations and emerging questions shared back into this Discussion for feedback and refinement.

The intended progression is:

Community discussion → Research → Local PoC → Validation and feedback → Further R&D → Potential upstream contribution

If the concept proves technically sound, useful and sufficiently general, we could explore contributing appropriate functionality to EMHASS, subject to the maintainer's direction and project requirements.

Equally, the research may establish that certain explanations are impractical, insufficiently reliable or better handled by external tools. Those would also be valuable outcomes.

The initial scope is strictly understanding and investigating optimisation decisions, not changing production dispatch behaviour or introducing another control system.

Community input

I'd particularly welcome perspectives on:

• Whether this addresses a meaningful problem for EMHASS users and developers.
• Existing research, techniques or capabilities worth investigating.
• Mathematical or architectural limitations that could make the concept impractical.
• What would constitute a convincing minimum proof of concept.
• How to keep any eventual solution accurate, maintainable and broadly applicable.

The immediate objective is to establish whether explainable and interrogable optimisation is a technically viable and worthwhile direction for EMHASS—not to prescribe how it should be implemented.

@davidusb-geek and the wider EMHASS community would is this something that you would be interested in having within EMHASS if possible?

[davidusb-geek]

@davidusb-geek and the wider EMHASS community would is this something that you would be interested in having within EMHASS if possible?

Hi, yes for me this is quite interesting and as you have noted in the discussions and issues that you referenced, most of the time it is simply hard to understand how the optimizer converged to a given solution.

One simple research technique that we use and that is not currently implemented in EMHASS (never had the time to) is visualization.
We can provide a 2D plot of the MILP Domain of Validity and the Convex Hull. This just help understand the domain and is even extremely helpful to understand why some domains are just infeasible.

There are many other solutions out there and we can discuss them and explore them here.
But a simple visualization that we can as of now directly embed into our GUI is a good first approach I think

[MMicieli]

@davidusb-geek and the wider EMHASS community would is this something that you would be interested in having within EMHASS if possible?

Hi, yes for me this is quite interesting and as you have noted in the discussions and issues that you referenced, most of the time it is simply hard to understand how the optimizer converged to a given solution.

One simple research technique that we use and that is not currently implemented in EMHASS (never had the time to) is visualization.

We can provide a 2D plot of the MILP Domain of Validity and the Convex Hull. This just help understand the domain and is even extremely helpful to understand why some domains are just infeasible.

There are many other solutions out there and we can discuss them and explore them here.

But a simple visualization that we can as of now directly embed into our GUI is a good first approach I think

Sounds good to me. I'll start the ground work now and once the new update is released I can base it off that

[renaatdb]

I think this research direction could be very useful in practice.

A recent MPC case in my own setup is a good example. The optimization became infeasible, while several causes looked equally plausible at first:

• battery SOC limits
• dishwasher scheduling
• boiler scheduling
• thermal constraints
• cooling-related constraints

After testing these one by one, the actual blocker turned out to be the grid import ceiling: P_from_grid_max = 2500 W.

Raising it to 5000 W immediately restored an optimal solution.

The difficult part was not fixing the problem once found, but determining why the optimizer had become infeasible.

For a case like this, I would find it very useful if an interrogable optimisation layer could show:

• which constraint or constraint group is binding/conflicting;
• what minimum relaxation would restore feasibility;
• whether infeasibility is caused by one hard limit or by several interacting constraints.

I had opened #1200 about this example, and David redirected me here, so I am adding it as a concrete real-world case for this research direction.

[MMicieli]

Thanks @davidusb-geek and @renaatdb.

The 2D visualisation of the MILP feasible region and convex hull sounds like a sensible starting point. I'll investigate what can be represented accurately using EMHASS's existing optimisation model, particularly how binary decisions and higher-dimensional constraints limit what a 2D visualisation can explain.

@renaatdb, your example in #1200 also provides a useful practical test case. It would be worth exploring whether existing solver diagnostics or controlled feasibility-relaxation tests can identify conflicting constraints and quantify the changes needed to restore feasibility.

I'll incorporate both into the initial research, starting with small, reproducible offline examples. The first objective will be to establish what can be explained reliably using existing EMHASS and solver capabilities before considering any new functionality.

I'll share the findings here for discussion once there is something concrete to evaluate. Working on a few other projects at the moment but will get onto this asap