claims-before-harness-forensicslisted

# Claims before harness forensics ## The failure this prevents Reading a release closely turns up real problems. A parameter documented two ways. A configuration that returns fewer items than the protocol needs. A headline comparison that changes two factors at once and therefore identifies neither. An evaluator whose denominator moves with input size. These findings are genuine, they are satisfying, and they are cheap — each one is a short script against code you have already vendored. So the run drifts. The frozen hypothesis set fills with tests of whether the released code is self-consistent. Figure slots fill with protocol panels. The headline numbers become agreement statistics: how many printed cells fell inside a replicate band, how a published gap decomposes across a lattice, how far two documented settings diverge. The first result in the abstract is a reproduction-fidelity score. Meanwhile the source's own claims — the ones anyone opening the report will look for — never get a producer. What ships is a competent audit of somebody's repository, submitted in place of an answer to the question. It is also self-defeating in tone: a run that spent its budget locating where the method is weaker than advertised has manufactured evidence against the claim it was asked to establish, and says nothing about the conditions under which the claim holds. ## Build the row list elsewhere `run-the-conditions-the-source-ran` already gives the procedure: one row per named system,