The nine steps of a retest
-
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. -
Record what changes. List every public change shipped between the runs: date, page or profile, intervention id.
-
Wait for engines to refresh. The fixture waited 91 days. Set the retest date in the baseline manifest (
planned_retest), before any intervention ships. -
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. -
Keep the engine configuration. If an engine was added, retired, or changed mode, say so in
engines.yamland expectcompareto print an engine-change disclosure. A changed set of engines is a disclosed comparison, not a clean one. -
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.
-
Validate, score, and compare.
archon score check,archon score generate, thenarchon comparison generate <retest> --against <baseline>. -
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.
-
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.