Issues: 30, 70 (refs only; both stay open)
Evidence status: a committed copy of a preregistration that exists only as GitHub issue comments. No real R1 outcome exists. Nothing on this page is a result, and nothing here changes any rule.
The first real R1 decision gate was written as a comment on issue 70 and is
therefore editable, easy to miss, and absent from the repository tree. The
hypothesis, the helps / hurts / uncertain decision rule, the primary
confounder, the 20-work-unit target and the rule for scaling to 3 to 5 workers
all live only there. This page commits that text next to the readiness gate that
enforces part of it, so a reader of the repository can find the gate without the
issue tracker.
This page is a copy, not a new registration. The authoritative timestamp is
the comment’s own, 2026-08-28T16:34:42Z. Committing a copy later adds no
preregistration value of its own; it only makes the existing text durable and
linkable. The comments below were fetched with the GitHub REST API on
2026-10-14 and none had been edited (each comment’s updated_at equals its
created_at). Issue bodies were last updated 2026-09-23, so the body text cited
here is as read on 2026-10-14.
The comment was posted from the repository owner’s account. The comment does not record whether a human or owner-controlled tooling wrote it, so treat it as owner-controlled either way. It is not an independent review.
| source | where | timestamp (UTC) |
|---|---|---|
| Preregistration comment (primary) | issue 70 comment 5455112557 | 2026-08-28T16:34:42Z |
| Identical re-post of the same comment | issue 70 comment 5455128410 | 2026-08-28T16:36:01Z |
| Corpus-integrity update (first-five pilot not eligible) | issue 70 comment 5455386108 | 2026-08-28T17:02:18Z |
| Reusable-infrastructure update (BenchmarkCohort) | issue 70 comment 5454746056 | 2026-08-28T15:59:45Z |
| Readiness-gate intent | issue 70 comment 5459306168 | 2026-08-29T00:52:59Z |
| Readiness-gate delivery report | issue 30 comment 5459348518 | 2026-08-29T01:01:25Z |
| Research question, conditions, evidence gate | issue 30 body | created 2026-08-28T14:10:54Z |
| Minimum first corpus, procedure, acceptance criteria | issue 70 body | created 2026-08-28T14:41:01Z |
The primary comment was posted twice with identical text, 79 seconds apart. This page treats the first as the registration and the second as a duplicate. Issue 30 also carries two earlier comments (5453886612, 5453954401) summarizing the synthetic E012 and E013 results; they are context, not part of the gate.
Quoted verbatim from the primary comment. The only differences are layout: the comment’s top-level heading (“Bounded research outcome”) is omitted, its sub-headings sit outside the quotation, and the H1 statement is a nested quotation. A line-by-line comparison against the fetched comment text (each line compared after stripping blockquote markers) found no line of the comment missing from this page apart from that omitted heading. No rule, number or threshold was altered.
Verified live evidence now changes the interpretation of this issue.
From merged PR #117’s successful exact-head workflow (
Real Two-Attempt Evidence E2E, run33187051319), the two normal real attempts were both independently supported, but they produced the same candidate patch digest:
sha256:8383a0dd5217e9472e5f55eb658248620e539394cb96012dc61c24a3cc33f6cfThe same run also preserved one verified peer when the other real worker invocation failed (
worker_error, exit code 2). Therefore the current real evidence establishes orchestration/replay/fault-isolation reliability, but it does not establish useful candidate diversity or reduced error correlation.
For the first frozen corpus with
swarm_size = 2and equal attempt budgets:H1: two prospectively declared structural signatures produce a higher independently verified task-success rate than two replication-baseline attempts from one fixed structural signature.
Primary comparison must use the already-merged
randomness_lab.r1_replayunchanged. The primary decision statistic is its paired bootstrap classification for independently verified success:
helpsonly if the paired 95% interval forsuccess_diverse - success_replicationis entirely above 0;hurtsonly if entirely below 0;- otherwise
uncertain.
For each eligible held-out work unit:
- replication arm: 2 attempts from one frozen
r1_structural_signature;- diversity arm: 2 attempts from 2 distinct, prospectively declared structural signatures;
- same WorkUnit/source revision and equal total attempt count;
- every included candidate independently verified with retained negative/failed outcomes.
The current #117 same-patch pair is useful as a control-plane replication example, but must not be counted as evidence for H1 because it is one smoke task and does not compare structural signatures.
Structural quality vs structural diversity. A different signature may simply be a stronger or weaker worker rather than useful diversity. Record each signature before hidden/final outcomes and report per-signature marginal success alongside pairwise failure correlation. Do not redefine signatures after seeing benchmark results.
Secondary confounders to retain in the corpus: verifier/model-family overlap, task difficulty, missing cost fields, inconclusive verification, and unequal hidden-test coverage.
Use the existing target of at least 20 eligible real work units for the first bounded result. Publish:
- the unchanged
r1_replaysuccess classification;- measured pairwise failure correlation for overlapping signatures;
- coverage/exclusion counts;
- negative/inconclusive candidates;
- utility-per-normalized-cost only where compute + human-attention fields are complete.
Decision rule for the next worker-scaling experiment: do not treat 3–5 worker fan-out as evidence-improving merely because two-worker execution is reliable. A diversity-motivated scale-up should wait for this frozen N=2 corpus to show
helps, or remain explicitly exploratory if the result isuncertain; if it showshurts, keep the replication baseline and investigate the measured confounders before increasing diversity.This narrows the uncertainty without adding a new controller, queue, schema, or analysis rule. It preserves the possibility that real diversity does not help.
A tight restatement for scanning. The quotation above is the authority; if the two ever differ, the quotation wins.
| element | rule | where it comes from |
|---|---|---|
| Hypothesis H1 | Two prospectively declared structural signatures beat two replication attempts from one fixed signature on independently verified success. | primary comment |
| Setting | swarm_size = 2, equal attempt budgets, same WorkUnit and source revision per task. |
primary comment |
| Decision statistic | Paired bootstrap on success_diverse - success_replication from the unchanged randomness_lab.r1_replay. |
primary comment |
helps |
Paired 95% interval entirely above 0. | primary comment |
hurts |
Paired 95% interval entirely below 0. | primary comment |
uncertain |
Otherwise. | primary comment |
| Primary confounder | Structural quality versus structural diversity: report per-signature marginal success next to pairwise failure correlation; never redefine signatures after outcomes. | primary comment |
| Secondary confounders | Verifier and model-family overlap, task difficulty, missing cost fields, inconclusive verification, unequal hidden-test coverage. | primary comment |
| Size target | At least 20 eligible real work units for the first bounded result. | primary comment; issue 70 body calls it “an experiment target, not a claim that 20 tasks provides universal statistical power” |
| 3 to 5 worker scale-up | Do not scale on reliability alone; wait for helps; stay exploratory on uncertain; keep the replication baseline and investigate confounders on hurts. |
primary comment |
| Not evidence for H1 | The same-patch smoke pair from the merged two-attempt end-to-end run. | primary comment |
| Not eligible | The original Phase B2 first-five pilot (burned; its outcomes are excluded from benchmark claims). | issue 70 comment 5455386108 |
Two requirements from the issue bodies shape what counts as eligible, and the readiness gate checks them: every analyzed candidate needs conclusive independent verification, and negative candidates must be retained. See the issue 70 body for the full minimum-corpus list.
These are gaps in the text as posted, not choices made here. Nothing below was resolved by this page, and none of it may be resolved after outcomes are seen.
randomness_lab.r1_replay defaults to 200 trials and
seed 42 and takes the 2.5th and 97.5th percentiles of the paired success
deltas. Those are facts about the code, not part of the registration. A
freeze should record the exact values used.verified_success_rate for the replication and
diversity arms and signature_failure_correlations (first-attempt failure
correlation per overlapping signature pair) but no per-signature marginal
success field, and r1_replay.py is left unchanged. The read-only
randomness_lab.r1_signature_marginals, described in
real-result replay, reads a saved replay report and
emits per-signature counts, success rate and a Wilson 95% interval, with the
correlations copied unchanged. It has been run on no real corpus: the
readiness gate (below) still reports 0 of 20 eligible work units. Whether its
output counts as part of the unchanged replay is still not stated by the
comment; it is a separate document bound to the report by digest.uncertain.helps” has no stated corpus condition. The text says the
frozen N=2 corpus must show helps but does not say whether that requires
the full 20 eligible units or any smaller helps classification.independent_from_worker truthfully.The readiness gate currently reports blocked. Run read-only on 2026-10-14
from the base commit of this page, writing nothing into results/:
python -m randomness_lab.r1_readiness \
--cohort benchmarks/phase-b2-successor-v2/cohort.json \
--baseline-signature single-worker-baseline-v2 \
--diversity-signature single-worker-baseline-v2 \
--diversity-signature role-specialized-two-attempts-v2
It exits 0 (a blocked report is valid output unless --require-ready is passed)
and prints status: blocked, evidence_class:
repository_contract_state_not_coding_outcome and supports_empirical_r1_claim:
false. Observed values:
| quantity | observed | required |
|---|---|---|
| cohort tasks | 5 | at least 20 prospectively |
| eligible work units | 0 | 20 |
| conclusive candidates after normalization | 0 | every analyzed candidate |
| cohort state | scaffold |
frozen or burned |
| committed definition digest | none | present before analyzed outcomes |
Every one of the five tasks is ineligible. The reported blockers on each are
cost_metrics_not_predeclared, evidence_not_verified, not_held_out,
seeded_negative_not_verified and unequal_or_unexpected_signature_budget; one
task also reports analysis_signatures_not_predeclared. These are collection
blockers, not experimental outcomes.
So there is no real R1 outcome, no helps, hurts or uncertain classification
on real data, and nothing here licenses scaling to 3 to 5 workers. The
readiness gate describes the checks, and its committed
current-state report
is the repository’s own record of this state.