Cheaper, cleaner day-ahead generation schedule

Independent audit in a few minutes:
1. Download data/grid-uc-instance.json (the fixed instance) and the submitted artifact (JSON: {"on": [...], "p": [...]}).
2. Run: node scripts/audit-grid-unit-commitment.mjs <artifact-file> [instance-file]
   This is a small, dependency-free script that recomputes every check independently of the verifier and prints PASS/FAIL plus fuel_cost, noload_cost, startup_cost, total_cost, co2_tonnes and min_reserve_margin_mw.
3. Compare its printed total_cost (and feasible:true/false) against the submission's reported Verdict.detail -- they must match exactly (costs are simple sums of linear terms, so this is exact arithmetic, not an approximation).
4. Spot-check by hand for a couple of hours: pick an hour h, sum p[g][h] across all "on" generators and confirm it equals demand_mw[h]-wind_mw[h]-solar_mw[h]; sum (pmax_g - p[g][h]) across "on" generators and confirm it is >= 0.05*demand_mw[h].
5. Spot-check one generator's min-up/min-down: pick a generator that switches state at some hour h, and confirm it had spent at least min_up (if it was on) or min_down (if it was off) hours in that state, counting its init_hours if the state extends back before hour 0.
What a dishonest or broken submission looks like: reports a low total_cost while actually violating the power cap or reserve in one hour (e.g. rounding p up past pmax "just a little"); commits a generator on for fewer hours than its min_up and then claims it satisfies the schedule anyway; or reports demand met "on average" over the day instead of exactly every single hour. Any one of these makes checkFeasibility (and the auditor script) report the exact hour and generator of the first violation, so a submission that is actually infeasible cannot produce a matching total_cost from the auditor.

Background. Day-ahead unit commitment (UC) is the classic power-systems scheduling problem: given a fleet of generators with different costs, emissions, and physical constraints, decide which to turn on/off and how much to produce each hour to meet forecast demand at minimum cost, while keeping enough committed-but-unused capacity ("spinning reserve") to survive a sudden outage or forecast error. Real-world UC formulations use quadratic or piecewise-linear cost curves and many more constraints (ramp rates, transmission limits, must-run contracts); this mission uses a linear-cost, single-node simplification so that costs are exact sums a human can recompute by hand, while keeping the parts that make UC hard: integer on/off decisions, minimum up/down times, and a reserve requirement that competes with cost minimization.

Instance. The fixed instance lives at data/grid-uc-instance.json (fetched by the verifier via ctx.data("grid-uc-instance.json")), generated by scripts/gen-grid-instance.mjs with a fixed seed (20260903) -- running that script again reproduces the identical file (same sha256). It contains:
{
  "hours": 24,
  "reserve_pct": 0.05,
  "generators": [
    {"id":"BL01","pmin":180.5,"pmax":420.3,"no_load_cost":1120.0,"fuel_cost":21.34,"co2_rate":0.91,"startup_cost":31000.0,"min_up":10,"min_down":10,"init_on":1,"init_hours":14},
    ... (60 generators total: baseload/coal, CCGT gas, OCGT peakers, oil peakers)
  ],
  "demand_mw": [ ... 24 hourly values ... ],
  "wind_mw":   [ ... 24 hourly values ... ],
  "solar_mw":  [ ... 24 hourly values ... ]
}
Units: MW for power, $/MWh for fuel_cost, $/h for no_load_cost (paid every hour the unit is committed, regardless of output), $ for startup_cost (paid once, the hour a unit switches from off to on), t/MWh for co2_rate, hours for min_up/min_down. "init_on"/"init_hours" describe the generator's state immediately before hour 0 (already on or off, and for how many consecutive hours), so min-up/min-down can bind at the very start of the horizon. Net demand thermal generators must cover each hour is demand_mw[h] - wind_mw[h] - solar_mw[h] (wind and solar are fixed, zero-cost, zero-emission must-take injections, not decisions you make). The spinning reserve requirement each hour is reserve_pct * demand_mw[h] (based on gross demand), and must be covered by unused capacity of generators that are ON: sum over on generators of (pmax - p) >= reserve_req[h].

Artifact format. A single JSON object:
{"on": [[0/1, ...24 values...], ...60 rows...], "p": [[MW, ...24 values...], ...60 rows...]}
Row g of both arrays corresponds to generators[g] in the instance (same order, same length: 60). Column h is hour h (0..23). Tiny worked example for a 2-generator, 3-hour toy instance (not the real instance, just to show the shape): on=[[1,1,0],[0,1,1]], p=[[100,80,0],[0,50,60]] means generator 0 runs hours 0-1 at 100 then 80 MW then shuts off, and generator 1 is off hour 0, then runs hours 1-2 at 50 then 60 MW.

Verification, in exact order (see src/verify/grid-unit-commitment.ts, mirrored by scripts/audit-grid-unit-commitment.mjs):
1. Shape: "on" and "p" must each have exactly 60 rows of 24 finite numbers.
2. On/off consistency: on[g][h] must be 0 or 1; when 0, p[g][h] must be 0 (within 1e-6); when 1, p[g][h] must be within [pmin_g, pmax_g] (within 1e-6).
3. Demand: for every hour h, sum_g p[g][h] must equal demand_mw[h]-wind_mw[h]-solar_mw[h] within 1e-6.
4. Reserve: for every hour h, sum over on generators of (pmax_g - p[g][h]) must be >= reserve_pct*demand_mw[h] within 1e-6.
5. Min-up/min-down: for every generator, every state switch must occur only after >= min_up hours on (to switch off) or >= min_down hours off (to switch on), counting init_hours as already-elapsed time in the init_on state before hour 0.
The first check that fails stops verification and is reported as Verdict.detail.first_violation (null when feasible). If all checks pass, score = total_cost = sum_{g,h: on} p[g][h]*fuel_cost_g + sum_{g,h: on} no_load_cost_g + sum over every off->on switch of startup_cost_g. Direction is "min" (lower cost is better). Verdict.detail always includes feasible, hours, generators, fuel_cost, noload_cost, startup_cost, total_cost, co2_tonnes, min_reserve_margin_mw, and first_violation.

Target and record -- how they were derived. scripts/gen-grid-instance.mjs also implements (and runs) a reference baseline: a merit-order greedy commitment (cheapest fuel_cost first, committing generators until capacity covers net demand plus reserve), a causal hour-by-hour repair that never switches a generator before its min-up/min-down has elapsed (adding or shedding only currently-unlocked generators to stay capacity-feasible), a merit-order economic redispatch (load committed units cheapest-first up to pmax), and a short local-search pass that tries deleting each generator's whole "on" run when the rest of the fleet can still cover demand+reserve, keeping the deletion only if it lowers cost. This is a simple, auditable reference implementation, not a state-of-the-art UC solver (no MILP solver, no Lagrangian relaxation, no ramp-rate-aware smoothing) -- do not read "target" as a claim about the best possible schedule. Running it against the fixed instance gives:
  target = $4,667,435.31  (this baseline's total cost -- beat this to be "solved")
  record = $4,527,412.25  (3% below target -- a genuinely good UC solver should clear this)
CO2 from that same baseline schedule is about 90,132.25 t, reported for context (CO2 is not the scored metric here, cost is; a legitimate strategy can lower CO2 as a side effect of dispatching cleaner units first when it's also cheap, but is not required to).

Attack strategies.
1. Greedy + local search (the baseline's own approach, reimplementable from scratch): merit-order commitment, causal min-up/min-down repair, economic redispatch, then local search over which "on" runs to keep. Improve on the reference baseline's local search by trying more move types: shifting a run's start/end by 1 hour, swapping which of two similar generators covers a given block, or restarting local search from several different merit-order tie-breaks.
2. Lagrangian relaxation: relax the demand and reserve constraints with multipliers, decompose into a per-generator dynamic program (find the cheapest on/off/output path for one generator given multiplier prices), and update multipliers with a subgradient method. This is the classical textbook approach to UC and can beat pure greedy without needing a general MILP solver.
3. MILP formulation: model on[g][h] as binary, p[g][h] as continuous, with standard min-up/min-down constraints (e.g. the Rajan-Takriti or Malkin formulation) and feed it to any MILP solver you have locally (e.g. HiGHS, CBC, or a Python/JS binding to one); 60 generators x 24 hours is a small enough instance for an off-the-shelf solver to likely close the gap to optimality or get very close, well past the record tier.
4. LP relaxation + rounding: relax on[g][h] to [0,1], solve the LP, round to integers with a repair pass (similar to the baseline's causal repair) to restore min-up/min-down and demand/reserve feasibility, then re-dispatch.

Pitfalls: forgetting that no_load_cost is paid every hour a unit is on (not just once) is a common source of underestimating cost; forgetting that net demand subtracts wind and solar (not gross demand_mw) will produce a schedule that either wastes capacity or fails the demand check; the reserve constraint is checked with the ON generators' actual dispatched p, not their pmin, so running units near pmax to save fuel can quietly blow the reserve requirement; and min-up/min-down must account for init_hours -- a generator that is only 2 hours into an init_on state with min_up=8 cannot switch off at hour 0-5 even though it "looks like" hour 0 is a fresh start.