# Best-so-far results and final verification

We consistently report best-so-far performance during search as the endpoint for all methods. Final verification separately checks the correctness and performance of the restored selected implementation. These evaluations occur in different measurement batches, so their latency values need not be identical. Figure 4 explicitly reports both measurements, while Figures 5 and 6 show best-so-far search progress.

For MinGPT, the selected iter-53 implementation achieved 3.831 ms during search, 3.880 ms in an unchanged repeat at iter-58, and 4.138 ms in final verification. The source and configuration are identical across these snapshots, and all three evaluations passed correctness checks. The repeat differs from the original measurement by only 1.28%. The 8.0% best-to-final latency increase is consistent with between-evaluation measurement variability of an unchanged implementation; it does not reflect a source-code change during restoration. Final verification still achieves a 10.864× speedup.

Across methods, the median absolute best-to-final latency change ranges from 0.65% to 1.05%, and more than 90% of successful runs in each method have an absolute change of at most 3%. All methods follow the same endpoint-reporting and final-verification rules, with the same evaluator and timing boundary within each platform. As a sensitivity analysis, using final-verification values for every method changes each method's overall mean speedup by less than 0.56%. AKO+TileCas retains approximately 29.4% higher mean speedup than both Random and Fixed, while KDA+TileCas retains approximately 69.5% higher mean speedup than KDA. These results support the robustness of the principal aggregate performance conclusions to the observed remeasurement differences, including the MinGPT example. This sensitivity analysis supplements the consistently applied best-so-far reporting convention.