Investigating a studio performance regression

The output is a verdict with evidence: culprit commit/PR, host or harness artifact, or noise. Trend points are host-relative daily samples; only an interleaved A/B run decides. Data access and query shapes are in the sanity-radar skill (references/groq-recipes.md); dispatching runs is in sanity-bench.

Rules that keep the verdict honest

• Never conclude from two absolute points. Run-to-run noise on main is ~12% at the median, above the gate's 5% threshold. A point-to-point delta is a hypothesis, an A/B verdict is evidence.
• Read the host first. runner.calibrationMs (higher = slower) and runner.cpuModel per run and per scenario shard. A metric step that coincides with a calibration step, or a CPU model change, is the host until an A/B says otherwise. GitHub rotates runner hardware under the same vCPU shape.
• Check the instrument. A Playwright/Chromium bump moves INP and vitals with no studio change (runner.browserVersion). A change under perf/bench/ (scenario, mock, harness) moves everything in that scenario at once.
• ⚪ inconclusive means widen, not shrug. The CI stayed too wide within the budget; re-dispatch, or look at which side had failures (scenarios[].failures).
• A level step is not a leak. DOM nodes, listeners or heap moving to a new plateau (and staying) is a behavior change; the soak slope (soak) is what detects leaks.
• Say what you did not verify. A shortlist is a shortlist until a dispatch confirms it.

Procedure