design()replication() and replication_gate() in sphragis/experiment/decomposition.py read the
GitHub family as registered on 2026-10-04. The family takes only Apache, LLVM, .NET and Grafana,
in that order; a Gerrit organization is refused there, as design() refuses a GitHub one, and a
registered organization outside the members is reported as not collected.
Four independent searches (RQ1's neighbours, RQ2's attacks and defences, methodology, and the federated-agents framing), each reading what this log, the intake file and the bibliography already hold, verifying every identifier and reading the closest works in full.
sphragis/experiment/across.py, and four fields on every H1 cell from h1_over_partitions:
meaningful (lower bound above the SESOI, per level), p_one_sided (the share of the cell's own
bootstrap draws at or below zero, the registered p-value), bootstrap_se (the draws' standard
deviation, the cell's weight in the summary) and resamples (the draw count, which the reading
checks against the level). Choices made in the implementation, each before any
reading exists:
AJ delegated the route spec's two open questions (highest-quality research, decided from current practice). Both are decided before any GitHub organization has a corpus beyond its pilot month and before any test window is fetched. This replaces the 2026-10-01 rule that listed the GitHub organizations as candidates behind Qt and Chromium.
partition-sensitivity-openstack.json, SPORC job 21794711 (CPU only, pinned at 89753ef), in
place of TIGRIS job 210563, which was cancelled when the TIGRIS queue slipped. It replaces the
artifact of 2026-09-30, which ran on the ten-month 1,635-change window at 300 trials per step.
Its placebo input is read from the cluster data root; that file, redacted, is byte-identical to the
committed rq1-placebo-openstack-v3.json. 1,000 studies per power step and 4,000 null studies,
K = 24, N = 1,850, and the twelve-month projection (2,017.6 changes, simulated at 2,017, rounded
down), with sigma_run calibrated on the pilot's 206 changes:
partition-sensitivity-wikimedia.json, SPORC job 21794712 (CPU only, pinned at 8c87f28 with the
arguments of OpenStack's rerun), in place of TIGRIS job 211288, which was cancelled when the TIGRIS
queue slipped. Its placebo input is read from the cluster data root; that file, redacted, is
byte-identical to the committed rq1-placebo-wikimedia.json. 1,000 studies per power step and
4,000 null studies, K = 16, N = 1,850, the 2,848-change lower-bound window, and sigma_run
calibrated on the pilot's 429 changes:
memory-probe-sporc.json, SPORC job 21796973 (A100-PCIE-40GB, 42.43 GB as the device reports
it, pinned at 592b11e). scripts/memory_probe.py trains the registered 7B with train_adapter
for two optimiser steps a cell on synthetic items of fixed length, at the registered rank and at
256, then runs the registered fp32 generator over a prompt one token under the training bound.
Training runs one item per micro-batch, so the longest item sets the peak, and no item over
2,048 tokens can be trained on. The CUDA context and libraries hold 0.55 GB outside PyTorch's
allocator.
label-audit-v2-open-rater.json (labels label-audit-v2-open-rater-labels.json, SPORC job
21795722, six minutes on one A100). Qwen3-14B at pinned weights labelled all 358 items still in
the refined corpus, none unparsed (the 25 audited examples a later refinement removed are left out,
13 of them human-checked, so the human pairs read on 139 items). By the rule fixed beforehand it
is adopted: its label kappa with the human, 0.254 [0.102, 0.404], reaches the lower end of the
locked human~A interval, 0.154. That bar was lenient by design, so the comparators on the same 139
items carry the reading: the human agrees with rater A at 0.289 and with rater B at 0.343, so the
open rater sits just below A, its interval overlapping both. Collapsed to valid or not, its kappa
with the human is 0.367.
The October 2026 hardening plan (ROADMAP Plan H, on the GitHub-route branch): raters A and B ran through an API, so the audit cannot be rerun on them once they
are retired. scripts/label_audit_open_rater.py adds a rater anyone can rerun: Qwen3-14B (Apache
2.0, revision 40c0698), greedy, thinking off, labelling the same 383 audited examples under the
committed v2 rubric and shown only the fields A, B and the human saw. Its agreement with each of
them (raw agreement, kappa, AC1 and specific agreement, on the five labels, collapsed to valid
or not, and on outside_names) is read with the audit's own statistics, each pair on the items
both raters answered (the human's 152 checked items for the human pair). Reading, fixed now:
it is adopted as the audit's reproducible rater if every item parses and its label kappa with
the human reaches the lower end of the locked human~A label interval in label-audit-v2.json
(the script reads it from there and records the decision); otherwise it is reported as tried and
not adopted, as the decision model was (2026-09-30). That bar is lenient, since rater A agrees
with the human less than with rater B, which is the reason to report all three pairs beside it.
The items are the refined examples the audit sampled, read through refined_examples; an
audited example a later refinement removed (the audit drew from corpus v2) is left out rather than
rebuilt, listed by id, and every pair is read on the items that remain. The committed rubric differs from the raters' copy only
in its worked example (invented here, a corpus item there).
backport-share.json (scripts/backport_share.py), metadata only. ROADMAP Plan H asked whether
pre-cutoff code enters through cherry-picks: a change's window is its creation month, so a
backport created inside the corpus can carry code first written before the checkpoint. A backport
that keeps its original's Change-Id can be traced, and the examples keep no branch, so each one is
read two ways. When every change with its (project, Change-Id) sits on a release, maintenance or
deployment branch (as the hosts name them, from OpenStack's stable/ and StarlingX's r/stx to
MediaWiki's REL1_xx, fundraising/REL1_xx and deploy/wmf/), its original is not in the corpus
and may predate it. When any does, it may be such a backport, whose original is in the corpus and
postdates the checkpoint with it.
github-conversion-apache.json. Apache's 2024-11 lists 11,083 PRs, all counted: 2,051 opened by a
bot or agent were not collected, 2,241 carried a reviewer's inline comment, 3,370 examples were
built and 2,453 survived refine. Against 8,736 reviewer threads the conversion is 0.281, 95%
interval [0.259, 0.304], the highest and the tightest of the six; all 15 of the sizing's draws
in the month recount the same. Its suggestion threads (1,851) are a small share beside .NET's,
Grafana's and HashiCorp's. Across the six, a larger share of suggestion threads goes with a lower
conversion, roughly (HashiCorp's is the largest share and the lowest rate, Apache's and LLVM's the
smallest shares and the highest rates; .NET and OpenJDK break the order), as expected when a
reviewer who writes the fix leaves an example refine removes.
github-conversion-hashicorp.json. HashiCorp's 2024-11 lists 2,194 PRs, all counted: 431 opened by
a bot or agent were not collected, 282 carried a reviewer's inline comment, 444 examples were built
and 131 survived refine. It is the only pilot where reviewers open more threads with a
suggestion block (669) than without one (590), so most of its review edits are written by the
reviewer, and refine removes them. Against the 590 the conversion is 0.222, 95% interval
[0.169, 0.279], the widest of the five for having the fewest threads; all 17 of the sizing's
draws in the month recount the same. On its own pilot HashiCorp projects 154 to 4,220 examples
and stays borderline for an H1 cell and for RQ2. Its interval widens the span Apache borrows
(Apache's census is running), which lowers Apache's low end to 8,720, still past an H1 cell
(github-sizing-report.json). Five pilots in, the measured conversions run from 0.222 to 0.255.
github-conversion-grafana.json. Grafana's 2024-11 lists 3,227 PRs, all counted: 973 opened by a
bot or agent were not collected, 579 carried a reviewer's inline comment, 663 examples were built
and 306 survived refine. Suggestion threads are 761 beside 1,325 other reviewer threads, as
high a share as .NET's. Against those 1,325 threads the conversion is 0.231, 95% interval
[0.202, 0.261]; all 15 of the sizing's draws in the month recount the same. On its own pilot
Grafana projects 1,880 to 12,104 examples, so its low end clears RQ2's 1,850 by 30 and it is an
RQ2 candidate again (it had dropped to borderline on the span borrowed from OpenJDK); H1 stays
borderline. The four measured conversions so far (0.231 to 0.255) are close to one another and
to the Gerrit range they replaced (github-sizing-report.json). Apache's census is running and
HashiCorp's pilot month is being collected.
github-conversion-dotnet.json. .NET's 2024-11 lists 4,114 PRs, all counted: 1,633 were opened
by a bot or agent the route recognises and not collected (1,739 under the sizing's wider name
rule, which counts them zero), 737 carried a reviewer's inline comment, 1,098 examples were built
and 489 survived refine, which removed 609 as suggested edits. Suggestion threads are 1,078
beside 2,026 other reviewer threads, the largest share of the three pilots, so .NET reviewers
write the fix themselves more often than OpenJDK's or LLVM's. Against those 2,026 threads the
conversion is 0.241, 95% interval [0.212, 0.272]; all 15 of the sizing's draws in the month
recount the same. On its own pilot .NET projects 2,398 to 19,122 examples, so it reaches RQ2 and
stays borderline for an H1 cell; the three measured intervals all lie inside OpenJDK's, so the
borrowed span and the other classes are unchanged (github-sizing-report.json).
github-conversion-llvm.json, read as planned (2026-10-01). LLVM's 2024-11 lists 2,710 PRs, all
counted (none failed or gone): 1,069 carried a reviewer's inline comment, 1,330 examples were built
and 989 survived refine (340 removed as suggested edits). Against 3,872 reviewer threads under
the sizing's rule the conversion is 0.255, 95% interval [0.231, 0.280], tighter than OpenJDK's
on three times the threads, and all 19 of the sizing's draws in the month recount the same.
LLVM's month was collected after the retry-on-resume fix, so its github_rules digest differs
from OpenJDK's; no PR in either month failed, so the fix changed nothing in either.