RFC: opt-in federated multi-device optimisation for EMHASS, with a fair split of the savings

[ameetdesh]

An opt-in EMHASS backend, off by default, that plans each device as its own subproblem, coordinates the plans by prices at the meter, and splits the saving among the devices. Nothing changes for anyone who leaves it off.

Why

Homes now run several optimisers side by side: EMHASS for batteries and loads, evcc for the car, vendor apps for heat pumps. Each plans against the tariff alone.

• Collisions. Every optimiser sees the same cheap hours, so they all charge then and can trip an import limit or an export cap.
• One model has limits. EMHASS's MILP coordinates only the devices it models, must keep each of them linear, and slows down with every binary.
• Advanced optimisers. Each device can use the solver that suits it. A dynamic-programming battery solver, for example, can include any nonlinearity, such as efficiency that varies with power or state of charge, or wear that depends on depth of discharge, which a MILP can only approximate.
• Credit. A leased battery, a flexibility programme or a tenant's car needs its own share of the saving. A single plan gives only the total.
• Value stacking. Aggregators earn from revenue streams of their own, such as frequency regulation and other ancillary services, and run infrastructure that depends on their device's telemetry. If each counts that revenue as its private gain, the coordinator keeps the best of every value stack while the devices still work as one for the customer.

Planning each device as its own subproblem, coordinated at the meter, answers all five.

What

All three parts below are in one draft PR, #1158, to review as one piece or split as you prefer.

Ask 1: an opt-in coordinator backend.

• optimization_backend: cvxpy (default, today's MILP), dantzig_wolfe or admm.
• participants (optional): groups of devices, each solved by emhass (its own model, the default) or home_energy_optimizer.
• A dispatch of about 20 lines in perform_optimization. The coordinator, the interface and the settlement come from home-energy-optimizer through pip install emhass[federated] (MIT, needs only numpy).
• The same opt_res columns, plus fed_meter_price, fed_lower_bound and fed_gap. Anything not yet supported falls back to the default solver, with one log line.

"optimization_backend": "dantzig_wolfe",
"participants": [
  {"devices": ["battery"], "solver": "home_energy_optimizer"},
  {"devices": ["deferrable0", "deferrable1"], "solver": "emhass"}
]

Ask 2: dry_run. A runtime flag on the optimisation actions: solve at the given prices, return the plan in the response, and write nothing. An outside coordinator can then include EMHASS as one participant without overwriting the live plan.

How it works. Each participant answers one query: its cheapest plan when its energy is priced at the coordinator's meter price. It returns the plan, its private cost (everything except the bill: discomfort, wear, a missed goal, less revenue earned elsewhere) and its state. The interface is a versioned JSON Schema (query, answer), so EMHASS's models, other solvers and remote agents look alike to the coordinator. Dantzig–Wolfe mixes the proposed plans in a small LP that holds the meter, updates the prices, and returns a lower bound (theory).

flowchart TB
  subgraph A["1. All in EMHASS"]
    CA["Coordinator<br/>(EMHASS backend)"] --> A1["Battery<br/>EMHASS model"]
    CA --> A2["Deferrable loads<br/>EMHASS model"]
  end
  subgraph B["2. Mixed solvers"]
    CB["Coordinator<br/>(EMHASS backend)"] --> B1["Battery<br/>DP solver"]
    CB --> B2["Deferrable loads<br/>EMHASS model"]
  end
  subgraph C["3. EMHASS as one participant"]
    CC["Outside coordinator"] --> C1["EMHASS<br/>(all its devices, dry_run)"]
    CC --> C2["EV<br/>evcc"]
    CC --> C3["Heat pump<br/>vendor solver"]
  end

Loading

Revenue sharing. Each participant is first reimbursed its change in private cost. The rest is split between solar and the participants by an Owen value, then among the participants by Aumann–Shapley. This needs one extra plan, and came within 0.46 currency units of the exact Shapley value on six test cases. Each player's share comes back as an opt_res column, fed_share_<player>.

Evidence. On EMHASS's own device models, the coordinated plans are very close to its MILP. Across 25 runs the cost differs by 0.016% on average and by at most 0.09%, with the MILP run at lp_solver_mip_rel_gap: 0.

Runs	Count	Cost difference from the MILP, mean / largest
EMHASS's study cases	7	0.0000% / 0.0003%
Synthetic days: battery and two on/off loads	12	0.0004% / 0.005%
Synthetic days: battery, an on/off load and a heat pump	6	0.07% / 0.09%

The coordinated plan takes 0.2–1.6 s, including the extra plan the shares need, against 0.1–0.6 s for the MILP. scripts/federated_benchmark.py in the PR reproduces these runs. A battery with ramp limits or stress costs must be answered by EMHASS as a black box, which is weaker: 94–100% of the MILP's savings, in 1.2–14 s. Through dayahead-optim and publish, both backends write the same files and entities.

Compatibility. Off by default. Parameters and columns are only added, there is no new required dependency, no EV or evcc code in core (#789), and no restructuring of optimization.py. The adapter builds EMHASS's Optimization through its constructor, which is not a public contract, so the backend's tests should run in one CI job.

Plan. After your feedback, the draft PR is finished or split as you prefer. Later, if wanted, the coordinator, the interface and the settlement can move into EMHASS as composable modules (step 2).

Questions for the maintainers

1. Are optimization_backend and participants the right names, with cvxpy, dantzig_wolfe and admm as values?
2. Would you welcome step 2 once step 1 has results: the coordinator, the interface and the settlement as modules inside EMHASS?
3. Should EMHASS's docs link to the interface schema, or carry a copy?
4. Where should each participant's share go: additive opt_res columns, or a table beside /api/v1/plan?
5. Settlement compares each participant with its plan without coordination. For a deferrable load, should that plan start as early as its window allows?
6. Is an optional quadratic term in EMHASS's model acceptable later, so that admm can use EMHASS's models too?

[LesIT1]

Two things from adjacent work, in case they save you a round.

On Ask 2, dry_run. The solve is not side-effect free today, so the flag has to do more than skip the HA post. In each optim wrapper, after the solve: the results CSV is always written, the dated file with save_data_to_file on and opt_res_latest.csv otherwise for naive-MPC and day-ahead (command_line.py:2901-2910, 2787-2796; perfect-optim writes opt_res_perfect_optim_<costfun>.csv by default, 2572-2580), and publish_data reads that latest file (or the entity JSONs when publish_prefix is set); with continual_publish or entity_save the entity JSON files are rewritten through publish_data(entity_save=True, dont_post=True) (2917-2923), and the continual-publish loop re-posts from those files every tick, so a dry run that touches them changes the live plan within one cycle; and _record_optim_snapshot (47-90) records the run in last_run and the plan store, which is what /api/v1/plan and /api/v1/last-run serve. All three sit after the solve in the wrapper, so a flag that returns opt_res before them covers the executor-facing surfaces. The one write outside the wrapper is web_server's injection_dict.pkl (578-579), which is only the web UI plot, and the shared OptimizationCache object is the in-memory thing a dry run still touches: a different config evicts the live cached problem, and the next live solve warm-starts from the dry-run solution. I went through the same ground on #931 (RFC 0001, a registry sidecar that folds evcc-style demands into one EMHASS solve, so the opposite route to yours for the same contention), where run-keyed results came out as the prerequisite for any what-if solve to coexist with the live one. Your outside coordinator with dry_run is a concrete user for the query/scenario type MMicieli sketched there, so a cross-link may be worth it either way.

On the adapter. You build Optimization through its constructor and keep out of optimization.py, and I'd keep it that way. The per-inverter phase proposed in #1150 (go from scruysberghs, who is validating it, waiting on David) changes perform_optimization in its PR 3, which is where your dispatch sits, and the plant_conf the constructor takes already carries per-battery lists since #1032. One inverter and one battery stay pinned unchanged in both, so your current scope is safe, but if your PR 1 lands first it's worth saying which constructor arguments and which opt_res columns your tests pin, so a rebase conflict is the worst that happens. One naming point: participants keyed on battery and deferrable0 names the single-battery case your docs scope to (more than one battery falls back today). When that scope widens, the per-battery outputs since #1032 are P_batt_{k} / SOC_opt_{k}, and #1150 adds an inverter as a device kind, so keying participants on the same indices would keep the two in step.

Nothing above argues against the shape, the price-coordinated split is a good fit for the evcc case, and 0.09% worst case against the MILP on EMHASS's own models is a strong number.

[davidusb-geek]

I Ameet, thanks for opening this and for your contribution. I still need to take the time to review the proposed PR.
I am open to this direction. The federated approach solves a very real pain point. Especially the collisions with external optimizers like evcc. Getting within 0.09% of the MILP on our own models is a highly encouraging result.

Our primary guiding principle here is safety for the existing user base. Because this is an opt-in feature, we need absolute certainty that it introduces zero regressions or side effects for users sticking with the default cvxpy MILP backend.

LesIT brought up excellent technical hurdles that align exactly with this safety goal.

I think we can proceed with the federated backend proposal by checking that a strictly side-effect-free dry_run implementation and isolating adapter logic to prevent merge conflicts with concurrent updates.

[MMicieli]

Thanks Les — yes, this is directly related to the query/scenario work I was exploring in #931.

The main immediate value in this proposal is definitely the dry_run, independently of whether we ever adopt the federated backend. I run EMHASS as a rolling 5-minute MPC and use its current plan/last-run state as part of the production evidence/control chain. We also do quite a lot of counterfactual work around forecasts, battery modelling, terminal SOC, tariffs and other controller settings.

A native way to submit the exact same EMHASS optimisation request and get the resulting plan back without replacing the authoritative production plan would remove a fair amount of special-purpose shadow/replay machinery.

I agree with the distinction Les makes though: for that use case, “does not write files or publish entities” is necessary but not quite sufficient. I would want dry_run to leave the production optimisation context unchanged as well — in particular no mutation/eviction of the live OptimizationCache, no change to the warm-start state used by the next production solve, and no change to /api/v1/plan, /api/v1/last-run, continual-publish sources or other persistent state.

In other words, ideally:

same request + dry_run -> real EMHASS solve + returned opt_res, but no observable change to the next normal production solve other than CPU time

That would make it genuinely useful as a scenario/query primitive, including for an external coordinator.

For my installation the coordinated backend itself is a later question because I use EMHASS’s hybrid-inverter model and consume P_hybrid_inverter downstream for the Sigenergy control path, while the current federated scope falls back on hybrid configurations. If that scope expands later, I think preserving the existing first-action/output semantics (P_grid, P_batt, P_hybrid_inverter, SOC etc.) will matter at least as much as horizon-level objective parity for MPC users.

I would strongly support dry_run as a standalone capability if splitting the PR makes that easier to review/land. The cache/process-state isolation Les identified is the critical thing I would want down before relying on it against a live EMHASS instance.

[ameetdesh]

Thanks @LesIT1 and @MMicieli and @davidusb-geek . I believe the file side was already covered on the draft PR: a dry run against a live instance changes nothing under /data except the action log. The OptimizationCache wasn't, thanks for reporting this bug. On a hit, the dry run reconfigured and re-solved the live object itself. As of b122c34, a dry run builds a private Optimization and never reads or writes the cache, so the next live solve sees the same object, key, configuration and warm-start values. test_a_dry_run_leaves_the_live_optimisation_untouched pins this for both a hit and a miss. Happy to split dry_run into its own PR if that's easier to review.

[MMicieli]

Thanks @ameetdesh — I had another look through the latest changes after your response and the additional hardening in 277c2a4.

The dry_run implementation in particular looks much stronger now. Building a private Optimization rather than touching/restoring the live cache seems like the right boundary, and the added tests around cache/warm-start isolation, strict dry_run parsing, file writes and continual_publish address the main failure modes I was concerned about. The fallback validation around participants is also a useful improvement.

I did notice a few remaining things that may be worth considering as the RFC develops. None of these are intended as a redesign of the proposal, just observations from trying to think through how an external consumer could safely depend on the interface.

The generated OpenAPI currently appears to describe participants as an object, whereas the documented/runtime form is a list of participant objects. It may be worth making that schema explicit as an array, particularly if this eventually becomes an integration surface for external tooling.

I also wondered whether admm should remain out of the selectable optimization_backend values until the EMHASS adapter actually supports it. Having it documented as planned/reserved seems clear enough for now, while avoiding a configuration that is accepted by the UI/schema but ultimately falls back.

The other area I think may become important is distinguishing a usable coordinated plan from a proven optimiser status. DWResult already carries useful information such as stop_reason, bounds and gap, but the adapter currently appears to set optim_status = "Optimal" once it has a runnable coordinated result. If the coordinator stopped because of an iteration cap or stall, it might be more accurate long-term to preserve that distinction somehow rather than equating feasibility with proven optimality.

Related to that, some lightweight backend provenance could be useful. For example, knowing that dantzig_wolfe was requested but cvxpy actually produced the plan because of an unsupported option or coordinator failure would make fallback much easier to observe programmatically. The current fallback behaviour itself makes sense to me — retaining a valid household plan is preferable to failing the whole optimisation — this is more about making the actual solver path visible outside the logs.

For dry_run, two extra regression tests might also be useful if they fit naturally: confirming /api/v1/plan and /api/v1/last-run are unchanged across a dry run, and checking that the same frozen inputs produce the same result in an isolated ordinary solve and a dry run. The current tests already cover most of the underlying mechanisms, so these would mostly document the external contract.

I also had a look at home-energy-optimizer itself. The test coverage there is considerably stronger than I initially appreciated — including differential LP testing against HiGHS and the MILP-reference tests — which gives me more confidence in the direction. Given it is still marked Alpha, perhaps bounding the optional dependency to the current compatible series (for example <0.3) would be worth considering until the interface settles.

Overall, I think the latest changes answer the main concerns I raised around dry_run, and I can see a useful path for that capability independently of whether the coordinated backend is ultimately adopted by every EMHASS installation. The coordinated backend itself also makes considerably more sense to me now as an optional composability layer rather than a replacement for the existing CVXPY path.

Thanks again for taking the earlier feedback on board.

[ameetdesh]

Thanks @MMicieli, all fair and great points. Thank you for your thoughtful review. They're addressed in #1158 and in home-energy-optimizer 0.2.4.

1. participants schema. openapi.json now describes it as a list of objects (devices, solver, config). The device pattern, the solver enum and the size limits are the same ones the runtime check uses, and a test keeps them in sync. The web UI is unchanged: it's still a JSON text box. The generator now uses a param's explicit schema when its UI input type is too coarse to describe it. (8ee03a9)

2. admm. It's no longer selectable: optimization_backend offers only cvxpy and dantzig_wolfe. ADMM is documented as future work in docs/coordinated_backend.md. If someone sets it by hand, EMHASS logs that it isn't available yet and runs the default MILP. (288f827)

3. Optimal only for a proven plan: optim_status is now Optimal only when the plan is within 0.1% of the coordinator's lower bound.
   If the coordinator stops early (it stalls, hits its iteration cap, or runs out of new proposals), the status is Optimal_Inaccurate. That's still in OK_OPTIM_STATUSES, so the plan is published, but it isn't labelled as proven.
   New columns fed_stop_reason and fed_iterations say why it stopped and when.

4. Which solver made the plan: With a coordinator backend configured, every plan carries backend_requested, backend_used and backend_fallback_reason. After a fallback, backend_used is cvxpy and the reason names the option, the error or the missing package. A default configuration's results have exactly the same columns as before.
   The web page shows these values in the summary table.

5. Tests: /api/v1/plan and /api/v1/last-run serve identical responses before and after a dry run. The dry run uses different prices, so a leak would show.
   The same inputs, each solved from a cold cache, give an identical plan live and dry.

6. Dependency bound. The federated extra now requires home-energy-optimizer>=0.2.4,<0.3. 0.2.4 is the release that reports the adapter's fallback reason. The <0.3 cap keeps a future change to the interface from reaching existing installs until the interface settles. (9417fd9)

[davidusb-geek]

Just a thought. Rather than adding a new dependency, shouldn't it be wiser to just implement that optimizer backend directly in EMHASS?

[ameetdesh]

Frankly.. that would be best case scenario for home-energy-optimizer. I was worried the big diff would make review and acceptance difficult. We can also add dependency with understanding that eventually it will be merged in emhass. Up to the maintainers here. Let me know.

[ameetdesh]

Hi @davidusb-geek Let me know your thoughts on this (baking home-energy-optimizer within EMHASS). I see that carving out dry_run from this PR has the broader community support. I will do that shortly. For federated approach, it would be helpful set an interface standard for federation, so that individual components can evolve independently without breaking the interoperability.

The PyPi package currently implements url based federation between independent EMHASS (e.g. garage_emhass below) both running on LAN with token based trust model:

Also see https://pypi.org/project/home-energy-optimizer/#user-content-federated-planning-each-planner-keeps-its-data

{
  "optimization_backend": "dantzig_wolfe",
  "site": [
    {"id": "grid", "max_import": 12000, "max_export": 6000},
    {"id": "garage", "parent": "grid", "type": "panel", "max_import": 7400, "max_export": 0},
    {"id": "l1", "type": "limit", "max_import": 7000},
    {"id": "battery", "parent": "grid", "solver": "home_energy_optimizer"},
    {"id": "deferrable0", "parent": "grid", "group": "loads"},
    {"id": "deferrable1", "parent": "grid", "group": "loads"},
    {"id": "water_heater", "parent": "garage", "solver": "home_energy_optimizer", "limits": ["l1"], "config": {"power_kw": 3.0, "liters": 180.0, "t_comfort": 55.0, "n_duty_levels": 2, "comfort_weight": 10.0}},
    {"id": "garage_emhass", "parent": "garage", "solver": {"url": "http://192.168.1.20:5000/participant", "token_secret": "garage_token"}, "limits": ["l1"]}
  ],
  "costfun": "profit",
  ...
  }

[ameetdesh]

@MMicieli regarding the earlier fallback to cvxpy for hybrid inverter case, this use case is now supported on 0.2.6 (thanks for pointing this gap). Dantzig-Wolfe backend now supports hybrid inverter limits as well as any number of group limits (e.g. for circuit breakers). The side effect is that the prices are now defined at each sub-meter, and thus reflect local price for violating that limit, similar to the locational marginal price. Please see home-energy-optimizer 0.2.6 and section "A four-DER house".

I also created a single html wasm based UI to visualize this here.

[MMicieli]

I've completed an off-box qualification of the dry_run implementation in PR #1158, including additional adversarial testing beyond the existing upstream suite.

Overall, the results are encouraging. The private Optimization instance, cache isolation and preservation of the existing plan/last-run state appear to provide a sound foundation for a native, non-persisting optimisation interface.

I also appreciate the subsequent improvements to the coordinated backend, particularly hybrid-inverter support, local marginal pricing, backend provenance and the clearer distinction between feasible and proven-optimal solutions.

Independent validation

Testing was performed in an isolated WSL2 environment against PR #1158 at 2f1bf5f.

• 89 passed: existing upstream test_dry_run.py tests.
• 1,261 passed, 22 skipped, 32 xfailed: remaining upstream tests.
• 66 passed: additional adversarial tests covering live/dry parity, fault injection, cancellation, concurrent requests, cache and file-state isolation, SIGKILL/restart recovery and input-cache behaviour.
• Ruff checks passed.

Cold-start live and dry-run plans matched across naive-mpc-optim, dayahead-optim and perfect-optim.

The tested optimisation paths also preserved OptimizationCache, result files, /api/v1/plan and /api/v1/last-run, including across the exercised failure and restart scenarios.

Three findings may be worth considering before finalising the dry_run contract.

1. Concurrent requests can interfere with HTTP success/failure reporting

The web action handler currently uses check_file_log() to inspect a shared action log when determining the request's final HTTP status.

With a healthy request overlapping a failing optimisation, the healthy request incorrectly returned a non-200 response in approximately 17–20 of 40 trials, depending on the failure scenario.

The reverse also occurred: a failing request was occasionally reported as successful.

Importantly, the same behaviour reproduced with ordinary live/live requests, confirming this is a pre-existing request-isolation issue rather than something introduced by dry_run.

Nevertheless, a future scenario evaluator or external coordinator could exercise infeasible trial inputs frequently, making this interaction more visible.

Would it make sense to derive each request's HTTP outcome directly from its own execution result, rather than from errors in a shared log?

This could be addressed independently of the coordinated backend.

2. Forecast-cache writes occur outside the optimisation persistence guards

The optimisation-result and warm-start isolation tests passed, but input acquisition has separate persistence paths.

I demonstrated that Forecast.get_weather_forecast() can update cached-open-meteo-forecast-b.json when invoked with an input context marked dry_run=True, using mocked HTTP responses.

This was a focused forecast-function test, not proof that every normal dry-run HTTP request refreshes this cache. Other input-cache paths have been identified through source inspection but not all executed end-to-end.

The relevant question is whether dry_run promises:

1. Optimisation-state isolation: no changes to plans, last-run records, published entities, result files or solver cache; or
2. Full operational isolation: additionally preventing persistent changes to forecast caches, freshness state or other input-acquisition artefacts.

For reproducible counterfactual analysis, the stronger contract would be preferable, particularly where hypothetical queries share an EMHASS instance with production optimisation.

Would you consider either enforcing this boundary during input acquisition or documenting the narrower guarantee explicitly?

3. dry_run on unsupported actions

The current documentation correctly describes dry_run as an optimisation-action parameter.

However, publish-data still performs publication when supplied dry_run=true. My isolated test observed nine post_data calls with and without the flag.

This is not a failure of the supported optimisation dry-run paths. It is an API misuse risk: a caller could reasonably assume that an explicitly supplied dry_run=true prevents side effects.

One possible improvement would be to reject dry_run=true on actions that do not support it, rather than silently ignoring the parameter.

Suggested direction

dry_run as a standalone EMHASS capability, independently of whether an installation adopts Dantzig–Wolfe coordination.

For rolling five-minute MPC use case, the main benefit is being able to submit a hypothetical optimisation and retrieve its plan without affecting the next ordinary solve.

A native dry_run interface, combined with externally retained input provenance and appropriately matched economic scoring, should also support useful forecast-value and counterfactual experiments without requiring a separate optimiser or a new native regret-calculation framework.

My overall assessment is positive: the core optimisation-state isolation appears robust under the tested scenarios. The remaining questions primarily concern request-level error isolation, the precise scope of persistent input-state protection, and explicit API behaviour for unsupported actions.

These tests were entirely off-box, with no production EMHASS, Home Assistant or physical control interaction. The coordinated backend's remote-participant paths and real Home Assistant input path were not independently exercised.

[LesIT1]

+1 for splitting dry_run into its own PR. I'd use it straight away.

My setup is a rolling naive-mpc-optim every 15 minutes driving a home battery, with the plan read back from /api/v1/plan. The grid import cap is enforced outside EMHASS by my own controller, so what I want from dry_run is shadow evaluation: the live payload with maximum_power_from_grid as a per-step list that leaves room for an EV charge, to see whether the plan still reaches soc_target and what the cap costs, before deciding whether to pass the cap into EMHASS at all. Right now the only clean way to do that is a second instance kept in step by hand.

On MMicieli's three findings, from where I sit:

Finding 3 matters most to me. Today an unknown runtime key is just ignored, so a client that sends dry_run: true to a release without the feature gets a normal solve that replaces the live plan. A line in the docs saying which release first honours it would let callers gate on version. Rejecting dry_run on actions that don't support it is the same idea on the new side: a caller should never get a silent publish after asking for a dry run.

Finding 2 doesn't bite me, since PV, load and price all go in as lists, but I'd still like the guarantee written down. Optimisation-state isolation with the forecast caches called out as not covered is fine, as long as it's explicit.

Finding 1 I avoid by serialising every EMHASS call on my side, and the dry-run response carries optim_status on each row, so I don't have to trust the HTTP code. It's still a real bug for anyone running a coordinator against a shared instance. The wrapper's False already maps to a 400; what leaks is the scan of the shared action log for ERROR lines afterwards. If nobody's on it I'm happy to put up a separate PR that scopes error capture to the request and reads optim_status from its own result.

[OptimalNothing90]

Another +1 for splitting dry_run into its own PR, from the sidecar side of #931.

The use case is concrete. The registry sidecar from RFC 0001 folds the active demands into one naive-mpc-optim call each cycle and reads the result back from /api/v1/plan. The next step on its roadmap, MMicieli's query and what-if type from #931 ("what would the plan look like if the car had to be at 80 % by 17:00", "what does this import cap cost"), cannot be offered today because a scenario solve against the live instance replaces the live plan, feeds continual_publish and updates the plan store. dry_run as specified in #1158, the same request, a real solve, the plan in the response and nothing written, is exactly the primitive that makes those queries possible without a second instance kept in step by hand.

Two of the points already raised matter to that consumer in particular, and I would put them in the contract rather than the docs alone: a release that does not know the flag must not run a live solve when asked for a dry one (so a caller can gate on a version or capability signal, as LesIT1 said), and actions that cannot honour the flag should reject it rather than ignore it (MMicieli's finding 3). The narrower isolation guarantee, optimisation state only with forecast caches called out as not covered, is fine for this use if it is written down.

The revised RFC 0001 states this dependency and the relation to this proposal explicitly: https://github.com/OptimalNothing90/emhass-contributions/blob/main/rfcs/0001-shared-plan-registry.md.