R-0046: evidence review of LH013 version 0.1

Reviewed: studies/LH013/LH013.md version 0.1 (committed as 04b1b97), against studies/LH013/brief.md (edition 0.1) and amendments.md (1 to 4, amendment 4 written today), scripts/, the retained data in data/, the figure older_three_weeks.svg, and LH012's record (version 0.4) and retained W0 files (studies/LH012/data/reference.csv, versions.csv, analysis/week.csv and python.csv, week/versions/ and week/python/) and studies/LH012/review/r0018_walkshare.py, whose definitions measure 4 fixes. Reviewer: evidence-review subagent in Claude Code on Opus 5.5 (claude-opus-5-5, as reported by its harness), dispatched by the driving session of run 2026-11-02T1524Z. Same model family as the writer; a second agent's agreement is a review contribution, not independent confirmation. Date: 2 November 2026. Outcome: fixed and ready for the reader-and-inference review. The record is now version 0.2. No outcome, holding count, interval, label or test result changed; nothing that must be fixed remains in the record.

What I checked, and how

• Order and pre-registration. The brief verifies against snapshot_sha256.txt (3e15eab6...). All 13 files in data/pre_counts_sha256.txt and analyse.py's hash in data/analysis_script_sha256.txt verify. From data/read_log.csv (217 rows), the stages ran in the order the brief needs: eligibility (15:30:05 to 15:30:12, dates only, plus one system.parts read), days held (15:30:24, SELECT DISTINCT project, date), PyPI metadata (15:30:25 to 15:30:35), documentation (15:32:52 and 15:32:53), a syntax test on literal rows (15:33:37), then the W0 check (15:34:51, pypi_downloads_per_day_by_version, W0 dates only), and only after it the gap-rule totals (15:34:55, the first read of any W1 or W2 count), the per-version sums, the by-Python sums and the 74 cell passes (to 15:38:45). The brief puts the metadata read after the eligibility check and before any count, and the W0 check before any count of W1 or W2; both hold. Amendment 4 and the pre-count hashes were taken before the W0 check: pre_counts_sha256.txt has a modification time of 15:34:51.09 and the W0 query is logged at 15:34:51 with one-second resolution, so the order within that second rests on the agent's account and the phase gate in scripts/common.py, not on the files. The snapshot is a hash file, not a commit; the record says so. Amendment 4 changes no question, week, R0, measure, field, threshold or convention; it fixes mechanics the brief left open, and I found none that would have favoured an outcome.
• Independent recomputation. studies/LH013/review/r0046_reproduce.py, written without importing or calling the study's scripts, rebuilds from the retained count files (data/counts/, LH012's W0 counts and data/versions.csv): the W0 check (37 of 37 totals and 259 of 259 daily totals equal), the days held (518 of 518), LH011's gap rule over the 37 (no gap day; the lowest day is 0.688 of its seven-day median), every project-week's O (111, all equal to older.csv), P lower and upper and class (111, all equal to python.csv; W0 classes equal to LH012's for 37 of 37), admission constant within each week (no project, week and minor differs between week start and end), C and C5 with their cells and cells carrying half (74, all equal to cells.csv), the four holding counts, project-resampled intervals with my own resampler and two seeds (each the record's, to one decimal), the CI split (amendment 3), the four boto3 tests, boto3's Python 3.9 flatness, block medians and the 1.42.87 ratio, and the walk-shaped share pooled and per project (17.1, 16.1, 17.5; boto3, aiobotocore, botocore, anyio, fsspec, grpcio-status and litellm as recorded). Output: review/r0046_reproduce.txt. The study's own replay (sh studies/LH013/replay.sh) also passes, byte for byte.
• Spot-check at the source. Six reads, logged with times in review/r0046_spotcheck_log.txt (15:55:54 to 15:55:55 UTC, user demo, anonymous): boto3's, litellm's and pydantic-core's W1 and W2 totals, pydantic-core 2.50.0's W2 count and boto3's W2 Python 3.9 count all equal the retained files to the download. Two PyPI JSON reads (15:55:55 UTC) for pydantic 2.14.0 and 2.14.2's requirement on pydantic-core.
• Every figure in the record against data/analysis/results.txt, the CSVs and post_hoc_reading.txt, and the Answer sentence by sentence for how sure it sounds.
• The figure, rendered with the container's headless Chromium at 720 by 700 in light and dark (--blink-settings=preferredColorScheme=0), read as images, and its 111 marks checked against older.csv by parsing the SVG (review/r0046_figure_check.txt: none off by more than 0.6 pixel).

What I found

1. Five misrounded figures (fixed). The CI split for boto3 and certifi in the record did not match cells.csv: boto3's older and at-or-newer shares flagged CI are 6.6 (record 6.5) and 33.3 (33.2) in W1 and 34.5 (34.4) in W2; certifi's 53.3 (53.2) and 38.9 (38.8). Not in results.txt, so the writer's hand rounding; no conclusion depends on them.
2. The staircase ranges in the Answer were narrower than the data (fixed). 0.1 said "near 860,000 to 900,000 ... then near 535,000 to 550,000, then near 110,000 to 126,000". The block medians in results.txt run 849,017 to 902,122 in the first five blocks, 519,505 to 549,880 in blocks 6 to 25 and 106,131 to 127,136 in blocks 26 to 40 across W1 and W2. Now about 850,000 to 900,000, 520,000 to 550,000 and 106,000 to 127,000, labelled described, not tested.
3. The near-ties reading understated and not fully labelled (fixed). post_hoc_reading.txt shows the ten non-litellm changes of the largest cell within 2.09 points in both weeks and within 0.73 in at least one; 0.1 said "within 2.1 in at least one", true but weaker than the data, and called it "read after the counts" in the Answer without the number of cases. Now labelled post hoc over twelve cases, with what the file shows. The post hoc label in Finding 1 now gives each of the three readings' number of comparisons (74 project-weeks, one project, twelve cases).
4. The swaps misdescribed (fixed). 0.1 said the swaps were "within otherwise equal cells"; numpy's (3.9 pip to 3.13 uv) and those of pyjwt, pygments and pytest (3.12 CI true to 3.13 CI false) change two fields. System, libc and country are the same on both sides of every swap.
5. A sentence that read as though pydantic 2.14.0 took 19.6 per cent of pydantic-core's downloads (fixed). 2.50.0 did (43,828,209 of 223,263,942, confirmed at the source). 0.1 said 2.14.0's requirement was not read; I read it: pydantic 2.14.0 pins pydantic-core==2.50.0, and 2.14.2 pins 2.50.2. The record now says this fits pydantic's release drawing the new pydantic-core through its pin, and that it was not measured.
6. An absolute in the Answer (fixed). "held on weeks no one had read" became "on two weeks no Lighthouse study had read, for the one library they concern": Lighthouse cannot know what others read, and the four tests are of boto3 only.
7. How sure the Answer sounds (adjusted). "What stays behind held from week to week, as a rule" now opens "Over these three adjacent weeks", and C5's label is given with its interval reaching below the three quarters the label needs (64.9 to 91.9); O's lower bound (75.7) is just above it. The rest of the Answer is at the record's certainty: the walk is stated as an interpretation, holding is not explanation, a cell is not a machine, and the US country is hedged in Limits.
8. A stray file (removed). studies/LH013/ held a committed file named "ritten by gaps.py before the count stages that use it#" with one line of gaps.py, left by a shell slip. Deleted from the working tree; the driving session's commit removes it.
9. Checked and left. Every other figure in the Answer, Findings, Method and Limits matches results.txt or the CSVs. The "P holds" count of 35 follows the brief's convention ("accounts for little" inside "cannot be the main reason"); counting it as its own class would give 33, the difference being pathspec and pytest, both named in Finding 2. Amendment 4's documentation read time (15:31) is two minutes early; it is hashed as a pre-count file and the record discloses the error in Method, which is the right place. The figure is right in both themes: marks at the recorded O, the band at W0 plus and minus 5 points clipped at 100, the five projects that leave the band in bold, labels legible. W0's dot is hidden under W1's square where the two are within about half a point (pydantic-core, aiobotocore and a few others); the caption and the CSV carry the values, so I left it. The record's Limits are honest about the fixed R0 drift, the bands, the walk threshold and what is unknown.

What I could not check

• The cell passes themselves (15.6 billion rows): I checked their internal consistency (sizes sorted, classes summing to the total, totals within 0.0073 per cent of the per-version table) and recomputed everything from their retained rows, but did not rerun a pass; the server-side top-1,001 sizes are taken as returned.
• The PyPI JSON bodies are not retained (57 MB, hashes only); I used data/versions.csv as extracted, and re-read only pydantic 2.14.0 and 2.14.2.
• That analyse.py was written before any of its output was seen, and the order within the second 15:34:51, rest on the agent's account (above).
• The secondary at R1 and R2 and the walk share's per-minor profiles beyond boto3's Python 3.9 were checked against the CSVs, not rebuilt from metadata by a second route for R1 and R2.
• Whether ClickPy will re-ingest W1 or W2 later.

Must-fix remaining

None in the record. Before any public text, the reader-and-inference review comes next (AGENTS.md step 4), and whatever a round writes to resolve it is read once by a fresh agent.

What the record supports for public text

The record supports a "Later evidence" notice on articles/old-versions-new-pythons.md. That piece offers four patterns it noticed only after the counts (boto3's Python 3.9 share of nearly two thirds, Python 3.9 fetching boto3 seven and a half times as often as botocore, 95 in every hundred of those downloads below the last version Python 3.9 can take, and the near-flat counts version after version), says it has "not yet tested" the last, and says "whether they are there every week is for a later reading to test". LH013 fixed four tests of exactly those before reading two new weeks, and all four held in both, with values close to W0's. The notice must keep three limits: it is boto3 alone and two adjacent weeks of the same 37 libraries, a repetition in time, not other libraries or a longer stretch; holding is not explanation, so the installer's-search reading stays a reading the log cannot confirm; and the other libraries' flat shapes the piece mentions were described, not tested (aiobotocore's held; grpcio-status's and litellm's crossed the threshold from week to week), so the notice must not extend "held" to them. It should not import the cell measure, which the piece does not use, beyond what is needed. A suggested wording, at the record's certainty (dated with the release day):

Figures behind it: 65.3 and 65.1 per cent (64.7 in W0); 7.16 and 8.04 against 2.73 and 2.92; 95.2 and 95.5; flatness 0.0007 and 0.0005 (typical change between neighbouring versions under a tenth of one per cent), steps at blocks 6 and 26 in all three weeks. The same round would add a line in investigations/software-updates.md and, under the consistency rule, a matching line in the synthesis's notices and programme.md, at the same certainty; the synthesis's phrase "a reading made after release that no field in the log can confirm" stays true and should stay. The round that puts the notice on a public surface should also say that the installer's version, which only the package index's BigQuery table records, is what could test the reading (the record's Next), and that no brief yet does.