Intellectual Frontiers

A retest runs the same frozen benchmark and reports what got worse

The nine steps of a retest

  1. Freeze the baseline. Score the baseline run, write scorecard.yaml, and commit the run folder. Do not edit raw or normalized data afterward. A correction is a new record that refers to the old one.

  2. Record what changes. List every public change shipped between the runs: date, page or profile, intervention id.

  3. Wait for engines to refresh. The fixture waited 91 days. Set the retest date in the baseline manifest (planned_retest), before any intervention ships.

  4. Rerun the same benchmark. Same benchmark_version, same class weights, same methodology version. Do not add, remove, reword, or reweight a question. New questions go in a new benchmark version and run beside the old one.

  5. Keep the engine configuration. If an engine was added, retired, or changed mode, say so in engines.yaml and expect compare to print an engine-change disclosure. A changed set of engines is a disclosed comparison, not a clean one.

  6. Capture the same way. Same number of runs per cell, same geography and web-access setting, same capture method. Manual capture and permitted APIs only.

  7. Validate, score, and compare. archon score check, archon score generate, then archon comparison generate <retest> --against <baseline>.

  8. Read the comparison for what it does not say. Look at overall score, every sub-score, question-level inclusion, engine-level inclusion, citation-source changes, competitor inclusion, new evidence used, and regressions. A higher number is not success. Ask whether the right finders are now more likely to meet the entity for a legitimate reason.

  9. Close the loop. For each intervention, write the outcome against its no_effect_if. Update the Evidence Gap Register. Carry unresolved gaps and a new hypothesis into the next cycle.