Experiment — no claim without a measurement
Optimization needs numbers; null results get recorded too.
1. Define the metric before touching code
Choose one command that prints the number: runtime, RSS, latency, size, or count. Decide now what improvement would count, before seeing results. If no metric command exists, build it first.
2. Baseline
Run at least 3 times and record all values, not only the mean. Pin what you can: seed, input, cache state, and environment; state what remains uncontrolled. Correctness verify must be green before and after.
3. One variable per experiment
Change one thing. Multiple changes make the result uninterpretable.
4. Measure again
Use the Same command, same repetitions, same conditions. A result must beat the baseline spread; Inside the noise = null result.
5. Verdict and record
Follow the repository's existing experiment log; otherwise create and append to
docs/experiments.md:
## <date> — <hypothesis>
change: <one variable>
baseline: <all values> | result: <all values>
verdict: WIN <n%> | NULL (inside noise) | LOSS
decision: <kept or reverted + reason>
Losers and nulls are reverted immediately; the log preserves the finding, not
the bad diff. A null result is a finding—record it so it is not retried without
new evidence. Never delete a previous entry; append a correction when later
evidence overturns it. Route load-bearing nulls through /retro.