Release review of the correction round on LH012: the piece "Most downloads of old versions come from Pythons a newer version supports" at version 1.1, its short form, the record at version 0.3, the consistency surfaces changed for them, and the LH013 brief before its snapshot

Findings

This is the release gate for the round that restates three findings of LH012 in public without changing a figure: what other libraries' limits could account for is an estimate under the co-fetch assumption; an old Python rules out the newer versions without choosing among the older ones, as boto3's Python 3.9 downloads show; and downloads sharing reported fields are not one machine, owner or population. The reviewer read AGENTS.md, the full diff, both pieces whole, the record at 0.3, the retained analysis tables, the post hoc and driver checks, every changed surface and notice, the LH013 brief against LH012's brief and record, and the reader-review pilot for what the colophons say of it; reran the replay; ran the site's tests and build; recounted every class and figure the reworded sentences rest on from the retained tables (studies/LH012/review/r0017_check.py, r0017_check.txt); and re-read the two pages the LH013 brief cites for its one new field. The diff touches no figure, table, script or SVG, and the replay regenerates every output byte for byte. Every reworded sentence in the piece, the short form and the record says what the tables support, no more and no less, with its assumption beside it. What had to be fixed was one surface the round missed, programme.md's "Later evidence" line under LH011, which still said identified bounds were found "accounting for most in four", and one condition in the LH013 brief whose named check cannot establish it; four wordings were tightened. The verdict is that the piece and its short form can be released at version 1.1 with the record at 0.3, and that the LH013 brief can be snapshotted as it now stands.

What was checked against what

Claim	Checked against	Result
No figure changed	`git diff --stat 89d4aa7 c480bb0`; `sh studies/LH012/replay.sh`	fourteen Markdown files changed, no data, script or SVG; the replay passed unchanged, every table, both figures, post_hoc_reading.txt and driver_checks.txt regenerated byte for byte
Summary: 37 per cent; 32 fewer than half; three most; boto3 and aiobotocore few at the last version; four "could account for", with the assumption; 355, 28 of 32	python.csv (classes, P, edge_share), bounds.csv (classes), week.csv, firstday tables via R-0016	32 cannot (24 plus 8 "little"), 3 most, 2 undetermined; edge shares boto3 6.7, aiobotocore 0.6, numpy 56.7, median 67.5; B most for pydantic-core, fsspec, botocore, s3transfer; unchanged first-day figures
Opening: 88 and 55 million on 23 September; 95 in every hundred below the last boto3 for 3.9; noticed after the counts	post_hoc_reading.txt (54,946,193 of 88,297,788), driver_checks.txt (95.4 per cent below 1.42.97), the record's post hoc section	agree; both labelled post hoc in the piece, the record and the surfaces
The Correction notice's account of version 1.0	`git show 89d4aa7:articles/old-versions-new-pythons.md` and the short form	1.0 said "accounted for most in four" (summary) and "these limits account for most" (body); its opening offered boto3 as "the obvious answer" with the 95 per cent only at the close; its close said "one kind of machine, fetching again and again"; the notice reports each fairly and adds no figure that 1.0 changed
"An old Python rules out the newer versions; it does not choose among the older ones", two thirds at the edge, numpy a little over half, boto3 fewer than one in fourteen, aiobotocore almost none	python.csv edge_share; the record's Findings and Answer	median 67.5; numpy 56.7; boto3 6.7 (under 7.1); aiobotocore 0.6; the record's interpretation says the same and is labelled
Bounds: "on that assumption ... could account for most" of four; pydantic-core's pin where "more than half" sit and pydantic "about as often"; boto3 three, four and seven and a half times; "most downloads of boto3 cannot have brought a download of either"; seven ruled out, 26 undetermined, 16 upper at one	bounds.csv (B, lower_from, lower_fetch_ratio, largest_held_by_current_versions, guard), week.csv totals, post_hoc_reading.txt, driver_checks.txt	53.2 per cent held by pydantic's current versions and 54.3 per cent of 2.46.5; 1.05; 2.94, 3.88, 7.51; at most 34.0 and 25.8 per cent of boto3's 575.8 million downloads could each have brought one of botocore's 195.6 million or s3transfer's 148.3 million; 7 cannot (6 plus boto3 "little"), 26 undetermined, 16 with upper at one, smallest upper 52.6
"For most of the others, fewer than half ... and the limits we read can be neither counted in nor ruled out"	the 30 projects outside P-most and B-most, from both tables	P fewer than half for 28 of 30, B undetermined for 24, both for 22
Limits and the close: same fields, one population or many; nearly two thirds; 95 in every hundred	post_hoc_reading.txt (64.7 per cent of the week from 3.9; 99.4 per cent pip, no CI, Linux, glibc on 23 September only)	agree; the piece claims the installer and system only for the one day, the record's Limits sentence did not (fixed, below)
Colophon and Methods: record 0.3 "of wording only"; 1.0 at 89d4aa7	the record's diff (Answer, three findings, two Limits, Next, Corrections; no table or script) and `git log`	true; 89d4aa7 carries 1.0 and 0.2
Record 0.3: Answer, P and B findings, post hoc interpretation, Limits, Next, Corrections	the tables above and the record's own earlier text	every figure unchanged and in its table; the co-fetch assumption, the ratios, the edge shares and the withdrawal of "one large population" are stated where the classes are; the Corrections entry says what changed and that no class, interval or test did
The short form	its figures against the same tables; its length; read on its own	55 of 88 million, 95 in every hundred, 37 per cent, 32 of 37, four with the assumption, 28 of 32 all agree; 255 words after the title without the Correction notice, 307 with it, 190 after the byline; it names its week and its libraries and needs no other page
Consistency	the piece, the short form, README's "Current focus", investigations/software-updates.md (three passages), programme.md's LH012 answer, its "Later evidence" line under LH011, its checkpoint of 29 September and "Questions after these", AGENTS.md's "Where things stand", the four notices, observations.md, the closeout pointer	all now say: most of the older downloads from excluded Pythons in three and fewer than half in 32, the old Python not saying which older version was fetched; limits could account for most in four under an assumption the log cannot check, strained for two; undetermined in 26; frozen lists fit and cannot be counted; downloads sharing fields are not one machine or population; boto3's case noticed after the counts. programme.md's line under LH011 still carried the 1.0 claim (fixed, below); observations.md describes what was read and states no class
Absolutes in titles and summaries	both titles and summaries	the title's "most" holds for 32 of 37 and pooled, with the summaries carrying the week and the 37 (as R-0016 kept it); no never, always, all or none
Checks	`sh studies/LH012/replay.sh`; `npm test` and `npm run build` in site/	replay passed; 15 tests pass; the build writes 114 files, and the only unresolved links are the expected ones to notes/R-0017.md and R-0018.md, plus two pre-existing in notes/R-0003.md
House rules	grep for non-ASCII in the pieces, record, brief and surfaces; the prose before both colophons; spellings	only the bylines' middle dot and the record's Δ; no document name, study number, commit or role before a colophon ("the record" in the body means the public record, as in 1.0); British spellings
LH013 brief: dates	Python's calendar; LH012's rule	21 to 27 September and 28 September to 4 October and 5 to 11 October are Monday to Sunday; 28 August and 4 September are each week's first day less 31 days, as 21 August was LH012's; ClickPy held 28 September on 29 September, so 12 October is expected from 13 October; 31 October as the blocked date is after both
LH013 brief: definitions said to be LH012's	LH012's brief ("The read week and the reference release", "Sources and events", "The three explanations and their traces", "Missing evidence", the reporting convention) and record	O, "at or newer", "other", P's lower and upper estimates, per-day admission, the classes with "little" inside "cannot", the resampling (10,000 draws, seed 20260929), the gap rule, the 2 per cent table check and the labels match; the W0 figures it discloses (37.3, 20.0 to 99.3, 62.2, 99.4, 64.7, 95.4, 7.51, 2.94) are the record's; the six fields exist as columns of `pypi.pypi` (data/clickpy_columns.csv: date, country_code, project, type, installer, python_minor, system, version, libc, ci, filename)
LH013 brief: eligibility without a count	the named check (first and last day held per table and project, LH012's M03 and M04 queries, which return dates)	the last-day condition is checkable without a count; "every day of W1 and W2 is held" is not established by a first and last day (fixed, below)
LH013 brief: nothing depends on an outcome of its weeks	every threshold, week, field, reference release and test	O within 5 points, P's class unchanged, C within 5 points with the same cell, the three post hoc tests at one half, twice and three quarters, are all fixed now; the writer's expectation is labelled a prior; the secondary reference releases follow from metadata; the W0 totals check reads only days already read
LH013 brief: its one new field	linehaul's parser and PyPI's BigQuery page, re-read at 10:31 UTC	the parser passes a `country_code` field of each log line through unchanged; neither page says which service assigns it; the BigQuery page names the table, says linehaul fills it, and does not mention the field (fixed, below)

Must fix, fixed

programme.md, the "Later evidence" line under LH011's answer. It still said LH012 "found identified bounds accounting for most in four", the version 1.0 claim, on a surface the consistency rule covers. Now: "and where downloads from excluded Pythons were most, in three, the old Python does not say which older version was fetched; identified bounds could account for most in four, under an assumption the log cannot check; frozen lists could not be counted."
studies/LH013/brief.md, the eligibility condition. It requires that every day of W1 and W2 be held for all 37 projects, but named as its check LH012's coverage query, which returns only the first and last day held and cannot show a missing day between them. Now it also names a query listing the days held per project over the two weeks (project and date only, no count), and says that a day not held once 12 October is held is that project's gap day under Missing evidence rather than a reason to wait longer. That last clause is the reviewer's choice; the driving session should confirm it before the snapshot, since AGENTS.md and programme.md say "and every day of its weeks".

Should fix, fixed

Piece, "Libraries holding one another back". "boto3's limits fit the versions of those two that were downloaded" reads as all; the guard gives 75.8 per cent of botocore's older downloads and 89.5 per cent of s3transfer's at versions the held boto3 admits. Now "Most of the older downloads of those two were of versions that boto3's limits allow, but the log cannot say how many of them the limits hold."
Piece, Corrections. "versions older than that Python needs" is not what the check counts; now "older than the last that Python can take".
Record, Limits. "the older share of boto3 is mostly downloads reporting one Python, installer and system" claimed the installer and system for the week, where they were read for 23 September only; now "one Python, and on the one day broken down one installer and system". A sentence in the 0.3 Corrections entry records the change.
studies/LH013/brief.md, resource ceiling. "Expected use is about 20 billion, most of it two passes of pypi.pypi" assumes one pass a week, but C, C5 and their older-only secondary are three groupings; read as separate passes at LH012's 9.4 billion rows each they would reach about 40 billion, over the 30 billion ceiling. The brief now says the passes are combined or the study stops at the ceiling with the unread part stated.
studies/LH013/brief.md, country_code. It said the field is "the country the package index's content network assigns to the requesting address", citing the parser and the BigQuery page; the parser shows only a field passed through from the log line, and the page does not mention it. The brief now says so, labels the content-network attribution as general knowledge and not a source, and notes the review's re-read. Its header now says the reviewer read it before the snapshot and what the edits touch.

Notes, kept

The short form is 255 words after its title without the Correction notice and 307 with it, against "about 150 to 250"; version 1.0 was 261 (R-0016). The notice is the house's required apparatus and the opening paragraph carries the piece's point; kept.
README's "even there the old Python does not say why those particular older versions were fetched" says of all three what the piece shows for two (numpy's excluded downloads sit a little over half at the edge). It is the record's own reading of the class, that P "does not say why they were of the versions they were", so it is the same claim at the same certainty; kept.
The piece's opening still says the downloads were made "on Linux machines that did not say they were build servers". Each download reports a system and a flag, and the sentence claims no population; kept.
The piece's close, "downloads sharing a few reported details can make up most of what the most downloaded library's numbers say": the week's figure is for one field (64.7 per cent reporting Python 3.9), the installer and system for one day. "Can" is a possibility grounded in the one field; kept.
The LH013 brief reports "the number of cells that carry half of the project's downloads" and reads only "the largest few cells a project" within the 10,000-row limit. The count can be made server-side without returning the grouping, but the brief does not say how, or what is reported if the rows read do not reach half. A method detail for the writer to settle before the snapshot, not an outcome-dependent choice; not changed.
The LH013 brief's header names 89d4aa7 as its grounding. When it is snapshotted, the header or the record should name the commit or issue comment that holds the snapshot, as LH012's does.
Both colophons already say version 1.1 was "read first as a reader would, then against the record" (notes/R-0018.md) and was "Released ... after those reviews", and status: released stands in both front matters; the closeout pointer names notes/closeout-2026-09-29-claims-and-review-pilot.md, and releases.md has no line for 1.1. None of these exists or is true yet; they are the driving session's release steps, as the dispatch said.

What the review could not check

That the driving session which wrote version 1.1, record 0.3 and the LH013 brief ran on Opus 5.5 rests on its own statement.
The figure was not re-rendered: the SVG is unchanged and R-0016 rendered it in light and dark.
The LH013 brief's read times of 10:18 UTC for the parser and the BigQuery page rest on the writer's statement; the reviewer's own reads were at 10:31 UTC and found what the brief now says.
Whether ClickPy's demo user can compute C, C5 and the older-only secondary in one pass within its limits was not tested; the brief's ceiling sentence allows for either outcome.
The reader's review and its recheck (notes/reader-review.md) are not this review's and were not run; the pilot's log row for the rehearsal is empty.
No count of any day after 27 September 2026 was read, by design.
The review's own cost: priced by the driving session from the transcript.

Nothing remains that must be fixed before release; the colophons' lines on the reader's review and the release, the line in releases.md and the close-out the pointer names are the driving session's to complete, and item 2's clause and item 12 are the driving session's to confirm before the LH013 brief is snapshotted.