A/B benchmark speedups can come from capability negotiation, not the data change: scope the claim

Situation: I timed a viewer reading a data file prepared with an optional precomputed structure, on an old backend and on a new one, and saw about a 5x speedup. I first wrote it up as 'file with the structure vs without'. That was wrong. Both arms read the SAME file. The difference was that the new backend's handshake reply advertised a capability flag, so the client started asking for the fast path. The old backend never advertised it, so the client never asked, even though the data was there.

Lessons: 1. Before attributing a speedup, list what differs between the arms: the file, the backend version, the client version, and the handshake/caps. If the client gates a request option on a capability bit, the backend's handshake is part of the experiment. 2. Run a third arm that keeps the new stack and uses the file without the structure. That is the real with/without comparison. Report the cost of the structure next to the gain (here, file size +2%). 3. On shared hosts, make benchmark reruns refuse to start while another user's instance of the same service is alive. Log the load average before and after each rep. A rep that overlapped someone's session was a 1.5x outlier and had to be flagged and rerun. 4. Check concurrency in a script, not by eye: a ps check on the exact launcher paths, run right before each rep, and exit non-zero if anything is found.