The programme

The questions Lighthouse is asking, what it has found, and what comes next. 25 September 2026, revised 30 September 2026 (last: LH017, whether pinned projects' CI workflows read the pin, under Answered and Next). The records cite this document as LH F04. Sources in square brackets are numbered in sources.md.

The programme follows the order observatories have always followed: catalogue what is visible, calibrate on known objects, explain the mechanism, then measure the dynamics. It is paced by budget and evidence, not by a calendar, and outward work does not wait for local calibration: an outward study validates its own sources within its own boundary and says whose instruments supplied the evidence. The programme is done when someone other than the analyst can reproduce at least one important result from the retained evidence and method; when the records explain a measurement failure or blind spot as clearly as a detection; when at least one outward observation has been compared with its source's coverage limits, and one interpreted through the LH001 calibration or the study says why it could not be; when Lighthouse's own consumption is recorded; and when a synthesis states what the watch would now detect of a self-sustaining propagation pattern and what it would miss. The next programme follows from what these studies teach.

Checkpoint, 22 October 2026. LH019's first prospective repeat found unchanged linux/amd64 manifest digests at all four selected moving PHP tags, while Hub tag-level push metadata changed. An additional post hoc audit of official-images issue #22546 records user-reported missing manifests and a maintainer's deployment-glitch acknowledgement between the publisher PR merge and LH018's successful registry reads; the interval is not a complete availability trace. The first Drupal production-image rule failed because its exact tag did not exist (LH022). An explicitly post hoc alternative, LH023, found a published drupal:10.6-php8.3-fpm amd64 manifest whose config declares fixed PHP 8.3.36, but no resolved-base build log or deployed population. LH013's date-only preflight now meets its eligibility condition for all 37 projects and fixed weeks; its amended CI-flag comparison was committed before outcome counts. The full LH013 measurement remains to be run. LH019's remaining UTC checkpoints are 24 and 28 October.

Public response watch, 22 October 2026. LH024 fixed a purposive panel of ten institutions and three technology outlets before searching its results. Its first snapshot distinguishes upstream notice, agency recommendations, network providers' claims of traffic rules and media coverage. A claimed default WAF deployment, an opt-in virtual patch, advice to take an exposed service offline, a published derivative image and a verified patched runtime are separate observable boundaries. Four institutional entries were unavailable or not found by the bounded reader, which says nothing about whether those organisations acted. The search connector did not retain a complete ranked result log; LH024 discloses that deviation and makes no coverage percentage. Daily observations through 28 October should preserve changes before analysis; LH013's eligible weekly baseline follows that time-sensitive capture.

Derived-image panel, 22 October 2026. LH025 fixed five WordPress, Drupal and Nextcloud moving tags, with Drupal's already-known result disclosed, then read their current linux/amd64 manifests and configs. All five current configs declared fixed PHP source versions at the first observation; their manifest and config bytes replay against OCI digests. This left-censored baseline cannot date a change of pointer or prove a deployment. Daily checkpoints through 28 October can bound later changes for these exact tags, while unchanged endpoints remain only snapshots.

One content link, 22 October 2026. LH026 deliberately selected LH023's Drupal artifact after it was known to declare fixed PHP 8.3.36, then read the exact php:8.3-fpm-trixie base named by its production Dockerfile. All twelve ordered compressed layer digests and uncompressed rootfs diff IDs of that current fixed base form the first twelve of the Drupal artifact's seventeen layers. This is a reproducible content-level link between two published artifacts, stronger than a shared version declaration, but neither a historical resolved-base build log nor a deployment. The selected case cannot give an uptake rate.

Selected operator case, 22 October 2026. LH027 fixed The National Archives' notice after a search snippet had already claimed a precautionary PHP-related outage. Its one bounded direct read returned HTTP 403. The case is inconclusive for the exact service list, current status and timing; neither an outage prevalence estimate nor a service availability check follows. Keep the retained denial and stop rather than completing the account from a search snippet.

Attack and AI-role checkpoint, 22 October 2026. LH028 fixed three first-party sources whose visible outcomes were disclosed before reading. Amazon's web-rendered first-party account says a MadPot honeypot saw an apparent attempt on 17 October, before the 21 October release, and later attempts; its direct endpoint served this collector only a Site Unavailable placeholder, so that source's text lacks raw replay here. Cloudflare's retained article claims attack traffic and default WAF protection without an episode-wide count. OpenAI's retained account identifies AI-assisted defensive discovery and coordination by people and organisations, not AI used by the attackers. A media headline about millions of attempts still lacks an event-specific numerator and window from this bounded primary panel. Follow this fast-moving event at shorter intervals in the early days and prepare a dated, reviewed reader account now, with revisions as evidence changes.

Reader checkpoint, 22 October 2026. A PHP emergency, from an early attack trace to published fixes is the dated, reviewed public account of these bounded records, with a timeline and a map of where the evidence stops. The evidence review corrected the patch and embargo clocks and the attribution of human coordination; an informed reader review and a separate public-first reading found no remaining must-fix claim (notes/R-0029 to R-0031). An intended six-hour revisit of LH028's exact three pages through 24 October is separately scheduled, while LH024 and LH025 keep their daily protocols through 28 October. Future observations require dated revisions, and no first observation is an uptake rate.

Later evidence, 30 October 2026. Read at their sources by the scheduled run (notes/php-leads-2026-10-30/leads.md). Palo Alto Networks' advisory and Unit 42 brief, updated 29 October, report active exploitation of internet-facing PAN-OS management interfaces; the brief puts those "impacted" at about 0.02 per cent of an installed base it does not size, without defining the word. By Dream's account PAN-OS carries PHP 8.0.30 (7.4.33 on one branch), outside PHP's 21 October fixes, so the reported compromise travelled a vendor's own copy of PHP, not the published fixes this account follows. The brief also records, and retracts on 25 October, a 23 October update on "agentic AI post-exploitation activity" in an attack on a European government agency whose initial access it could not tie to these flaws. Unit 42 says it verified the attacker's tooling and confirmed the results reported by Dream Research, which counts 25 servers rooted by the attacker's own build of a PHP exploit chained with CVE-2026-46300, three in what Dream calls a US government-affiliated environment. These are attributed claims whose evidence is not public. A researcher's report (Karimi) records 35 shell starts on three decoys on 24 October, and Delft's dashboard counts sensor traffic. CISA's criteria, read only through a web reader's summary (LH031 amendment 3), count attempts as well as successes, code run on a decoy included, so the 26 October listing may still rest on attempts. CVE-2026-46300's entry, listed 28 October, says it can be chained with the PHP flaws to implant webshells as root. The PHP account carries these in version 1.3, a third later-evidence notice with no correction.

Later evidence, 27 October 2026. LH031's read at 06:34 UTC found CVE-2026-109618 and CVE-2026-109619 in CISA's catalogue of known exploited vulnerabilities, version 2026.10.26, each dated 26 October with a due date of 29 October; CVE-2026-115560 is not listed (studies/LH031/LH031.md, version 0.2). An entry is CISA's classification, by criteria the feed does not state, published without its evidence or a count; the two entries link no exploitation report we could read (their one CISA link, its 21 October alert, refuses our reader), so the listing may rest on the same reports of attempts already described and does not show that any attempt succeeded; an absent entry is not a negative finding. The PHP account carries it in version 1.2, a second later-evidence notice with no correction.

PHP's own notice, 23 October 2026. LH029 fixed a protocol of one read and at most two follow-ups, none needed, in commit a41f896, disclosing what a web reader and Cloudflare's revision had already shown, then retained PHP's news page at 17:00 UTC (record). PHP's entry suggests session.upload_progress.enabled=0 until the next regular bugfix release "to fully protect from an unlikely RCE vector", CVE-2026-115560, which by PHP's account needs an application that switches its session serialise handler from php_binary or php_serialize to php at runtime with upload progress enabled. It names no version; its advice implies the 21 October releases do not close the path, which Cloudflare states outright. The setting is the one PHP listed on 21 October as a partial measure for CVE-2026-109619. Nothing counts the applications that switch handlers. The entry's datetime of 10:12 UTC is a stamp PHP attaches, not proof of first visibility: the 21 October entries carry times hours before the reported release. The 22 October account gained a dated later-evidence notice and change list (version 1.1).

Answered

Each answer says what its record's current Answer says, at the same certainty as the investigation page and the current account, articles/where-software-updates-go.md; the release review checks that they agree. Where later evidence changes how an answer reads, a dated "Later evidence" line follows it, and the answer's own words stand for its own sample.

LH017 Whether a pinned project's CI workflows install what its pin or lockfile names. For the same 469 pairs as LH015, does some job in the repository's GitHub Actions or GitLab CI workflows, at the pair's snapshot, install the library's version from the file that held the pin or lock, and from the lockfile itself, including where the container recipe leaves it unread? Almost always, where the rules could decide, and for lockfiles mostly, with half of that resting on commands that can re-lock. Each of the 332 repositories was cloned anonymously and read at the pair's snapshot, by rules taken from the installers' and services' documentation and fixed in a brief whose hash was posted on issue #19 before any repository was read, with three amendments made after workflows were seen, the third after the evidence review; scripts, Makefile targets, tox, nox and hatch configurations and local actions were read one level down, and the writer judged 271 jobs. A blind check of 40 jobs agreed on 36; the faults it and the evidence review found were corrected, moving four pairs, and the record went to version 0.2, then to 0.3 with two readings made after the counts at the reader review. 395 of the 469 pairs kept CI (84.2 per cent, repository-resampled 95 per cent interval 79.7 to 88.3, "as a rule"; 81.5 per cent by repository). Of the 291 whose CI the rules decided, 282 had some job that installs the library from a timed file (96.9 per cent, 94.4 to 98.9, "as a rule"); 50 were undetermined, 14.7 per cent of that frame. By the kind of pin: exact pin 94 of 95 and both 91 of 92, "as a rule"; lockfile 97 of 104 (93.3 per cent), with its label withheld because 31 of the 135 lockfile pairs in that frame were undetermined (23.0 per cent) and the two bounds read differently. Of the 188 pairs with a timed lockfile whose CI was decided for the lock, 164 had some job that installs from the lockfile itself (87.2 per cent, 80.2 to 93.3, "as a rule"), against 45 of 90 for LH015's container builds among the pairs LH015's pair rule decides, and 71 of 113 (62.8 per cent) counted by this study's rule, where one build is enough; but in 83 of the 164 every such job uses a command that keeps the locked versions only while the project's own constraints admit them (uv run or uv sync without --locked or --frozen, and the like), and counting those as resolving afresh, the brief's sensitivity, gives 81 of 161 (50.3 per cent). Counted by one rule, a reading made after the counts at the reader review: by this study's, the recipes installed from the pin at 164 of 194 pairs (84.5 per cent) against CI's 282 of 291; by LH015's, CI at 231 of 302 (76.5 per cent) against the recipes' 129 of 167 (77.2), so the workflows read the timed lockfile more often under either rule and the pin more often only under this study's. Described, not tested: of the 25 lockfile pairs whose container builds did not read the timed lock, a CI job read it in 20; 51 of the 282 pairs that read the pin also had a job installing the project's requirements without it; in 236 of the 282 a job reading the pin used pip or uv, which send the CI flag, and in 125 every such job restores an installer cache as written, though by setup-uv's own READMEs, read after the counts, 55 of those have a job whose cache at the version named keeps no pre-built wheels and fetches them at each run. A workflow is a recipe for a run, not a record of one: nothing here says which jobs ran, how often or what they fetched, so the study shows that a road runs from a pin to installs the download log's CI flag can mark, not how many older downloads come down it. The record is studies/LH017/ (version 0.3); the piece is articles/tests-read-the-lockfile.md. What it leaves open: whether that road carries a visible share of the older-version downloads, which the log's CI flag on weeks not yet read could describe library by library and only run logs could count; and whether the jobs that could re-lock ever did.

LH016 Which steps of the workflow changed the pieces' claims. In the six research rounds of 28 and 29 September 2026, which steps of the research and review workflow changed what the pieces and records say, what kind of change did each make, at what cost, and what reached release uncaught? An inward study of the repository's own history, each change credited to the step whose commit window held it and coded by a scheme fixed before any change was read. Of 125 changes made while a step ran, 66 changed what a reader of a public surface would believe. The evidence review made 23 of them, mostly figures and how sure a sentence sounded (13); changes to what a claim meant, what a count counts, what caused what or a new reading, came mostly from outside review the keeper relayed after two pieces' release (5 of its 8) and from the reader-and-inference review's second stage (8 of its 17), and all 8 of the relayed review's and 15 of stage 2's altered text an evidence review had passed; that grouping of types was made after the counts. Text written to resolve a review carried problems of its own: 8 of the recheck's 10 public-claim changes corrected text written minutes before in response to a review, six of the eight sentences stage 2's resolution had introduced (a reading made after the counts). Every correction of a released claim in the frames came from relayed review or work the keeper commissioned, directly or in the rounds those readings opened, and three of the twelve pieces released before the reader review existed had their main claims corrected. Replayed on LH011's and LH012's pieces as first released, a fresh reader review found the relayed reading's central point on each (5 of 16 known answers found, 7 in part, 4 missed), with or without its list of prompts, and found two material problems still standing in released pieces, which the driving session confirmed on the retained data: litellm's six late releases all first reached half on 1 May 2026, and none was at half on any later day of the 30 read (issue #21); and a new version's share, counting it and any newer, rose after day 2 in 339 of 355 releases, by a median 7.2 points (issue #22); both were corrected the same night. A second coder, blind to the step, agreed on the tier of 28 of 30 sampled changes (kappa 0.88), on types less often (21 of 29). At list rates the evidence review cost $30.41 over six rounds and the reader review with its recheck $22.47 over three; the relayed review's cost is unknown, since the repository records who relayed it and not who or what produced it, much of it, by the relayed account of Astra, a reviewer outside the workflow, Astra's analysis (studies/LH016/review/relayed-review-astra-2026-09-29.md); and these costs describe the rounds rather than rank the steps. Six rounds are cases, the steps ran in one order, and every coder and reviewer runs on the same family of models as the steps it codes. The record is studies/LH016/ (version 0.2). What it leaves open: how often each review catches a known problem, which one draw per text cannot say; what the pieces that never had a reader review still hold (issue #23); and what the briefs' rules and the literature checks prevent, which leaves no trace in the history.

LH015 Whether a pinned project's own container recipe installs what its pin or lockfile names. For the repositories whose pins or lockfiles LH008, LH009 and LH010 timed, does the container recipe a repository keeps at the moment of a release install the project's Python requirements from the file that held the pin or lock, or from something else? From the pinned file for most of the pairs whose recipes the rules could decide, but no label stands, because more than a quarter of the pairs with a recipe could not be decided. The frame was those studies' 469 distinct repository and event pairs, in 332 repositories and 40 releases of 31 libraries from April 2025 to August 2026, fixed by their own rules; each repository was cloned anonymously and read at the pair's snapshot, the last commit before the release, by rules taken from the installers' documentation and fixed in a brief before any repository was read, with seven amendments made after recipes were seen. 247 of the 469 pairs kept a container recipe (52.7 per cent, repository-resampled 95 per cent interval 45.9 to 59.3, "for some pairs"; 45.3 per cent by repository, "not as a rule"). Of the 167 whose recipes the rules decided, 129 installed the library from the pinned file (77.2 per cent, 68.6 to 84.4); the label that share would carry, "as a rule", was withheld by the brief's rule because 68 of the 247 were undetermined (27.5 per cent), and counting all of them one way or the other gives 54.9 or 83.8 per cent. By the kind of pin, described and not tested: an exact pin alone 63 of 77, a lockfile alone 21 of 37, both 45 of 53, with lockfile pairs also the most often undetermined (41 of 153); among the 90 decided pairs whose timed files included a lockfile, a container build read the lockfile itself in 45; 89 of the 129 pairs from the pinned file never read a timed lock, their pin sitting in the project's manifest, which any install of the project reads, or in a requirements file the build installs (a reading made in the reader-and-inference review, notes/R-0022.md). Of the 38 pairs not from the pinned file, 15 installed from another requirements file, 14 the project's own published package from the Python Package Index, 7 left a timed lockfile in the build unread, the pattern LH006 and LH007 found in images, and 5 took another pin; 12 of the 38 rest only on builds that never name the library, and reading their instructions, a fresh build after the release could have taken the new release for 2, could not for 12 and was not determined for 24. A build from a repository's own recipe would therefore have bypassed the timed pin in at least 38 of the 469 pairs (8.1 per cent) and at most 106 (22.6 per cent). A recipe is not a build: no registry or image was read, recipes for development and for release counted alike, and whether a build installs the library at all was not resolved. A reviewer who classed 60 sampled builds without seeing the writer's classes agreed on 57, all 30 judged builds among them; the classifier's rules behind the three errors were corrected after the check, and one amendment applied as written, which moved nine builds at the snapshots and no label (record version 0.2). The record is studies/LH015/ (version 0.3); the piece is articles/recipes-follow-the-pin.md. What it leaves open: whether the same projects' CI workflows, whose installs the download log's CI flag records, read the lockfile their container recipe leaves unread; which recipe, if any, makes the images a project publishes and people run; what the 13 pairs undetermined only by the rule for a build's starting folder would show; and whether the lockfile pairs' lower share holds once more of them are decided.

LH013 Whether what stays behind holds from week to week. Over the two weeks after LH012's, 28 September to 11 October 2026, do the 37 libraries' older shares and Python exclusion hold, how much of each library's downloads falls in its single largest combination of reported fields, and does the flat profile of boto3's old-Python downloads hold? Over these three adjacent weeks, yes, as a rule, on every measure the brief tests (the largest cells compared across the two new weeks), read on 2 November 2026 under a brief fixed on 29 September (the record, version 0.2, evidence review notes/R-0046-lh013-evidence.md, reader review notes/R-0047-lh013-reader.md). The older share O at LH012's fixed reference held within 5 points for 32 of 37 (project-resampled 95 per cent interval 75.7 to 97.3; median 37.3, 36.6 and 36.7 per cent); the class of Python exclusion for 35 of 37, the two changes being W0's undetermined pandas and urllib3. The largest cell of six reported fields, a median 10.2 and 10.1 per cent of a library's downloads, held for 33 of 37 and, without country, for 29 of 37 (interval 64.9 to 91.9, reaching below the three quarters the label needs); a cell is not a machine, an owner or a population. All four tests of LH012's post hoc boto3 readings held in both weeks (Python 3.9 share 65.3 and 65.1 per cent; ratio to botocore 7.16 and 8.04; 95.2 and 95.5 per cent below 1.42.97; flatness 0.0007 and 0.0005). Holding is not explanation: the resolver's-walk reading stays an interpretation, which the installer's version in the package index's BigQuery table could help test, though not settle alone (notes/R-0047-lh013-reader.md), and no brief yet reads it. A repetition in time on the same projects, not a replication on others.

LH014 Whether the two-day pace holds below the top fifty. Below the fifty most downloaded Python projects, does a new newest version reach half of its project's downloads within two days as a rule, and does its share settle by day 2? Not as a rule in either band, by the brief's convention. From ClickPy's August 2026 ranking [S21], after LH011's fifty and the packaging tools, 80 projects were drawn at random from positions 51 to 500 (band A) and 80 from 501 to 5,000 (band B), by a rule fixed before the ranking was read; 52 and 35 of them released 295 and 196 versions from April to August 2026 that became the newest when uploaded. 25 of band A's 52 had most of their releases reach half of the project's downloads, at that version or newer, on day 1 or day 2 (48.1 per cent, project-resampled 95 per cent interval 34.6 to 61.5, which includes one half), and 9 of band B's 35 (25.7 per cent, 11.4 to 40.0), beside LH011's 26 of 37 (70.3 per cent) as a description, not a test. The median of project median day-1 shares was 48.1 per cent in band A and 22.7 in band B, against 57.6 at the top. LH012's settling test held as a rule in band A (39 of 50, 78.0 per cent, 66.0 to 88.0) and for some projects in band B (23 of 35, 65.7 per cent, 51.4 to 80.0), where the median release that reached half within 30 days took 4 days. Described only: a new release's early pip and uv downloads carried the CI flag less often than the replaced release's, by a median 14.2 points in band A and 7.1 in band B (LH011: 6.6); the mirror tools pypistats names that occur in the log (bandersnatch, Artifactory, devpi) made a median 148 and 62 downloads of a release on its first two days, 0.01 and 0.23 per cent of its own, and leaving them out changed no project's outcome. Rank is not a cause and no reason was measured, and a download is a fetch. Downloads were read only to 27 September 2026, so nothing of LH013's weeks was read. Read after the counts by the reader-and-inference review (post hoc, record version 0.2, about twenty comparisons): for 172 releases that replaced a version at least 14 days old and not folded into the lower-version row, the replaced version's share on the eve of the release had project medians of 61.8, 50.5 and 31.2 per cent at the top and in bands A and B, the new release's day-30 share differed from it by project medians of -0.2, -2.1 and 0.0 points, and of releases whose predecessor held less than half on the eve, 2 of 91 reached half within two days, against 68 of 81 of the rest; so the gradient seems to lie mostly in how much of a project's downloads follow its newest version at all, before any release, which is what stays behind, and less in speed. The record is studies/LH014/; the piece is articles/rarer-further-down.md. What it leaves open: whether the gradient and the inherited share hold on a fresh draw and on later releases, and what the smaller floating share further down is made of.

LH012 What keeps older versions downloaded. After a new release of one of the most downloaded Python libraries, what keeps older versions downloaded, and which explanations can the public record rule out: other libraries' version bounds, Pythons the new release no longer supports, or environments rebuilt from frozen lists? For most projects the record rules out old Pythons as the main reason and cannot rule identified bounds in or out; for three, most older downloads came from Pythons that no newer release supports, and for four, identified bounds could account for most under an assumption the log cannot check; frozen lists cannot be counted in the log. Over 21 to 27 September 2026, for the 37 projects of LH011, with each project's reference release the newest version uploaded by 21 August, a median 37.3 per cent of a project's downloads were of versions numbered below it (20.0 per cent for pyjwt to 99.3 for pydantic-core, whose downloads follow the version pydantic pins; 45.6 per cent pooled). For 32 of the 37 projects (86.5 per cent, project-resampled 95 per cent interval 75.7 to 97.3, "as a rule" by the brief's convention) less than half of those older downloads came from a Python that every newer release excludes, even counting downloads that report no Python as excluded; the median project's share was 12.2 to 18.0 per cent. Downloads from such Pythons were most of the older downloads in boto3 (76.3 to 77.0 per cent), aiobotocore (63.0 to 63.5) and numpy (62.5 to 66.7), the brief's class "accounts for most", and pandas and urllib3 were undetermined; that class counts fetches that could not have been of the reference release or later, not why they were of the versions they were, and most of boto3's and aiobotocore's were of versions below the last one their Python admits, where a fresh install would land. Read after the release (post hoc, record version 0.3), those two projects' older downloads by version are flat for long runs of versions below each Python's edge (boto3 on Python 3.9: 49 of the 50 versions below 1.42.97 had 882,481 to 905,092 downloads each), the profile an installer's resolution walk leaves when it fetches every version it tries; on that reading most of them are versions inspected and discarded, not installations, which none of the three explanations describes. Walk-shaped fetches, so measured, were 17.1 per cent of the 37 projects' older downloads pooled and none for the median project. Bounds declared by the 500 most downloaded projects could account for most in four projects, the brief's class "accounts for most" for an estimate that assumes each fetch of a held dependent version brings one fetch of the project, which the log does not observe: pydantic-core (pydantic's exact pin), fsspec (s3fs), and botocore and s3transfer (boto3's versions below 1.43, fetched 2.94 and 3.88 times as often as they are, so the assumption is strained there); only for pydantic-core do the dependent's current versions carry much of the hold, the rest coming from older s3fs and boto3 versions. They could not be the main reason for seven, among identified bounds, and were undetermined for 26, whose upper estimates saturate on requirements the log cannot resolve: extras, platform markers and versions not read. Frozen lists were described, not counted, as the brief said in advance: 18 of 37 projects showed the trace fixed for them (most older downloads off every version an old Python or an identified bound would pick, and more often flagged CI than newer ones), and uv made a median 59.6 per cent of older downloads against 43.2 per cent of newer ones. The first-day observation, seen only after LH011's counts, held as a rule on 355 releases of November 2025 to March 2026 that no earlier study read: for 28 of 32 projects most releases' at-or-newer share on day 30 was within ten points of day 2 (87.5 per cent, 75.0 to 96.9), and so were 257 of the 355 releases; the band is absolute, and by the brief's secondary ratio boto3's and aiobotocore's small shares still grew by about two thirds after day 2; within the band the share rose from day 2 to day 30 in 339 of the 355 releases and for the median release of 31 of the 32 projects, by 3.2 points for the median project, so to settle is to stay within ten points, not to stop (read after the counts; record version 0.4). Read after the counts, and not tested: on 23 September 2026, 62.2 per cent of boto3's downloads came from Python 3.9, 99.4 per cent of them pip on glibc Linux with no CI flag, and over the week Python 3.9 fetched boto3 7.51 times as often as botocore; whether such downloads come from one population of machines or many, the log cannot say. A download is a fetch; the Python is the one the installer reports; one week was read; only identified bounds were tested. The record is studies/LH012/ (version 0.4), its brief snapshotted on issue #14 before any count; the piece is articles/old-versions-new-pythons.md. What it leaves open: what the older downloads that neither trace accounts for are, which the log cannot count and public lockfiles could, once each; whether what stays behind, and boto3's Python 3.9 downloads, hold on weeks not yet read; and whether bounds hold back the 26 projects the log leaves undetermined.

LH011 How fast a release reaches downloads, and how much of it is builds. When a new version of one of the most downloaded Python projects is released, does it reach half of the project's downloads within two days as a rule, and how much of its early uptake carries the build-server flag, compared with the release it replaces? For some projects, not as a rule, by the brief's convention. Of the 50 projects most downloaded in August 2026 in ClickPy [S21], less setuptools and pip, 37 released 424 versions from April to August 2026 that became the newest when uploaded; 26 of the 37 had most of their releases reach half of the project's downloads, at that version or newer, on day 1 or day 2 (70.3 per cent, project-resampled 95 per cent interval 54.1 to 83.8, which spans the convention's 75 per cent line). The split was sharp: 21 projects had every release reach half, five most, and eleven none (aiobotocore, boto3, litellm, grpcio-status, fsspec, botocore, protobuf, pandas, pytest, numpy, s3transfer), whose median day-1 shares were 2 to 34 per cent and moved little over the month, to 2 to 37 per cent by day 30, litellm's rising most, from 9.5 to 21; no release of ten of them reached half within 30 days, and litellm's six that did all first reached half on one day, 1 May 2026, and were at half on no later day read (record version 0.4). Pooled over releases, 127 of 424 (30.0 per cent) reached half, because boto3, botocore and litellm account for 252 releases and none of theirs did. For one release a project a month (104 releases), the new release's pip and uv downloads on days 0 to 2 carried the CI flag less often than the replaced release's on the same days: medians of project medians 32.2 against 40.7 per cent, every project's median per-release difference below zero, median -6.6 percentage points (interval -11.4 to -5.0), smallest in the three daily releasers. pip's and uv's source shows both send the flag as true when one of four CI variables is set and nothing otherwise, so it is a floor on builds; other installers' 1.7 per cent of downloads were left out. ClickPy's daily totals agreed with pypistats.org [S22] within 1.6 per cent on the 15 days checked. A download is not an installation or a run, ClickPy keeps the day and not the hour, and why older versions keep their downloads was not measured: the record's interpretation, from general knowledge of those packages, is that several of the eleven are held back by their dependents' version bounds, and that Pythons a new release no longer supports and environments rebuilt from frozen lists would fit too; no dependent's requirements, no release's Requires-Python and no download's Python version were read. Described only after the counts were read (record version 0.3): for 34 of the 37 projects the median share on day 30 was within ten points of the median on day 1, though within that band the share rose from day 1 to day 30 in 378 of the 418 releases, by a median 4.1 points (record version 0.4), and a month on from 17.8 to 47.1 per cent of downloads were still at older versions in the 26 projects where new releases took over, and from 63.0 to 97.5 per cent in the eleven. A share of downloads is a share of fetches, weighted towards environments that fetch often, so a low share is not by itself slow uptake. The record is studies/LH011/ (version 0.4); the piece is articles/two-days-for-most.md (version 1.2). What it leaves open: what keeps older versions downloaded, in all 37 projects and most in the eleven, which LH011's retained counts cannot say offline because every version older than a project's first qualifying release is folded into one row a day and no Python version was read; whether a release's share is set on its first full day, which was seen only after the counts were read; whether the two-day pace holds below the top fifty; and what the new release's lower CI share consists of, since the log cannot separate builds holding a version from fresh installs.

Later evidence, 29 September 2026. The first-day observation above, a reading made after the counts, held as a rule on releases LH011 did not read, measured from day 2 to day 30 as the checkpoint asked (LH012): for 28 of 32 projects with a release between November 2025 and March 2026. Of the explanations named above for what keeps older versions downloaded, LH012 ruled out Python exclusion as the main reason for 32 of the 37 projects over one week of September 2026, 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.

LH010 Does the announced fix's pace hold across many libraries. Do pinned dependents move faster before the advisory to fixes whose notes announce a security flaw than to silent ones, when each class has enough libraries that no one or two carry the result? Not settled. With the library as the unit the classes could not be told apart under any reading; pooled from the release to the advisory, the announced class leads under every clock and every restriction tried, but by the brief's clock a library-clustered bootstrap puts the ratio anywhere from 0.52 to 3.96 (record version 0.3, an outcome-aware reanalysis of the retained evidence). LH008's rule widened to GitHub-reviewed advisories of every severity in OSV [S26] published 27 March to 27 August 2026 against the 500 projects most downloaded in August 2026 in ClickPy [S21] gave 215 qualifying records against 43 libraries, one event each: 22 announced and 21 silent by LH009's rule, fixed before any note was read, not the 20 libraries a class with pinned dependents the design asked for. Open Source Insights [S11] listed few or no dependents for the release before 13 of the fixes, so 18 announced and 12 silent libraries gave 209 repository and event pairs from 150 repositories, and 142 moved by 27 September. Pooled, from release to advisory, announced fixes drew 2.30 moves per 100 waiting repository-days (35 moves) against 1.57 (20), about 1.5 times, 2.04 to 3.73 and 1.41 to 1.95 leaving out any one library; in days two to seven, 3.34 (11) against 2.29 (5). With the library as the unit, the median library rate from release to advisory was 3.21 for announced libraries and 2.74 for silent ones, and a permutation of class labels over the 30 libraries gives p = 0.89; in days two to seven the median announced library had no move (nine of 16) against 1.46 for eight silent libraries, p = 0.68. 36 per cent of moves to announced fixes and 43 per cent to silent ones came before the advisory. The fastest libraries in each class are small frames with few repository-days, and nltk alone holds 691 of the announced class's 1,522 repository-days before the advisory. Sensitivities: security words only (strict class), 3.71 against 0.76 (p = 0.28); security words about an earlier release (idna, aiohttp) counted silent, 3.17 against 4.18 (p = 0.78), and the pooled lead in days two to seven, which rests on aiohttp's three moves, turns to 2.61 against 3.30. Within the four libraries with followed dependents on both sides, the announced fix drew moves faster in three and slower in one (pip), on 0 to 4 moves a side. Three fixes (nltk, tornado, pip) had been named by an earlier reviewed advisory outside the rule's window or before the fix; with the earliest GitHub-reviewed record in the retained OSV records as the clock, the medians are 3.26 against 1.30 (p = 0.47) and the pooled rates 3.42 against 1.42 (ratio 2.42, interval 1.00 to 4.90), and with those records' NVD times, earlier for 17 events, the pooled ratio is 3.53 (1.44 to 6.86) while the medians still do not separate (p = 0.47). Nine silent events (four with pairs: litellm, mcp, pydantic-ai-slim, fastmcp) had no notes readable at release in any source read; setting them aside leaves the medians unseparated (3.21 against 2.47, p = 0.87) and the pooled rates 2.30 against 1.41. These readings were chosen after the outcomes were known: of 36 overlapping comparisons two p values and seven intervals exclude no difference, all under readings chosen after the fact, and none is claimed. The test has little power, and GitHub's release pages were not requested. The record is studies/LH010/; the piece is articles/the-lead-was-a-few-libraries.md. What it leaves open: whether a longer window of advisories, or a frame that does not depend on the release before the fix having listed dependents, would give enough libraries to see a modest difference; what GitHub's release pages say of the nine silent events without readable notes; which public notice should count as the advisory, fixed before outcomes are read; and whether the people who moved in the week after an announced release had read its notes.

LH009 Does an announced fix move pins before its advisory. When a fixed release says in its own notes that it fixes a security flaw, do pinned dependents move to it before the advisory more than to a fix released silently? Faster, but not in a larger share, and not separably from the library. Of the 37 fixed releases behind LH008's 68 advisories, read by a rule fixed before any note was read (the changelog at the tag, the tag's annotation and the PyPI description), 19 said at the release that they fixed a security flaw and 18 did not; none was announced late, and eleven of the 19 named GHSA identifiers 1.2 to 25 days before GitHub published them. GitHub's release pages were refused, so litellm's, mcp's and langchain's fixes are silent only in the sources read. Taking LH008's one event per library, eight of each class, seven of each with pinned dependents from Open Source Insights [S11], 257 repository and event pairs from 204 repositories held an affected version at the release and 173 moved by 27 September. The share of moves before the advisory was alike, 29 of 105 for announced fixes and 17 of 68 for silent ones, but the announced fixes' advisories came sooner (median 3.9 days against 10.6); between release and advisory the announced fixes drew 2.36 moves per 100 waiting repository-days against 1.36 (1.84 to 2.84 and 1.13 to 1.68 leaving out any one library). The classes ran alike in the first two days after the release (3.77 on 11 moves, 3.99 on 8), much of it bots'; the difference was in days two to seven (3.22 on 13 against 1.45 on 5), when people made 9 of the 13 announced moves. One of the 46 commit messages before an advisory has a security word. With one fix per library, gitpython and pyjwt carry much of the lead and class cannot be told from library. The record is studies/LH009/; the piece is articles/fixes-that-said-so.md. What it leaves open: whether the pace holds across many libraries of each class, so that none carries it; whether the people who moved in that week had read the notes, which their pull requests would say; and what GitHub's release pages say of the three unread libraries.

Later evidence, 27 September 2026. Across thirty libraries, one fix each (LH010, version 0.3), the question is not settled: library by library the classes could not be told apart, and by the brief's clock the pooled lead's interval spans no difference. "Faster" above holds for these fourteen libraries only. "Before the advisory" here means before OSV's publication of GitHub's reviewed advisory: pyjwt, one of the two libraries carrying the lead, had a reviewed record naming its fix with an NVD time 18 days earlier (LH010's data/reanalysis/clocks.csv), and LH010 found that which notice counts as the advisory moves this comparison more than any other choice tried.

LH008 Do pins move on releases or on advisories. When software built on a widely used library pins or locks it, what moves the pin to a security fix: the release, or the advisory published later? Both, and neither draws most of the moves. The libraries were fixed by a rule before any dependent was read: the four most downloaded in ClickPy's top 200 for August 2026 [S21] with a high or critical GitHub advisory in OSV [S26] published 27 March to 27 August 2026, urllib3, cryptography, pyjwt and starlette. In all 68 qualifying advisory records against 16 of those projects, the fixed release was on PyPI a day or more before the advisory. From Open Source Insights' dependents of the release before each fix [S11], screened in hash order, 102 repository and library pairs from 88 repositories pinned or locked a version below the fix when it was released. By 27 September 73 had moved to it, a median 18.7 days after the release, 28 had not and one had stopped pinning; 19 of the 73 moved before the advisory, 13 of 30 for the two libraries whose advisories came three weeks after their fixes. Moves ran at 4.1 per 100 waiting repository-days in the two days after the release and at 5.1 and 4.3 in the first week after the advisory, against 1.3 to 1.7 at other times: two short spells of about the same pace, on eight moves each, and no burst like mcp's in LH007 (4 of 102 moved within a day of the advisory). An earlier release of each library that no advisory named moved 23 per cent of 91 pairs within 30 days, against 49 per cent for the fixes, partly because many of those repositories were dormant. 22 of the 73 moves were bot commits and 16 a person merging a bot's branch; no bot message in the two days after an advisory calls itself a security update. Three of the four advisories were published within 48 minutes on 15 June, among ten against the three libraries that evening. Authorship and times are read from git alone, since GitHub's API was refused and neither pull requests nor release notes were read; a move is a request, not an installation, and no project's exposure was checked. The record is studies/LH008/; the piece is articles/pins-move-over-weeks.md. What it leaves open: how much of a fix's uptake before its advisory comes because the release itself announces a security fix; which of the bots' moves were security updates, which their pull requests would say; and whether the pattern holds beyond four libraries and one evening.

Later evidence, 27 September 2026. "Before the advisory" here is before OSV's publication of the GitHub-reviewed advisory; pyjwt's flaw had an NVD time 18 days earlier (the record's Limits; LH010's data/reanalysis/clocks.csv), and LH010 found that the choice of clock moves comparisons before the advisory more than any other choice it tried. The first question left open, whether the release's own announcement draws moves before the advisory, was taken up by LH009 and LH010 and is not settled.

LH007 How much of the installed population moves with the resolver. When a widely used library releases, how much of the software built on it installs the new version because an installer resolved an open range, and how much waits for a pin? In a sample of the published images of mcp 1.28.0's direct dependents (16 June 2026), fixed by a hash-order rule before any image was read, the two paces are distinct. Of 199 dependents Open Source Insights listed for 1.27.2, 1.28.0 and 1.28.1, 120 were screened, 22 name an image of their own, and 13 image repositories gave an installed version in 49 images, read anonymously from ghcr.io [S25], Docker Hub [S24] and public.ecr.aws [S27]. Open-range images took the new release within days, 5 of 6 built in the four weeks after it, the first 2.6 days after, at the pace of the download log [S21], where 1.28.x was 43 to 62 per cent of each day's downloads; 10 of the 20 open-range images held a newer mcp than a lockfile their own repository keeps and the image does not use, as agentcrew's did in LH006. Every one of the 29 lockfile and exact-pin images held exactly what its lock or pin named, and 9 of the 12 such repositories had no pin on 1.28.x within four weeks. Of 13 projects whose first 1.28.x pin was found, six made it 0.9 to 27.6 hours after three high-severity advisories against mcp were published within 18 minutes on 16 July [S26], a month after the release; four of those six were changes Dependabot wrote. The link to the advisories is timing and commit messages, and no project's exposure was checked. The sample is small and clustered, most of its Docker Hub images went unread when the byte ceiling was spent, and an image is an installation, not a run. The record is studies/LH007/; the piece is articles/what-moves-a-pin.md. What it leaves open: whether pinned dependents in general move on advisories rather than on releases; how often a project's image ignores its own lockfile; and what the unread Docker Hub images hold.

Later evidence, 27 September 2026. Across four other libraries (LH008), pinned dependents moved to security fixes over weeks, after both the release and the advisory, with no burst like this one (4 of 102 moved within a day of the advisory), so the advisory reading here is one library on one evening. The first question left open above was answered there: neither the release nor the advisory draws most of the moves.

LH006 What a public container image shows of installation. Is there a public record of what was installed, past the download? Yes, for software published as a container image, and only as far as the installation. The installer's own record inside an image's layers, a site-packages/mcp-<version>.dist-info directory, gives the installed version, and the image's configuration its build time; both were read anonymously from Docker Hub [S24] and GitHub's container registry [S25] by streaming the upper layers, 25 to 211 MB per image, without pulling any image whole. The population is thin: of 37 packages (LH002's ten projects and the 34 direct dependents of mcp 1.27.0), 7 name a published image and 6 could be read, giving the installed mcp in 37 images. What an image installs follows how it is built, not the project's pin alone: agentcrew's repository locked 1.26.0 until 24 April, and LH002 counted it as not moving, but its images held 1.27.0 from 8 April, 5.5 days after the release, because its Dockerfile resolves an open range and ignores the lockfile. Images built from an exact pin or a lockfile moved only with it: serena 2.9 days after its pin and mcp-snowflake-server 11 minutes after; keboola's moved on 17 April in a build of the package version whose PyPI release, three days later, was the first to require 1.27.0; octobot's still held 1.26.0 at the end of July. The same tag can name different installations over time, and neither registry lists what a tag named before; an earlier build survives only while another tag names it, as nine of agentcrew's version tags show. An image is an installation made to be run, not a run, and a pull count counts requests. Docker Hub's anonymous allowance, 100 pulls an hour through an address shared with other traffic, bounded the reading to 30 counted pulls. The record is studies/LH006/; the piece is articles/what-an-image-holds.md. What it leaves open: how much of a release's installed population moves with the resolver rather than with a maintainer's pin, across a release's dependents; what moving tags named over time, which only watching them would record; and whether any public source records runs of published software at all.

LH005 Connecting a release to installation. Can any public record connect a software release to its installation? Partly, and only as far as the download. The Python Package Index's download log [S20], read through ClickHouse's public copy of it [S21] and checked against pypistats.org [S22] and pepy.tech [S23], connects a release to the files fetched by version, day, installer and a build-server flag the client reports. mcp 1.27.0 was 22 per cent of the library's downloads in the nine hours left of its release day and 48 per cent the next day, and stayed between 45 and 71 per cent to the end of LH002's window: about half of every day's downloads for five days before the first dependent LH002 watched pinned it. uv made 79 per cent of the window's downloads. The new version was taken far less through Poetry and Bazel, and carried the build-server flag on 11 per cent of its downloads against 49 per cent of the previous version's, which fits installers resolving open ranges at install time rather than dependents' decisions. The log reaches the download and stops: it is not an installation, never a run, and aggregate and anonymous, so the second hop LH002 found, 35,024 downloads of the pinning dependent's releases, cannot be told apart among 109 million downloads of the release on the same days. The copies agree to about one per cent in the window; pypistats's "without mirrors" also drops downloads that name no installer, and one of ClickPy's tables keeps an arbitrary file type. The record is studies/LH005/; the piece is articles/what-a-download-shows.md. What it leaves open: whether any public record reaches what was installed, past the download; and whether a release reaching half of downloads within two days is the rule for widely used libraries, and how much of it is builds.

LH003 Survey of surveys. Who already observes the computational world, which layer does each observatory see, and where does its coverage end? Thirty-four candidate observatories were considered and seventeen have a row. Each sees one layer from one narrow population: event archives and dependency resolvers see residue, broker rankings and vendor usage reports see activity, and vulnerability databases see disclosed flaws rather than their exploitation. None observes propagation directly, and none states how its population overlaps another's, so their counts cannot be added into a total. No source read can tell a person's action from an agent's. The record is studies/LH003/, with every source's row in studies/LH003/sources.md; the piece is articles/what-we-can-see.md. What it leaves open: how much the seventeen populations overlap, which only a joint sample can say; and which of the seventeen Lighthouse could read as instruments of its own, which each study that uses one settles for that one, recording its unit, population and access conditions.

LH004 A historical propagation case. What would the three layers have shown during a documented propagation event, and which layer carried the first detectable signal? The xz backdoor of 2024. The malicious code was public in release tarballs from 24 February, and nobody detected it there. Both signals that were noticed were activity: a memory checker's errors in Red Hat's distributions from 4 March, which the attacker answered with a fix, and one engineer's slow logins on 29 March. The first fitted no surface in the design, which gained a Correctness surface as a result. None of the seventeen sources LH003 surveyed, and no instrument Lighthouse has proposed, watches the distribution package pipelines the compromise travelled through. The record is studies/LH004/; the piece is articles/the-xz-backdoor.md. What it leaves open: what an undetected case of the same kind would lack, which one detected case cannot say.

LH002 A bounded public software neighbourhood. What can public activity reveal about change and dependency in a small software neighbourhood, and where does it fail to reveal running activity? Ten repositories around the Model Context Protocol Python SDK, over twenty-eight days in March and April 2026 fixed before collection by the SDK's 1.27.0 release. Four of the nine dependents came to hold the new release within the window, and in one case the change went a step further, a dependent pinning it and publishing its own release 22 minutes later. Every move fits ordinary maintenance, none was made by an identified bot, and the records tie a move to the release only by the version string and the order in time, which shows what came first and not what prompted it. No source read, git, the registry, Open Source Insights, Software Heritage or one hour of GH Archive, says what anyone installed or ran. Git and GH Archive disagree in both directions for the one hour compared, and a full window of GH Archive would be about 24 GB. The record is studies/LH002/, with the executed design in its brief; the piece is articles/where-a-software-update-went.md. What it leaves open: whether any public record connects a release to installation; how long exact-pin dependents take to move, across all of a release's dependents rather than a cohort selected on uptake; and how complete GH Archive is for a small cohort over a whole window.

LH000 One dispatch end to end. A first look at what Harbour records about one of Lighthouse's own tasks and what the host shows while it runs. Harbour's record is of what was asked and what the agent claimed, not of what happened on the host, and the host was close to idle. The record is studies/LH000/.

Next

Checkpoint, 9 November 2026: the registry worms, dated (LH041 0.3)

LH041 tried to date thirteen named waves of the token-stealing registry worms from OSV's malicious-package records and npm's publish times, under a brief fixed before any record was read. Record 0.3, reviewed by an evidence review and a reader-and-inference review, not released: seven waves are found by the vendors' indicators and two by date, one of them (Miasma) only post hoc; nine have registry times, one of them (July's AsyncAPI wave) only from a record that doesn't identify the wave, and four have none, PyPI's Hades among them, since every malicious PyPI release read is gone. In a view chosen after the counts (two decisions, each a single alternative to the brief's rule), Shai-Hulud 2.0's and ChainDrop's malicious versions went up within hours under 88 and 13 groups of packages sharing a current maintainer. A group isn't to be read as a victim, an account or a step of the worm, and 14 and 2 of those groups began within a minute of the group before them (post hoc, two thresholds). Each count is at most how many of the groups in OSV's records were reached without a person's new act, and OSV's records are incomplete. In the AntV wave 316 of its 359 npm packages are one maintainer group, and two smaller groups followed, one nearly a week later. Three options were weighed: continue with read 2 in December; repair the join for the waves OSV's text does not name (April's two and July's) with the vendors' package lists; or an outward question, dated counts of the worms' public exfiltration repositories, in aggregate and naming no account. The reader-and-inference review found that read 2 as written can't tell a chain of worm infections from one publishing run or one operator's pool of stolen tokens, so amendment 2 to the brief (9 November, post hoc) adds the repair, the timing of groups that began together and whether the group counts hold under two other groupings; all three run on the same waves, so none is a test on unseen data, and they can only lower the ceiling on how many groups were separate steps. Read 2 stays cheap and goes ahead with them. The outward question goes to proposals.md, with account names discarded at collection. No literature search was run beyond the brief's nineteen sources, because the amendment brings in no explanation from outside the record.

The keeper's review, 8 November 2026: gaps covered, and one result reproduced

At the review the keeper gave this session a spend allowance to cover gaps, counted as started by the keeper, and drew a line: Lighthouse does not try to re-identify what a source has anonymised (proposals.md, From the keeper). Under it all four questions of the third investigation started, each with a brief fixed before outcomes were read, and everything they found is unreviewed: the closing web (LH044, P-0013) read its baseline, walls at 13 of 67 readable named services and robots.txt keeping it from 32 of 161, none dated yet; exposed AI services (LH042, record 0.1) found published counts plentiful and rarely comparable; the registry worms (LH041, record 0.1, two readings made after the counts and labelled) dated nine of thirteen named waves, and repairing its join with the vendors' package lists goes before read 2 if the reviews agree, with a dated count of the worms' exfiltration repositories left to proposals.md; agents in public (LH043) closed at 0.1 before any search, because every account anonymises what the agents touched. LH045 keeps two records that overwrite themselves, Epoch AI's data-centre estimates and an IETF draft census around IETF 127; compute prices were dropped on their sources' terms, and asking a publisher's consent waits for the keeper (P-0021). LH046, a repair (record 0.1), read 452 of GH Archive's hourly files: all were present, but pushes, new branches and deletions were absent from 26 of 176 sampled hours from 1 September to 14 October and 64 of 96 from 15 October, while from January to August the other types thinned; the cause is unknown, and notices on the two released pieces that lean on the archive wait for its reviews. The site gained a This week block and plainer reader pages (P-0018, P-0019 in part). Late that evening the keeper decided that Lighthouse obeys robots.txt as its own agent and as whatever runs it: the closing web applies the rule from read 1 through scripts/robots_rules.py (LH044, Amendment 5; eight baseline probes would not have been sent under it), and row robots-sweep-1 brings the other collectors under scripts/robots_gate.py, since most checked no robots.txt (notes/robots-tokens-2026-11-08.md). LH047, the rules of the road, started by the keeper (P-0022), catalogues what sites ask of automated readers and audited Lighthouse's own requests of 8 November: by its derived count (record 0.3, after an evidence review and a reader-and-inference review) 113 of 3,497 requests broke a rule as its brief fixed it, and 59 more, one reviewer's under a User-Agent naming no one, were classed as breaches only after they were seen (post hoc, one choice), for 172; 90 of the 172 got HTTP 404, and most came from a collector that read no robots.txt and that reviewer; next comes a simple paper. An outward question it raises: how many sites that disallow an AI company's training crawler also disallow its user-triggered fetcher (L-0045).

The programme's first condition for being done is met for one result: a fresh agent on a different model (Fable 5.1), which hadn't read LH011's record, tables, script bodies or pieces, recomputed the pace result from the retained data and the brief alone, and every figure came out the same, from 26 of 37 projects to the 54.1 to 83.8 per cent interval (the note). The CI-flag half of LH011, LH013, LH033 and LH034 haven't had that exercise. The last condition, a synthesis of what the watch would detect and miss, has a draft in review: the essay What the watch would see, with its claims check and reader review done and a recheck to come.

Opened, 8 November 2026: what AI activity costs the shared internet

The keeper agreed on 7 November to open a third investigation (proposals.md P-0014), and the scheduled run of 8 November wrote its page. It asks the charter's question directly: what AI activity costs shared infrastructure, as operators report and public traces show, and whether any of it sustains or spreads itself outside a lab. The page keeps five strands apart, as the gate asked: load, exposure, spread run by people, capability in a lab, and activity on the open internet, the last being the charter's own question and the one with least evidence. Its questions, each to become a study under the throttle: the closing web (P-0013, agreed, first), published counts of exposed AI services, a dated timeline of the registry worms, and whether GH Archive shows the evaluation agents' July actions. No literature search was run for the page: it fixes no brief and tests no explanation; each brief will read its own primary sources first.

Decision, 7 November 2026: proposals, a horizon sweep and a throttle

The keeper asked for Lighthouse to widen and deepen what it watches without a person acting as its clock, while keeping a person able to steer. Ideas that are not yet promises now live in proposals.md, ranked; a horizon sweep twice a week (its plan, rows horizon-<date>) adds them from the news and from Lighthouse's own open threads; a fresh agent gates each into started, waiting for the keeper or backlog; and a throttle set by the keeper bounds what starts unreviewed (three active investigations at most, two new studies a week, urgent watches of 14 days unless extended). The keeper reviews the list when they choose and adds directions of their own; nothing waits on that review. The candidates listed under "Questions after these" and the open question issues were copied into proposals.md as its first backlog, not yet gated.

Checkpoint, 7 November 2026: the map of instruments (LH035) released

The map page, Every layer of the internet had a public watcher in November 2026, by what we found, but none saw the whole of its layer, was released after its three readings (notes/R-0049 to R-0051). The reader review changed what it claims: the gaps are partly where an instrument stands, partly what it counts and partly who may read it, so the vantage grouping stays a labelled reading, and that review judged the record's proposed test (Next, item 4) unable to separate the explanations, since the blind-spot column was written by the reading's own author. Three options: continue the map by widening its thin layers (names and IPv6, the record's Next items 2 and 3); repair row I30 by a read of CISA's catalogue that needs no disguised client; or take an outward question. The map can wait: the proposals lane (proposals.md) holds outward questions already started, P-0017 (WordPress's fix, LH039, whose first finding before any brief is that WordPress.org's statistics count branches, not releases) and P-0015, and they go first; the thin-layer widening goes to proposals.md for the horizon sweep to rank.

Checkpoint, 6 November 2026: the map of instruments (LH035) goes to review

LH035, at version 0.3, re-read rows I01 to I40 raw: 62 pages fetched with curl and kept, 214 of 228 quotations found verbatim, and the unquoted fields checked against the raw text. Eleven fields in ten rows were corrected, and five live values in four rows given both readings (the largest corrections: CAIDA's AS relationships dataset lists no sibling links, and one quotation from CAIDA's telescope page was the reading tool's paraphrase); none touched the Answer. CISA's catalogue page refused the research client, so row I30 alone still rests on an extract. With the measurement repaired, the map page the brief mentions goes ahead from figure.svg through the full review sequence (row LH035-map-page), ahead of a new outward question, because the survey is otherwise finished and unpublished. The blind-spot grouping stays a reading (the record's Next, item 4).

Checkpoint, 5 November 2026: the map of instruments (LH035) waits for raw reads

LH035, at version 0.2, settled eleven of its twelve candidates without a row by raw reads of their own pages: eight are now rows (48 in all), three remain undetermined (USC/ISI's datasets, ICANN's zone file service, Shodan) and Internet Atlas still did not resolve. The answer held: every layer has at least one public instrument by what was found, certificates is now the thinnest, and 11 of the 48 rows draw on another included instrument. Three options were weighed for what follows. A reviewed map page now would publish 40 rows that rest on a reading tool's model-written extracts, of which only four were checked against raw pages; another outward question would leave that weakness standing under a record the site already lists. Repairing the measurement was chosen: re-read rows I01 to I40 raw, as the eight new rows were, correcting any extract the raw page does not bear out, before a map page and its full review sequence (row LH035-raw-reread). The blind-spot grouping stays a reading until a study classes the instruments' vantage blind to it (the record's Next, item 4); no brief exists for that yet.

Brief, 4 November 2026: the disclosure timeline (LH038)

Question 2 of When a model finds the bug now has its brief (LH038): a dated timeline of CVE-2026-98432 from public primary sources, each event on its source's own clock, with the elapsed days set beside the intervals six published policies state, read and kept before the brief was fixed (Anthropic's, the kernel security team's, the kernel CVE team's, the linux-distros list's, Ubuntu's and Debian's). Two readings of the policies, made from their texts and not from any outcome, shaped the design: Anthropic's policy page dates its 45-day buffer from a patch being available while the post words it as 45 days after 90, so the record computes against each clock and picks neither; and the kernel's page says a bug found with AI assistance must be treated as public, which is the current text, so the brief reads the file's history to learn whether it applied in September. No literature search was run: the study tests no explanation, and its comparators are the policies themselves. One read from 17 November, after LH036's interim read supplies the advisory lists; the record by 30 November; one revision after LH036 stops.

Checkpoint, 1 November 2026, afternoon: vendors that ship PHP (LH037)

R-0044 found that the compromise reported through Palo Alto Networks' firewalls ran on a vendor's own copy of PHP, a road the PHP account's fixed panels do not follow. Against waiting for PHP's next release (which answers a question about the third flaw) and widening LH031 (whose unit is a catalogue entry), a panel of vendors was taken because it measures that road directly and every vendor statement is public now. To avoid choosing vendors for having spoken, the panel is the 20 vendors with most entries in CISA's catalogue from 2023 to the day before the releases, a rule committed alone before it was run; the four vendors a source had named are read as a separate stratum. At the baseline (1 November, 14:20 UTC), 5 of the 20 had a statement their own channels reached, none states which PHP branch its products carry, and seven vendors were unavailable at the baseline, six of whose routes may be replaced once before the next read (brief, checkpoint). No literature search was run: the brief tests no explanation. LH013 remains the standing baseline.

Checkpoint, 1 November 2026: when a model finds the bug (LH036)

The keeper asked about CVE-2026-98432, a remotely reachable use-after-free in the Linux kernel's IPv4 connection handling, fixed and published on 15 October and scored 9.8 by the kernel's CVE team, for which Anthropic described on 27 October an exploit its internal model wrote. Read on 1 November, EPSS gave it 0.46 per cent for 31 October, CISA's catalogue did not list it, and distributions' fixes ranged from shipped (Debian's security suites) to pending or absent (Ubuntu). Three options were weighed: leaving it to the news, which would keep nothing; folding it into an existing panel, which would lose the disclosure question; and a new investigation with one flaw at its core, taken because it joins two things Lighthouse is for, AI activity on the shared internet and how a fix travels, and because every signal involved answers anonymous reads and EPSS keeps daily history, so the start is not lost. The keeper widened it from a score watch to the responsible-disclosure questions around it and chose model disclosure over a second provider's reviewer (the investigation). The core watch, LH036, was fixed before any EPSS history was read, with the morning's reads disclosed in its brief; the disclosure timeline and the scoring of the post's five chains wait as rows for their own briefs. No primary literature search was run before the brief: its measures read each source as it dates itself and test no explanation; the timeline brief will read the disclosure policies it compares.

Checkpoint, 27 October 2026, evening: an essay strand and a map of the terrain

Talking through the PHP, Node.js and Python comparisons, the keeper and the driving session saw that the instruments themselves tell part of the story: PHP can be seen only from outside, as standing servers that announce their version, while Node.js and Python are seen from inside, as fetches by systems that rebuild constantly, and each instrument's blind spot sits on the opposite side (the download log cannot see neglect; the scanner cannot see care). The keeper asked for this to become Lighthouse's first essay, keeping editorial and theoretical writing visibly apart from reviewed findings, as the charter's promise of essays and this file's rule on speculative essays allow; AGENTS.md (Writing) now sets an essay's form and checks. The first, essays/seen-from-outside-seen-from-inside.md, is drafted and is to be released with the reviewed week-one piece on LH033 and LH034, from whose figures it will take its numbers; its testable readings are named in its last section and point at LH033's and LH034's day-30 reads. Beside it, a standing aim: a map of the internet as the terrain AI systems work in, built by setting partial instruments side by side with their edges stated, growing from LH003's survey, the windows piece and observations.md, and from the research others have already published (internet-wide scans, certificate logs, routing data, web crawls, technology surveys). The front page is being redrawn around four doors (the watch, findings, essays, the map), on a branch for the keeper's approval. LH013 remains the standing baseline.

Checkpoint, 27 October 2026: a Node.js fix on the same day (LH034)

The keeper suggested that a recent Node.js security release might be a third point beside the PHP and Python studies. A bounded check (the project's advisory, dist/index.json, the /dist/ listings, the npm and PyPI package metadata, and the metrics page, all read 27 October without any count) found that the Node.js project released fixes for lines 22, 24 and 26 on 21 October, LH033's day 0, and that nodejs.org publishes daily download counts by exact version: the same unit as LH011, from first-party logs, which LH033's third-party service counts are not. PyPI's Node.js wheel packages have not published the fixed versions and the npm node package keeps only a rolling week, so neither is used. Against continuing LH033 alone or repairing a measurement, LH034 is worth asking because it is the first case where two ecosystems can be set side by side in one unit, and because the July 2026 Node.js security release gives an ordinary release on the same instrument, named in the brief by rule. Brief fixed before any count (studies/LH034/brief.md); baseline read 27 October 18:11 UTC. LH013 remains the standing baseline.

Checkpoint, 25 October 2026: the PHP fix beside the Python findings (LH033)

The keeper asked whether the PHP emergency, a loud version of the update question this programme has followed through Python, should now be compared with it, using projects that already track PHP's uptake as sources until Lighthouse can collect such data. Three options were weighed: continuing the PHP notice panels alone, which say where advice travels but not where the fix lands; repairing a measurement, such as LH021's consumer CI chain, which still lacks a run boundary and denominator; and the comparison, taken as LH033 because a third-party instrument now gives a daily, patch-level view of running services, the far end of the road the Python work never reached. A discovery subagent read trackers' methods only, without their PHP figures (studies/LH033/discovery.md, with searches and unopened results listed). The brief, fixed before any outcome was read, uses Censys ARC's PHP2Shell counts as primary, W3Techs and Packagist as secondary, and names the Python comparators in advance; it describes shapes in different units and claims no cause. First read 25 October 08:55 UTC (checkpoint in the study). LH013 remains the standing baseline.

Checkpoint, 23 October 2026: independently repair LH032's history clock

A separate model reviewed the pinned first read without collecting a second daily snapshot. The 751-entry status totals match the source fragments, compiled SPDX and individual generated rows. First-parent history corrects 117 first-resolution clocks and removes the apparent pre-release Not vuln record; escaped-pipe parsing corrects URL coverage from 737 to 749. The corrected baseline, regression fixture, independent replay and incomplete late advisory sample are retained in LH032. Its list includes runtime components and tools as well as hosted products, and mainline commit times do not establish public availability. Continuing collection remains with the existing daily agent; this round selects repairing the measurement because its clocks will underpin later comparisons. The next separate contribution is comparing the documented defensive AI accounts, using retained first-party sources and attributing each claim. No deployment or causal AI-effect measure is earned here.

Checkpoint, 23 October 2026, evening: the PHP reader loop repaired, and LH030 running

The three priorities of the afternoon's checkpoint were done. PHP's own notice was retained (LH029) and carried into version 1.1 of the PHP account as a dated later-evidence notice, after an evidence review (notes/R-0032-php-later-evidence.md), a reader-and-inference review (notes/R-0033-php-later-evidence-reader.md) and one recheck of what the resolutions wrote (notes/R-0034-php-later-evidence-recheck.md). A bounded discovery pass (notes/php-discovery-2026-10-23/) found no reader update and two bounded candidates: CISA's catalogue of exploited vulnerabilities, whose entries carry a date added, and a fixed panel of appliance vendors' advisories, since PHP embedded in vendors' products is fixed on the vendors' clocks. LH030 was fixed before its outcomes were read, apart from PHP's and Cloudflare's, which its brief discloses as already known, and took its baseline at 17:15 UTC: no structured record yet held CVE-2026-115560, CERT-EU's advisory carried the instruction with only a general qualification, not PHP's condition, and cited a news article for it, and Cloudflare linked PHP's notice and stated the version scope PHP left implicit. Three options were weighed for what comes next. Continue the question: LH030's daily reads through 30 October are time-sensitive and cheap, and its records will show within days whether the trackers' affected and fixed fields bear out the one inference the public account makes, that the 21 October releases do not close the new path; this is taken. Repair a measurement: LH024's and LH025's daily reads for 23 October were not made, and LH028's rapid slots after 23 October 16:06 UTC were not made by this session; they resume under their own protocols, a missed slot staying missed. Another outward question: the two discovery candidates each got a brief the same evening, fixed before their outcomes were read: LH031 (CISA's catalogue of known exploited vulnerabilities; none of the three CVEs listed at its first read) and LH032 (the Dutch NCSC's public PHP-related inventory, read through its git history; 751 entries, 109 with a recorded fix, two days after the release, by the list's clock). When PHP publishes its next regular release with the CVE-2026-115560 advisory, about 19 November by the four-weekly cadence of its last regular releases on its news page, and on no date PHP has given, the PHP account takes a dated version 1.2 in PHP's own words. LH013 remains the standing baseline behind this time-sensitive work.

Checkpoint, 23 October 2026: connect the PHP watch to investigation and reading

Five rapid LH028 snapshots through 23 October 16:00 UTC preserve two consequential Cloudflare revisions, while the public account remains dated 22 October. Continuing identical captures, repairing the reader loop, and launching another measurement were weighed. Repair the reader loop first: retain PHP's original related-vulnerability notice, whose configuration conditions were read separately during the keeper's assessment, and prepare a reviewed dated update. Then make a bounded discovery pass and fix one feasible question about how a mitigation instruction travels through a defined public-notice panel. The continuation plan records source context, existing work, ceilings, acceptance gates and exact next action. The existing source/image protocols retain their clocks; the fixed panel does not prevent separately logged investigation. No public deployment rate or causal AI effect is currently measured. LH013 remains the standing baseline priority after time-sensitive capture and this reader repair.

Checkpoint, 21 October 2026: the emergency PHP release

Consumer boundary: LH021 fixed three application-image repositories and a tiny deterministic file and run rule in its protocol, commit f58afb6, before reading their files and runs. Its feasibility record finds literal PHP base references in selected WordPress and Drupal recipes and two successful runs at each sampled head among the latest ten, but no resolved input digest or derived-image publication; the fixed four-file cap reaches only Nextcloud proxy examples. Some sampled commits and runs precede the patched registry images. This is an instrument failure for one repository and an adoption limit for all three, not a negative uptake result. Repair the production-recipe selection and link runs to digests under a new brief before attempting an uptake estimate; no population denominator is available.

Publisher-chain reading: LH020 fixed a retrospective selected-case protocol in commit 6fc2af8 before API collection. Its record retains 15 public GitHub responses and replays a timeline from an early public image-maintainer issue, through two explicitly linked PRs and successful publisher CI, to LH018's registry observations. The official-images PR merged at 15:16:45 UTC; the earliest selected platform's Hub push field is 16:27:22. Those endpoints do not expose the intermediate production build or any consumer pull. The public issue's 07:17:01 timestamp is evidence in one selected venue, not a measure of who knew or when disclosure first occurred. Next, if this chain is pursued, inspect Docker's meta and staging records under a separate bound and select public consumer repositories before reading their responses. LH019's later checkpoints and LH013 remain independent.

Further bounded reading, later the same day: LH018's first snapshot could not recover what moving PHP tags named before it. LH019 fixed a four-tag protocol in commit 4698c8e before reading those aliases. At their first observation, all four matching-variant moving tags named the same linux/amd64 digest as their fixed-version counterparts and declared the patched source versions (record). This is left-censored: no earlier moving-tag state, rollout lag, or deployment rate follows. The exact retained digests now make separately bounded 22, 24 and 28 October checks possible. LH013 remains the standing weekly-baseline priority; its ClickPy eligibility was not checked in this PHP session.

The PHP project released fixes for two critical flaws today. Issue #24 asked whether the public record shows those fixes moving downstream. Three choices were weighed. Continue the standing question: LH013, issue #15, keeps its fixed September and October weeks and remains the programme's weekly-baseline question; its earliest start date has passed, but this session did not test its ClickPy eligibility or read its outcomes. Repair a measurement: LH001 remains the planned local standard candle, but cannot recover a time-sensitive public snapshot. Ask another outward question: a single, small reading of vendor package records and official PHP image tags today can retain public evidence while tags and feeds change. The third was taken as LH018, with a protocol fixed in commit d35c517 before downstream outcomes, and a first snapshot on 21 October. The seven purposely selected tracks all have a vendor fix record or a fixed-version image declaration at the first reading, but none reveals a running deployment. The event and four fixed version numbers were known before selection, and no adoption rate or PHP-to-Python pace comparison follows. The bounded source check for the brief read Docker Hub's tag API documentation and Ubuntu's official OSV documentation on 21 October; the Ubuntu security API docs timed out and were not relied on. LH013 remains next for the standing baseline; any repeat of these PHP tracks is a separately bounded question whose first observation cannot reconstruct earlier moving tags.

Checkpoint, 29 September 2026: what to ask next

The software-updates investigation (investigations/software-updates.md) reached a checkpoint when LH012 answered what keeps older versions downloaded as far as the download log can: downloads from Pythons that no newer release supports are most of the older downloads in three of the 37 projects and fewer than half in 32, though an old Python does not say which older version is fetched; identified bounds could account for most in four, under an assumption the log cannot check, and cannot be settled in 26; what remains fits frozen lists without the log being able to count them; and the first-day share held as a tested result. Three options were compared.

• Continue the question. Two ways. First, count what the log cannot: a census of the versions of the 37 projects that public lockfiles and pinned requirements name, once each, set beside the older versions the downloads sit on, as LH008 set repositories beside downloads. It is the direct test of the frozen-list reading, but it needs a reader for public code at scale: GitHub's code search needs an authenticated reader, which a task must name, and Open Source Insights' BigQuery dataset needs an account. Second, measure on weeks not yet read what LH012 saw only after its counts: whether each project's older share and its Python-exclusion share hold from week to week, and how much of a project's downloads falls in a single combination of the fields clients report, as downloads reporting Python 3.9 made nearly two thirds of boto3's in the week read, almost all of them pip on glibc Linux with no CI flag on the one day broken down. It needs ClickPy's anonymous SQL only.
• Repair a measurement. B, the identified-bounds estimate, was undetermined for 26 projects because extras, platform markers and unread versions count as holding in its upper estimate. Reading more dependent versions narrows the last, but the log never says which extras were requested, so the repair has a floor and cannot settle most of the 26. LH001, the standard candle (issue #2), remains the repair the programme most needs to close, and remains inward, needing a Harbour instance whose host can be observed.
• Ask another outward question. Whether the two-day pace and what stays behind hold below the top fifty, by rank bands, is cheap with LH011's and LH012's scripts but widens the population before its baseline is known to be stable. How often a published image ignores its own lockfile (LH007's candidate) is cheap from Dockerfiles but about the few projects that publish images.

Selected: is what stays behind stable from week to week, and how much of a library's downloads falls in one combination of the fields clients report? (issue #15; LH013, its brief fixed on 29 September 2026 at studies/LH013/brief.md, its SHA-256 posted on issue #15 before any count of its weeks; waiting for data) A watch can call a change unusual only against a baseline that holds from one week to the next, and LH012 found, only after the counts, that downloads reporting one Python made nearly two thirds of the most downloaded library's downloads in the one week read: if such concentrations are common and steady, a watch must know them before it reads any count; if they come and go, a single week's shares say little. A combination of reported fields is not a machine, an owner or a population, and the log cannot say which machines make one; the study measures how concentrated downloads are and whether that holds, not who makes them or why older versions are fetched. It reads, for the weeks of 28 September to 4 October and 5 to 11 October 2026, the 37 projects' older share and Python-exclusion share at LH012's reference releases, set against LH012's week; the share of each project's downloads in its largest combination of Python minor, installer, operating system, libc, CI flag and country; each project's count-by-version profile of older downloads, with a test that boto3's on Python 3.9 stays flat; and, as tests of LH012's readings made after the counts, boto3's Python 3.9 share, its ratio to botocore's on Python 3.9, and how much of it sits below the last boto3 that admits Python 3.9. It may run only when ClickPy holds 12 October 2026, the day after its second week, so not before 13 October 2026; a day ClickPy lacks then is a gap day under the brief's rules, and no week already read stands in for either week. The lockfile census waits for a reader of public code that a task names; issue #4's exact-pin census would need the same.

Until LH013 can run. A session that starts before its data are held reads none of its weeks and does not wait in a loop. It weighs the other outward questions and takes one only if it is bounded and worth asking on its own, or stops and says why; stopping is a valid outcome. What each needed on 29 September 2026: the pace and what stays behind below the top fifty, cheap with LH011's and LH012's scripts, but widening the population before its baseline is known to hold, which is LH013's question; how often a published image ignores its own lockfile (LH007's candidate), cheap from Dockerfiles and public registries, about the few projects that publish images; one day of the package index's BigQuery table, which records the installer's version and would say whether the flat profiles come from pips older than 23.2 (22.3 until the correction of 29 September 2026, late evening, after notes/R-0025.md), the smallest reader of any here, needing an account that a task must name; the lockfile census and issue #4, an authenticated reader of public code or an Open Source Insights account that a task must name; issue #5, GH Archive's completeness, about 24 GB for an hour no current claim rests on; LH001, the standard candle, inward and needing a Harbour host that can be observed; and the announcement question (issue #12), resting until more advisories accumulate.

Taken while LH013 waits, 29 September 2026: does the two-day pace hold below the top fifty? (issue #16; LH014, its brief at studies/LH014/brief.md) The session of that afternoon weighed the list above. The BigQuery day, the lockfile census, issue #4 and LH001 each need an account or a host that a task must name, and none was named; issue #5 would spend 24 GB on an hour no claim rests on; the announcement question still lacks advisories; and the image question's frame would be the few projects already read. The pace below the top fifty is worth asking on its own: the two-day pace was measured only for the libraries almost everything depends on, while a watch reads libraries of every size, and the AI libraries this investigation began with, such as mcp, sit far below the top fifty. The objection recorded above is to widening what stays behind before LH013 says whether it holds, so this study widens only the pace and the first-day settling, which LH012 tested on releases no study had read, and leaves what stays behind to LH013. It reads LH011's release window and no download later than 27 September 2026, the last day LH011 read, so nothing of LH013's weeks is read. The bounded literature check was three web searches between 12:15 and 12:19 UTC, and three pages opened: pypistats.org's FAQ (pypistats.org/faqs, read 12:18 UTC), which says that mirrors, known by the installer they report (bandersnatch, z3c.pypimirror, Artifactory and devpi), download each new release when they sync, so a release day carries many more mirror downloads, and that it leaves them out of its version breakdowns; and the abstracts of two studies of adoption measured in dependents' declared versions rather than downloads, in npm (Chinthanet and others, 2019, revised 2021, read 12:18 UTC) and in Maven (Berretta and others, April 2025, read 12:19 UTC), neither of which relates the speed of adoption to a package's popularity in its abstract. Not opened: a Medium post of August 2026 on download counts, a guide to download statistics in BigQuery, pypinfo's issue on filtering mirror downloads, the npm technical-lag papers, a study of same-day releases in npm, and several download-statistics services. No published measure of how fast a release reaches a Python library's downloads by the library's rank was found in three searches, which says little about whether one exists. What it changed: a mirror's sync is a larger part of a small library's release day than of a large one's, so the brief adds a reading without those installers beside LH011's measure, which stays as it was so that the bands can be set beside the top fifty. LH014 answered the same afternoon, under Answered: below the top fifty, the two-day pace is not the rule. Its reader-and-inference review (notes/R-0020.md) found, after the counts, that a new version mostly inherits the share its predecessor held on the eve of its release, and recommended adjusting and then waiting, which was taken: the next pace reading's brief will fix that eve share and the day-2 share as a fraction of it, so that a smaller floating share and a slower arrival can be told apart, on a fresh draw of releases from September 2026 whose thirty days are held from about 1 November; and once LH013 reports whether the older share holds from week to week, LH012's measures could be read for the 87 band projects that released, on LH013's weeks. LH013 still waits for its weeks, and the options above stand for a session before 13 October, less this one.

Taken while LH013 waits, 29 September 2026, evening: does the container recipe a pinned project keeps install what its pin or lockfile names? (issue #18; LH015, its brief at studies/LH015/brief.md, its SHA-256 posted on issue #18 before any repository was read) The evening's session weighed the list above again, less the pace below the top fifty. The BigQuery day, the lockfile census, issue #4 and LH001 still needed an account or a host that a task must name, and none was named; issue #5 would still spend 24 GB on an hour no claim rests on; the announcement question still lacked advisories. The image question had been passed over that afternoon because its frame would have been the few projects LH006 and LH007 had read. Read from recipes alone, as LH007's Next proposed, it can take a larger frame that earlier rules fixed: the 469 repository and event pairs, in 332 repositories, whose pins and lockfiles LH008, LH009 and LH010 timed, and whose recipes no study had read. It is worth asking on its own because the account's slow road rests on those pins. A lockfile holds only the builds that install from it, so if pinned repositories' own recipes often install without it, images built from them take a release at their next build whatever the pin says, the timed moves describe less of what gets built than they seem to, and the lockfile census that would test the frozen-list reading would have to read recipes as well. It reads no download count, so nothing of LH013's weeks. The bounded literature check was five web searches between 15:26 and 15:29 UTC, with five pages opened, listed with their dates in studies/LH015/sources.md: a study that rebuilt 5,298 Docker builds of 2023 and found, in half of the images compared, at least 22.6 per cent of packages at another version (Malka, Zacchiroli and Zimmermann, January 2026, read 15:27 UTC), whose advice on pinning rests on the linter hadolint; that linter's rule for pip installs (DL3013's source, read 15:28 UTC), which never looks inside a requirements file or at pip install . and counts a lower bound as a pin; a study of how lockfiles are designed across package managers (Gamage and others, version of October 2025, read 15:28 UTC); and the abstracts of two studies of Dockerfile smells, of 2021 and 2022. Not opened: the journal versions of those studies, Cito and others (2017), five other preprints, thirteen issues and pull requests on GitHub, and several blogs. No published measure of how often a repository's recipe installs from its own lockfile was found in five searches, which says little about whether one exists. What it changed: counts built on the linter's pinning rule measure neither exact pins nor lockfile use, so the brief classes an install by the files it reads, from the installers' own documentation. LH015 answered the same evening, under Answered: about half of the pairs kept a container recipe, and where the rules could decide, most recipes installed from the pinned file, with more than a quarter undecided and no label standing. For the lockfile census it means a count of lockfiles should read the install commands beside them, in container recipes and in the workflows that build and test a project, which this study read only for build settings. LH013 still waits for its weeks, and the options above stand for a session before 13 October, less these two. For such a session the reader-and-inference review of LH015 (notes/R-0022.md) recommended one more bounded step on the slow road, filed as issue #19: class the install steps in the same 469 pairs' CI workflows under LH015's installer table, since CI installs are what the download log's CI flag marks, and the frozen-list reading turns on whether they read the lock that a recipe leaves unread. At the same checkpoint the reader-and-inference review, after its two pilot rounds, was kept as a standing step before release, because both rounds changed public claims the evidence review had passed (notes/reader-review.md).

Taken at the keeper's question, 29 September 2026, late evening: which steps of the workflow changed the conclusions? (issue #20; LH016, its brief at studies/LH016/brief.md, its SHA-256 posted on issue #20 before either coder read a diff) The keeper asked which parts of the recent research and review workflow materially improved the conclusions, and what Lighthouse should learn from that. The study reads the repository's own history and no download count, so nothing of LH013's weeks, and its sources needed no literature check. It answered the same evening, under Answered. What it changed: AGENTS.md step 2 says what each check found; step 4 has a fresh agent read whatever a round writes to resolve a review, a relayed review included; the Evidence paragraph has a reading made after the counts that reaches a public surface name the brief, amendment or issue that will test it; notes/reader-review.md records the replay and calls the recheck the first reader of the resolution's text; and the About page describes the second review, the recheck and the readings the keeper relays. For a session before 13 October, the two corrections its replays found (issues #21 and #22) came before new research, since they were claims already released.

Corrected the same night, after a review of LH016 relayed by the keeper. Astra, a reviewer outside the workflow, read LH016, reran its replay, and recommended one bounded correction round and then outward work. The round corrected the two claims, the reading of the pace to version 1.2 and the reading of what stays behind to 1.2, with their records at 0.4 and the synthesis's notices to match (issues #21 and #22), and took LH016 to version 0.2: step K is outside review relayed by the keeper, much of it Astra's by Astra's relayed account, at an unknown cost rather than a person's reading at none, and LH016's costs per change describe its rounds rather than rank the steps or allocate work. AGENTS.md step 4 now has the session that resolves a review see that its text gets one fresh reading, not a chain of them. Next, for a session before 13 October: issue #19, the install steps of the same pinned projects' CI workflows, bounded and worth asking on its own because whether CI reads the lockfile a container recipe leaves unread bears on the frozen-list reading, with its brief fixed before any workflow is read. It can show whether a road runs from a pin to the builds the log flags, and how often for these projects, not how many of the log's older downloads travel it, so its brief says what it cannot say about downloads, counts per repository as well as per pair, and discloses the workflows LH015 already read (notes/R-0025.md). The reader review of the pieces released before 29 September (issue #23) is a finite backlog, taken one piece at a time beside outward work and starting with the synthesis, and no round waits on it. LH016 does not say which models, or how much review, a round should buy, and the programme does not press that question now. LH013 still waits for its weeks.

Taken on 30 September 2026: do pinned projects' CI workflows install from the pin or lockfile their container recipes leave unread? (issue #19; LH017, its brief at studies/LH017/brief.md, its SHA-256 posted on issue #19 before any repository was read) The brief took the design issue #19 and notes/R-0025.md set out: LH015's frame and snapshots, the install steps of GitHub Actions and GitLab CI jobs classed under LH015's installer table, counts by repository beside pairs, LH015's reads of the same workflows disclosed, and a section on what the study cannot say about downloads; it added a primary share for the lockfile itself, and left LH015's rule for a build's starting folder to LH015, since deciding its 13 pairs could not lift that study's withheld label. The bounded literature check was five web searches, from about 06:48 to 06:50 UTC, and three pages opened, listed with their dates in studies/LH017/sources.md: a scan of the workflows of the repositories PyPI packages link to (Nesbitt, 25 May 2026, read 06:50 UTC), which found GitHub workflows in 152,000 of 343,000 repositories, Travis CI in 11 per cent and every other system below 2 per cent; and the abstracts of two studies of GitHub Actions, on caching in 952 repositories (Hasan and others, April 2026) and on how workflows change in 49,000 (Rostami Mazrae and others, February 2026), both read 07:01 UTC. Not opened: about twenty blog posts, guides and issues, listed in the sources. No published measure of how often a Python project's CI installs from its own lockfile was found in five searches, which says little about whether one exists. What it changed: the brief classes GitHub Actions and GitLab CI and counts the rest, and records caches as written, since a cached job may fetch nothing. LH017 answered the same morning, under Answered: where the rules could decide, some CI job reads the pin at almost every pair, and the timed lockfile at 164 of 188, half of those through commands that can re-lock.

Checkpoint, 30 September 2026. With LH017 the slow road has been read as far as a repository's own files go: pins move over weeks, container recipes install from them in most of the cases the rules could decide, with no label standing, and CI jobs almost always, the lockfile itself mostly. Three options were compared. Continue the question: whether that road shows in the download log. LH012 found, in the one week it read, older pip and uv downloads carrying the CI flag more often than newer ones in 20 of 37 projects (median difference 1.6 points), a descriptor its brief fixed; LH013's weeks could describe the same on weeks not yet read, project by project, if its brief is amended before any of its counts; the runs themselves are recorded only in run logs, which need GitHub's API and a token a task must name. Repair a measurement: the 50 undetermined pairs, most through reusable workflows kept in other repositories and local actions nested two deep, which a second level of reading could decide; it could lift the lockfile share's withheld label only by deciding most of 31 pairs, and would change no conclusion. Another outward question: none bounded and new before 13 October beyond the list above; issue #17's fresh draw of releases waits for their thirty days, from about 1 November. Selected: LH013 stays first, from 13 October 2026, and before any of its counts its brief takes an amendment adding, for each project and week, the share of pip and uv downloads flagged as CI below the reference release and at or above it, beside LH012's week. It does not count the road LH017 found; it tests on weeks not yet read whether older downloads lean to the CI flag, which that road predicts, and says so. The reader review of LH017's pieces (notes/R-0027.md) recommended the same step, sharpened before any count: the flag crossed with Python admission, both fields of pypi.pypi, which LH013 already passes over, since a test matrix on an old Python or a resolver's walk inside CI would give older downloads the same lean, while older downloads flagged CI on a Python the newer versions admit are the road's own trace. That is taken for the amendment, which a session writes before 13 October: it reads the flag's share within pip and uv downloads by version class and by whether the download's Python is admitted, with its test fixed before any count. The review also asked what setup-uv's cache holds; its READMEs, read after the counts, say that v4 to v7 drop pre-built wheels from the cache by default and the current version keeps them, so whether a cached uv job fetches its pinned version at each run depends on the version it names (studies/LH017, Finding 15), and the amendment says so. Until then the reader review of the pieces released before 29 September (issue #23) is the finite work, and a session may stop.

The bounded literature check of 29 September 2026 was two web searches, around 07:36 UTC, and three pages opened. Opened: Python's table of its versions, read 07:31 UTC, which gives Python 3.9's end of life as 31 October 2025; boto3's own description on the Python Package Index (its JSON, read 07:38 UTC, version 1.43.104), which says that "On 2026-04-29, support for Python 3.9 ended for Boto3"; and a security vendor's blog post, PyPI Download Statistics as a Security Signal (Safeguard, 17 March 2026, read 07:39 UTC), which calls download numbers noisy, gameable and widely misused and measures nothing. Not opened: pepy.tech's page for boto3, libraries.io's, a Medium post of August 2026 on download counts, pypistats.org's FAQ (read by LH005) and the Python Packaging User Guide's page on analysing downloads (read by LH005 and by LH012 before its brief), a discussion on discuss.python.org about CI and download statistics, and a post on Python in Plain English. No published measure of how much of a library's downloads one combination of client fields carries was found in two searches, which says little about whether one exists. What it changed: the concentration measure is defined over the log's own fields and says in advance that a cell is not a machine.

Revised 29 September 2026, after the keeper read the released piece. The selection first asked how much of a library's downloads "one kind of machine" can make; a combination of reported fields is not a machine, an owner or a population, and the question and the brief now say so. The brief was fixed the same day with its two weeks and the condition for reading them. For the next two research rounds, a reader-and-inference review is added before release as a pilot (notes/reader-review.md). Its rehearsal on LH012's corrected pieces (notes/R-0018.md) found that boto3's and aiobotocore's older downloads have the profile of an installer's resolution walk, and recommended adjusting and then continuing: correct LH012 with that reading, labelled post hoc, which was done; add the version profile and a test of boto3's to LH013's brief before any count, which was done; name the installer's version in BigQuery as a smaller reader to seek, which is listed above; and then wait for LH013's weeks.

Checkpoint, 28 September 2026: what to ask next

The software-updates investigation (investigations/software-updates.md) reached a checkpoint when LH011 answered its question: in 26 of the 37 most downloaded projects that released, most new releases reached half of the downloads within two days, and in eleven none did. Three options were compared. The choice was revised the same evening, after the keeper read the released piece; the revision is recorded at the end of this section.

• Continue the question: what keeps older versions downloaded. LH011's most interesting observation, made only after its counts were read, is that in almost every project a new release took most of the share it would hold for the month on its first full day, while from 18 per cent to nearly all of the downloads stayed on older versions throughout (record version 0.3, Findings). What that remainder is made of is what a watch needs to know before it can call a pace unusual. LH011's retained counts cannot say: every version older than a project's first qualifying release is folded into one "~other" row a day (studies/LH011/data/counts/), and no Python version was read. A small new read would: ClickPy's per-version counts of the older versions and its per-download Python version, installer, CI flag, operating system and libc, on days fixed in advance, with PyPI's metadata for each version and for the projects' most downloaded dependents. It reuses LH011's frame, which its brief must disclose.
• Repair a measurement. LH001, the standard candle (issue #2), is the most valuable repair for the programme, a condition for closing it, but it is inward and needs a Harbour instance whose host can be observed, which a task must name. GH Archive's completeness for a small cohort (issue #5) needs about 24 GB for LH002's window and bears on one hour that no current claim rests on. The exact-pin census (issue #4) needs Open Source Insights' BigQuery dataset, which needs an account. Within LH011, the folding of older versions is a gap in what was kept, not an error, and is repaired by the continuation's read.
• Ask another outward question. Whether the two-day pace holds below the top fifty, by rank bands (LH011's second Next), is cheap with LH011's scripts but widens the population without explaining what stays behind. How often a published image ignores its own lockfile (LH007's candidate) is cheap from Dockerfiles but about the few projects that publish images. The announcement question (issue #12) still rests, for the reasons in the checkpoint below.

Selected: what keeps older versions downloaded after a new release, and which explanations can the public record rule out (issue #14). It asks what the ordinary part of a library's downloads that does not move is made of, which a watch must know before it can call any movement unusual. It needs only ClickPy's anonymous SQL and PyPI's JSON. What the brief should fix, before any older version's count is read:

• All 37 projects. The frame is every project with a qualifying release in LH011, not the eleven with a comparison set: the 26 projects where new releases took over still had 18 to 47 per cent of their downloads on older versions a month on, and choosing the eleven because they were slow and then explaining their slowness would select on the outcome.
• Three explanations, each with the trace it would leave, each allowed to hold for some projects and not others, or for none. Dependents' version bounds would put the older downloads on the few versions a bound allows; for a tightly coupled pair, such as boto3 with s3transfer and botocore, the dependency's share can be predicted from the parent's version mix and its declared range, which tests a bound with a number rather than a pattern. Python compatibility would put the older downloads on Pythons that the new release's Requires-Python excludes, which the log's per-download Python version can test directly. Environments rebuilt again and again from a frozen list would spread the older downloads over many versions, more often flagged CI, with their own installer, operating system and libc mix; the log can describe that, not count it, and the brief says so in advance, as what would leave the question inconclusive.
• The unit. A download is a fetch, so a share of downloads weights each environment by how often it fetches; a low share is not by itself slow uptake, nor a high share broad uptake. The brief says what each measure counts.
• The same releases read two ways. LH008's four fixes are LH011 releases. A check made by the driving session on 28 September 2026, after both sets of outcomes were known (LH011 record version 0.3, Findings), found that 50 of LH008's 102 pinned repository pairs moved to the fix within 30 days of its release, while the four releases' download shares rose by 3.4 to 14.7 points over the same days. The brief discloses this as known and may set it out properly, offline, as its first step.
• The first-day observation measured, not assumed. The brief fixes a measure of how much a release's share changes between day 2 and day 30 before any count is read and, as a secondary question if the ceiling allows, reads it for the same projects' releases that LH011 did not read (November 2025 to March 2026), since rereading LH011's releases would not be a replication.
• Primary sources first. Before the brief is fixed, read from PyPI's JSON each version's Requires-Python and file tags and the requirements of each project's most downloaded dependents: they are what an installer obeys, and they touch no outcome, so they may be read before the brief; per-version counts come after. Support policies such as SPEC 0 and NEP 29 are context, not evidence. A search result is a lead, not a source: the brief cites only pages it opened, with the date read.

The bounded literature check of 28 September 2026 was five web searches whose results were read as summaries, and no page was opened, which falls short of reading the primary literature. Two of its summaries misdescribed papers whose abstracts the release review then read (notes/R-0014.md): PyPitfall (2025) reads the declared dependencies of 378,573 PyPI packages for vulnerable versions, and LibEvoBench (2026) is a benchmark of whether code-generating models keep track of library versions; neither measures downloads. Work on "technical lag", Decan, Mens and Constantinou, 2018 and a 2020 study across package managers, measures lag from what projects declare, not from downloads, by the search summaries. The results also pointed to aiobotocore issue 840 and issue 829, on its narrow bound on botocore, which returned HTTP 403 here and were not read, and to SPEC 0 and NEP 29, the support policies the scientific Python projects publish, which were not opened; what any release supports is in its own metadata. A search for per-version download distributions of numpy found only tools (pypinfo). No published measure of which older versions a library's downloads sit on was found in five searches, which says little about whether one exists. No brief is written yet.

Revised 28 September 2026, after the keeper read the released piece. The first selection was "what holds the eleven back": the eleven with a comparison set of fast projects, and two explanations, dependents' bounds and Python support windows. The keeper's reading was that a low share of downloads is not slow adoption, since a release that jumps to a fifth and stays there may have reached its readily available users at once, and that the observation worth following is the share settling on the first day. The question was widened to what keeps older versions downloaded, across all 37 projects; a third explanation was named so that "neither" has a trace of its own; the first-day observation, made after the counts, is to be measured in advance and checked on releases not yet read; and the brief is to read primary sources before it is fixed. The piece was revised to version 1.1 and the record to version 0.3 at the same time.

Checkpoint, 27 September 2026: what to ask next

The software-updates investigation (investigations/software-updates.md) reached a checkpoint when LH010's reanalysis left the announcement question not settled and the synthesis set out the current account. Three options were compared.

• Continue the announcement question (issue #12): the same question over a longer window of advisories, with the earliest public notice naming the fix as the clock, the handling of unreadable notes and a library-clustered interval fixed in the brief. It is the one open disagreement in the current account. But five months of the top 500 gave 30 libraries with pinned dependents, not 40; twenty a class needs a year or more of advisories or a new frame rule, a clock searched beyond OSV is new instrument work, and at this power the likeliest result is another wide interval over populations that overlap LH008 to LH010.
• Repair a measurement: read GitHub's release pages for the nine silent fixes without readable notes (four with pairs). Cheap if the pages can be read, but they were refused to anonymous reads in LH009, an authenticated reader would change the study's access conditions and must be named by the task, and the most it can change is the class of four of thirty libraries, which cannot move a test of this power. It belongs in the continuation's brief, not in a study of its own.
• Ask another outward question: LH011, whether a release reaches half of a project's downloads within two days as a rule, and how much of that is builds. The fast half of the current account rests on one release of one library (LH005, echoed by LH007's images); this tests it across fifty projects, gives the ordinary pace a watch needs before it can call anything unusual, shares no data with the announcement question, and needs only ClickPy's anonymous SQL and LH005's scripts. Its weak point is the CI flag, which clients report and whose rule LH005 could not read.
• Also considered: LH001, the standard candle below, still a condition for closing the programme but inward; and how often a project's image ignores its own lockfile (LH007's candidate), cheap from Dockerfiles but about the few projects that publish images.

Selected: LH011. It asks the cheapest question whose answer changes the most of the current account: if the two-day pace holds, the synthesis's "days" becomes a measured rule rather than one case; if it does not, the account's fast half is narrower than it reads. The announcement question rests, unsettled, with issue #12 open, until more advisories accumulate or a frame that does not need listed dependents is designed. A bounded literature check (five web searches on 27 September 2026, results read as summaries; URLs in the brief) found no published cross-project measure of uptake by downloads and a consistent warning that automation and caching bias counts differently by package; it changed the design so that the CI share is compared within project and within days, only over installers whose flag is known, with the installers' source read for the flag's rule before any count.

LH001 Observing a known Harbour workflow

Question. Which parts of an ordinary workflow can our sensors reconstruct, and which consequential events do they miss?

Role. LH001 is Lighthouse's standard candle: a workflow whose inputs are recorded, observed by the instruments that will later observe unknown activity. Its published signature is what makes outward readings interpretable rather than merely countable.

Design. Select one bounded Harbour workflow with identifiable initiation, processing, communication and completion records. Prefer a test environment or an existing routine task whose normal execution can be observed without changing its purpose. Choose a dispatch target whose host can be instrumented: a command-line or local agent runs on a machine Lighthouse can observe, whereas a web session runs on a provider's infrastructure and exposes only what the provider reports. Capture an idle baseline, the workflow, and a declared follow-up window for persistent changes.

Initial sample. Use a calibration run of three repetitions under comparable conditions, with the ordering and collection interval recorded. Include one ordinary non-LLM operation where available, such as a CI run or a dependency install, to test whether the proposed signature is specific to inference. This is an instrument calibration, not a population estimate. Record each instance and task variation.

Readings. Start with Harbour's dispatch fields (identifier, kind, target, model, harness, effort, queue and claim times), feedback entries with their timestamps and terminal marker, usage entries and proxy audit entries [S12]; the repository's pull request, review, CI and merge records; host process activity where available; and versions of affected artefacts. Preserve remote calls as remote activity: local CPU readings do not measure a provider's inference compute. Add electricity only if the measurement boundary is defensible.

Retention. Harbour's records are time-limited: dispatch items expire after twenty-four hours, and feedback, status and audit records after thirty days, at the time of writing. Export what the study needs within them and record each export as an observation. Repository and CI records persist longer and can anchor the follow-up window, which is proposed as seven days after the last repetition.

Comparators. Reconcile against operator-labelled events and Harbour's operational record. That record is server-timestamped for queueing and claiming but agent-reported for progress and completion, so treat the agent-reported parts as claims to be checked, not as ground truth. Examine disagreements at the event level. Include a known small coordination event if available, so the analysis tests whether low-volume activity with broad consequences remains visible.

Analysis. Produce an activity timeline, a flow account with duplicate observations identified, a before-and-after state comparison, and a record of any subsequent activity the change enabled within the follow-up window, such as further dispatches, CI runs or deployments. That last record is the smallest observable instance of propagation and gives the follow-up window its purpose. Report timing error, event detection, missingness, collection overhead and the limits of inferred dependencies. Keep observed relationships separate from hypothesised causal links. Publish the calibration in a form later studies can cite: signal per token, per request and per change, with the instrument version and boundary.

Alternatives. Check whether bursts reflect retries, scheduled jobs, cache behaviour, shared host load or sensor overhead. Determine whether apparently persistent activity is ordinary background processing.

Stop and output. Close after the planned runs and reconciliation, or document why the instruments cannot answer the question. Produce a study, an instrument revision and an observation sample suitable for sharing. No favourable hypothesis result is required.

Execution record. Before collection, write the study's brief with the exact workflow, participating systems, dispatch target, access scope, retention, timing, resource ceiling and review responsibility. LH001 proposes no change to Harbour's production behaviour.

Questions after these

Choose follow-up work from observed gaps. Candidates from LH012 are whether what stays behind is stable from week to week and how much of a library's downloads falls in one combination of the fields clients report, selected at the checkpoint of 29 September under Next as LH013, whose brief waits for its weeks to be held; a census of the versions that public lockfiles and pinned requirements name for the 37 projects, set beside the older versions downloads sit on, once a reader for public code at scale can be named; and narrowing the identified-bounds estimate for the 26 projects it left undetermined, as far as the log allows. Candidates from LH014 are a fresh draw from the same bands on releases from September 2026 on, from about 1 November 2026, with the reading of build tools and young projects and the eve share and its ratio to the day-2 share fixed in advance as tests; and, after LH013, what stays behind in the 87 band projects that released, by LH012's measures on LH013's weeks. Candidates from LH011 are whether the two-day pace holds below the top fifty, by rank bands, with the same rules, taken by LH014; and what the new release's lower CI share consists of; its first candidate, what keeps older versions downloaded, was taken by LH012. Candidates from LH010 are widening the announcement question to a longer window of advisories, which LH008's rule allows, so that each class has enough libraries to see a modest difference, with the clock (the earliest advisory, CVE or NVD record naming the fix) and the handling of unreadable notes fixed in the brief, and reading GitHub's release pages, from an address that is served them, for the nine silent events without readable notes; the first is issue #12, resting since the checkpoint under Next, and the second belongs in its brief. Candidates from LH009 are reading GitHub's release pages from an address that is served them, for litellm's, mcp's and langchain's fixes, and reading the pull requests of the people who moved in the week after an announced release, to see whether they cite its notes, once GitHub's API can be read. Candidates from LH008 are reading Dependabot's pull requests, where they are public, to separate its security updates from its version updates, once GitHub's API can be read, and whether projects' pins move together in one change across libraries, which LH008's pairs counted separately. Candidates from LH017 are the CI flag's share of older and of at-or-newer downloads on LH013's weeks, crossed with Python admission, by an amendment to its brief before any count, which is the selected next step; reading the runs of the same projects' workflows, whether they ran, how often and with what cache, once GitHub's API can be read; deciding the 50 undetermined pairs by reading one level further into reusable workflows kept in other repositories and nested local actions; and whether the jobs that could re-lock ever did. Candidates from LH015 are the install steps of the same 469 pairs' CI workflows and documented install commands, classed under its installer table, which would show whether CI reads the lockfile a container recipe leaves unread, taken by LH017; the rule for a build's starting folder, fixed better, for its 13 pairs; which of a repository's recipes, if any, makes the images it publishes, from the workflows that push images and the registries they name; and a lockfile census that reads the install commands beside the lockfiles. Candidates from LH007 are how often a project's image ignores the project's own lockfile, across a larger frame, which Dockerfiles alone could answer without a registry read, taken by LH015 for the repositories whose pins LH008 to LH010 timed, and reading the Docker Hub images LH007 left unread with a byte budget sized for multi-gigabyte images. Candidates from LH006 are recording what moving tags name over time with a HEAD request on a schedule, rereading the images LH006 could not from an address with its own allowance, and whether any public source records runs of published software at all. Candidate questions from LH002 are how long exact-pin dependents take to move across all of a release's dependents, and how complete GH Archive is for a small cohort over a whole window. Others include whether small control signals predict large downstream changes, which state changes survive after inference ends, how much apparent growth comes from changed visibility, which layer carries the earliest detectable signal in a propagation event, whether a standard candle measured on one workflow transfers to another, and which of Harbour's own workflow findings leave a computational signature that an outside observer could detect. A later risk study could test whether the instruments distinguish benign repeated deployment from a propagation scenario in a contained model.

Readings made after the counts that no brief, amendment or issue yet tests are candidates too; studies/LH016/data/post_hoc_readings.csv lists the 23 in LH010 to LH015 as of 29 September 2026, twelve of them without a planned test.

Prioritise questions by scientific value, decision relevance, evidence access, tractability and cost. Record the reasoning rather than hiding it behind a single numerical priority score. Keep speculative essays connected to the questions in this file so that ideas can become testable when suitable evidence appears.

The first public collection holds the charter, LH003 and LH004 with their pieces, and will hold LH001, LH002 or its feasibility result, and an account of the instruments. Every visual identifies its sample and observation period. When the programme is reviewed, retain the methods that produced useful evidence, repair weak instruments, and close questions that cannot currently be answered. The next investigation should be smaller and clearer because the first programme happened.