Shift compute to low-carbon hours

Independent audit in a few minutes:
1. Download data/carbon-sched-instance.json (the fixed instance) and the submitted artifact (JSON: {"start": [...], "hours": [...]}).
2. Run: node scripts/audit-datacenter-carbon-scheduling.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 total_kwh, total_co2_kg, cost_usd and peak_load_kw.
3. Compare its printed total_co2_kg (and feasible:true/false) against the submission's reported Verdict.detail -- they must match exactly (CO2 is a simple sum of power_kw * carbon_g_per_kwh[h] / 1000 over every scheduled job-hour).
4. Spot-check by hand: pick a non-preemptible job, confirm start+duration_hours-1 <= deadline_hour and start >= release_hour; pick a preemptible job, confirm its "hours" array has exactly duration_hours distinct integers all inside its window. Pick one hour, sum power_kw across every job scheduled during it (from either "start" ranges or "hours" lists) and confirm it does not exceed cap_kw.
What a dishonest or broken submission looks like: reports a low CO2 total while actually running a job partly outside its deadline window (e.g. "close enough"); double-books hours for a preemptible job so it appears to finish in fewer wall-clock hours than duration_hours actually allows; or exceeds the power cap in exactly one hour by a small amount, betting nobody checks every one of the 168 hours by hand -- the auditor script checks all of them.

Background. Deferring flexible compute to low-carbon hours is a real, already-deployed idea: several major cloud and hyperscale operators publicly describe shifting non-urgent batch and training workloads to track grid carbon-intensity forecasts, because grid carbon intensity can vary several-fold within a single day -- driven mainly by solar generation peaking at midday and fossil "peaker" plants covering the evening demand ramp when solar drops off. This mission gives you a fixed week (168 hours) of jobs and a fixed carbon-intensity forecast, and asks for a schedule that minimizes total emissions without missing any deadline or exceeding a shared power cap. The instance's carbon trace is synthetic -- shaped from the well-documented general pattern (midday trough, evening peak, weekend/weekday variation) -- and is explicitly NOT a specific country's or grid operator's real measured data; treat it as a realistic-shaped exercise, not a claim about any actual grid.

Instance. The fixed instance lives at data/carbon-sched-instance.json (fetched by the verifier via ctx.data("carbon-sched-instance.json")), generated by scripts/gen-carbon-instance.mjs with a fixed seed (20260903) -- running that script again reproduces the identical file (same sha256). It contains:
{
  "horizon_hours": 168,
  "cap_kw": 6016,
  "carbon_g_per_kwh": [ ... 168 hourly values ... ],
  "price_usd_per_kwh": [ ... 168 hourly values ... ],
  "jobs": [
    {"id":"J0001","duration_hours":4,"power_kw":37.9,"release_hour":12,"deadline_hour":58,"preemptible":true},
    ... (500 jobs total)
  ]
}
Every job draws a fixed power_kw the entire time it runs (so running it for 1 hour uses power_kw kWh of energy). A non-preemptible job must run as one uninterrupted block of duration_hours consecutive hours, entirely inside [release_hour, deadline_hour]. A preemptible job may split its duration_hours hours of work anywhere inside its window, in any (not necessarily contiguous) set of hours, as long as it totals exactly duration_hours distinct hours. cap_kw is a single constant power ceiling that the sum of every job's power_kw running at that hour must never exceed, checked every one of the 168 hours.

Artifact format. A single JSON object with two parallel arrays, one entry per job (same order, same length as instance.jobs):
{"start": [hour or null, ...500 values...], "hours": [array-of-hours or null, ...500 values...]}
For a non-preemptible job at index i, start[i] must be the integer hour it begins (hours[i] is ignored). For a preemptible job at index i, hours[i] must be an array of exactly duration_hours distinct integer hours inside its window (start[i] is ignored). Tiny worked example for a 3-job toy instance (not the real instance): jobs = [{duration_hours:2,release_hour:0,deadline_hour:5,preemptible:false}, {duration_hours:3,release_hour:0,deadline_hour:10,preemptible:true}, {duration_hours:1,release_hour:2,deadline_hour:4,preemptible:false}]; a valid artifact is {"start":[0,null,3],"hours":[null,[1,4,7],null]} -- job 0 runs hours 0-1, job 1 (preemptible) runs at hours 1, 4, and 7, job 2 runs at hour 3.

Verification, in exact order (see src/verify/datacenter-carbon-scheduling.ts, mirrored by scripts/audit-datacenter-carbon-scheduling.mjs):
1. Shape: "start" and "hours" must each be arrays of length 500 (one entry per job).
2. Release/deadline window + total hours per job: every non-preemptible job's block [start, start+duration_hours-1] and every preemptible job's "hours" array (exactly duration_hours distinct entries) must lie entirely inside [release_hour, deadline_hour].
3. Hourly power cap: for every hour 0..167, the sum of power_kw over every job scheduled during that hour must not exceed cap_kw.
The first check that fails stops verification and is reported as Verdict.detail.first_violation (null when feasible). If all checks pass, score = total CO2 in kg = sum over every scheduled job-hour of power_kw * carbon_g_per_kwh[hour] / 1000. Direction is "min" (lower emissions is better). Verdict.detail always includes feasible, jobs, horizon_hours, total_kwh, total_co2_kg, cost_usd, peak_load_kw, cap_kw, and first_violation. cost_usd (using price_usd_per_kwh) is reported for context but is not the scored metric.

Target and record -- how they were derived. scripts/gen-carbon-instance.mjs implements two simple, auditable reference schedulers (neither is claimed to be optimal):
  - "run it now" (defines target): process jobs in ascending release_hour order; for each, place it at the earliest hours where the power cap still has room (a non-preemptible job takes the earliest feasible contiguous block; a preemptible job greedily fills the earliest hours with spare capacity). This is carbon-blind by construction -- exactly what a scheduler with zero carbon-awareness would do.
  - "earliest-deadline-first over cheapest carbon hours" (defines record): process jobs in ascending deadline_hour order; for each, place it at the lowest-carbon hours available to it within its window that still respect the power cap (cheapest hours first for preemptible jobs; the lowest-total-carbon contiguous block for non-preemptible jobs).
Running both against the fixed instance gives:
  target = 65,354.13 kg CO2  ("run it now" baseline's total -- beat this to be "solved")
  record = 46,490.39 kg CO2  (the EDF-over-cheapest-hours baseline's total, about 29% lower than target -- a genuinely carbon-aware scheduler should be able to clear this, since real deployments of this idea report double-digit-percent reductions)
Both baselines schedule the same 190,685.10 total kWh of work (moving jobs in time doesn't change how much energy they use, only when), so the CO2 difference between target and record is entirely due to which hours the work lands in.

Attack strategies.
1. Reimplement and beat the EDF-cheapest-hours baseline directly: process jobs in some order (deadline order is a reasonable start, but try others), and for each, greedily pick its lowest-carbon feasible hours given what's already been committed. Improve on the reference by trying multiple job orderings and keeping the best, or by a second pass that re-shuffles already-placed preemptible jobs' hours when capacity frees up.
2. Lagrangian relaxation / LP relaxation + rounding: relax the power cap into a penalty (or solve a continuous relaxation where "fraction of a job" can run at fractional hours), then round to a feasible integer assignment with a repair pass, similar in spirit to the grid-unit-commitment mission's approach.
3. MILP formulation: for non-preemptible jobs, a binary start-time indicator per (job, feasible start hour) with cap constraints per hour; for preemptible jobs, a binary per (job, hour) with a per-job total-hours constraint. 500 jobs over 168 hours is a moderate-sized MILP that an off-the-shelf solver (HiGHS, CBC, OR-Tools) can likely handle well within the record tier.
4. Local search on top of any feasible schedule: for preemptible jobs, try swapping one scheduled hour for a cheaper still-feasible hour within the job's window; for non-preemptible jobs, try shifting the whole block earlier or later within its window if a lower-total-carbon position exists and the cap still holds.

Pitfalls: forgetting that "hours" for a preemptible job must be exactly duration_hours *distinct* hours (repeating an hour to "finish early" is rejected); computing the power cap check per-job instead of by summing all jobs' concurrent power at each hour (many jobs share hours; the cap applies to the sum, not to any single job); assuming a job's flexibility window (deadline_hour - release_hour) can always be used freely -- most jobs in this instance are guaranteed at least 6 hours of slack beyond their minimum run length, but shifting a job too aggressively toward a single very-cheap hour that many other jobs also want can blow the shared power cap, as the record baseline's own history shows (it had to fall back to a next-best hour whenever the very cheapest one filled up); and remembering that CO2 (the scored metric) and cost_usd (reported for context) usually move together but are not identical, since price and carbon intensity are correlated but not equal in this instance.