| name | egret |
| description | Progressive-disclosure workflow for Egret market and operations optimization. Use whenever the user wants to run DC-OPF, AC-OPF, or unit commitment through PowerMCP — even when they just say "what's the cheapest dispatch", "commit the units", "check for congestion", or "is this schedule feasible". Exposes the simplest credible optimization (DC-OPF) before escalating to AC-OPF or full unit commitment. Reach for this instead of answering Egret optimization questions unaided. |
Egret workflow
Start with the cheapest model that can answer the question. Do not jump into unit commitment when a single-snapshot OPF will do.
Default tool ladder
solve_dc_opf(case_file, solver, return_results) for fast feasibility and congestion screening.solve_ac_opf(case_file, solver, return_results) when voltage or reactive realism matters.solve_unit_commitment_problem(case_file, solver, mipgap, timelimit) only after the horizon, reserve logic, and commitment assumptions are clear.
Working rules
- Confirm the case file format, solver, and time horizon before solving.
- Use DC OPF first unless the question explicitly depends on AC feasibility.
- Treat UC as a higher-cost study that needs a clear operational objective.
- Validate promising dispatch fixes in an AC tool when voltage limits matter.
Escalation triggers
Quote the binding constraint or infeasibility cause rather than saying "it failed".
| Observation | Escalate to |
|---|
| OPF or UC infeasible, reserve-short, or implausibly expensive | operations-planning-mitigation |
| AC-OPF bus voltage outside [0.95, 1.05] pu | voltage-violation-mitigation |
| A branch limit binds persistently across the horizon | thermal-overload-mitigation |
Deliver
- The case, solver, and study type.
- The limiting constraints or binding tradeoffs.
- Whether the next step is AC validation, UC escalation, or mitigation.
