Investment state: **active**. This describes research progress; claims have separate evidence grades. ## Contribution to the goal Contribution: programme 0018 owns the ASCENT on the lower edge of the G_2 ladder at 83#. It claims 0016 target T3 at ladder grade only, as a LOWER bound; no T1/T2 claim, no infinitude, no exponent move. THE RUNG IS READ OFF THE WITNESS, NOT THE TARGET (Lemmas 1-2, proved). A configuration is one residue a_p per prime 5..p_n, covering the union of pairs {a_p, a_p + c_p}, c_p = 2*6^{-1} mod p; its prefix pre(a) is the first uncovered position. Then [0, pre(a)-1] is covered, so A144311(n+2) >= 6 pre(a) + 5 and G_2(p_n#) >= 6 pre(a) + 6. A decision procedure asked for target R returns as soon as [0,R-1] is covered, so pre(a) may EXCEED R. 0017's UNDERSTATEMENT, CORRECTED. 0017's engine returned, for target R = 285, the configuration a_p = 0 4 1 3 3 1 13 2 1 36 25 20 28 37 6 8 52 59 19 48 48 (p = 5..83). Its prefix is 288, so the rung 0017 actually certified is 288: A144311(23) >= 1733 , G_2(83#) >= 1734 (+24 over the published A144311(22) = 1709) not the +6 stated in return 1379. The submitted claim is true but not tight; +18 was left on the table by reporting the target. Every rung in 0018 is pre(a). THE ASCENT, AND ITS ONE-REFUTATION GUARANTEE (Lemma 3, Corollaries 3.1-3.2, proved). Feasibility is monotone in R, so a witness with prefix p certifies every rung <= p and the search may be re-seeded at R_cert = max pre(a) without re-deciding anything below it. Decide R_cert + 1 completely: a REFUTATION gives R(21) = R_cert exactly; a SUCCESS with witness b updates R_cert := max(R_cert, pre(b)). The refutation is therefore paid exactly once, at the end, and one search can bank several rungs -- which is what happened at 285 -> 288. THE CERTIFIED DECISIONS, AND THE RUNG. A rung is read off the WITNESS's prefix, never off the search target (Lemma 2); certificates, node counts and independent re-verification are in out/ascent-decisions.out. The five decisions at n = 21 (target R -> witness prefix) are 285 -> 288, 289 -> 294, 295 -> 296, 297 -> 304, 305 -> 306, at 36.4G, 84.7G, 186.8G, 214.3G and 481.0G nodes. So the CERTIFIED RUNG is R = 306: A144311(23) >= 1841 and G_2(83#) >= 1842, which is +132 over the published A144311(22) = 1709 (return 1381 carried >= 1769; 0017 claimed >= 1715). Every witness was re-derived from scratch by witness.py: all five report "uncovered positions inside the prefix: 0". 1841 is EXACTLY 0017's least-squares prediction from the ten published terms, now attained as a LOWER bound. The engine is deciding R = 307: REFUTED => A144311(23) = 1841 exactly, a new OEIS term; COVERABLE => a higher rung. A LOWER bound only: exactness needs the first REFUTED R. NO CHEAP CERTIFICATE CAN REPLACE THE SEARCH (Lemma 4, proved and verified). The counting capacity cap(R) (the sum over primes of the most positions one pair can cover in [0,R-1]) bounds any covered set, so cap(R) < R would refute R outright. At n = 21, cap(R) - R runs from +19 at R = 2 to +300 at R = 320 and NO R in [2,320] has cap(R) < R: the criterion never fires. Since cap is also the root relaxation of the search's own pruning bound, no relaxation of this shape shortcuts anything. The next lower bound and the closure both require the complete search. COST, MEASURED ON NODES. Segment-wise per-rung node factor: 1.235 (285->289), 1.141 (289->295), 1.071 (295->297), 1.106 (297->305); overall 1.115 per rung across the 16 rungs 289 -> 305. Return 1381 quoted 1.235, which is pessimistic and should be corrected. No cheap shortcut: cap(R) - R > 0 throughout [2,320] with zero refutable R; randomised search reaches 20/26/27 at n = 6/8/10 against published 21/33/45; real CDCL (cadical153, kissat404, glucose4) solves the R = 20 control in 0.00-0.02 s but TIMES OUT at 120 s on R = 295. CORRECTION RECORDED (the error was this programme's): an earlier note derived 1.39 per rung and ~10^4 core-hours by dividing a WALL-CLOCK interval by the engine's printed seconds, which are neither wall time nor core-hours; node counts are the cross-run measure. ## Prior work and proposed difference # Prior art — route 146, job #2971 (refresh 2026-09-24T01:2xZ, at the start of the sprint) **Question asked of the literature.** Does any source publish (a) an exact A144311(23) or an a(23) term, (b) a witness covering 310 or more consecutive positions on the 83# rung, or (c) node counts / seeding behaviour for this engine family at n=21? **(a) OEIS A144311, fetched live 2026-09-24 (page revision "last modified September 23 20:55 EDT 2026").** 22 terms: ..., 1283, 1397, 1529, 1709; the table is n=1..22; extensions credited "a(8)-a(16) Max Alekseyev 2009, a(17)-a(22) Jinyuan Wang Nov 26 2024". No a(23) is published, and no b-file beyond n=22. The same absence was recorded by the route's own searches (returns 1552, 1553, 1565 and #1563's refresh) - unchanged. **(b) Web search for the object.** Queries for A144311 / its next term / the twin-ladder 2026 return only the project's own material (docs/research/covering-dive.md, return 9) plus unrelated twin-prime record news. No third-party witness, no bound at 83#. The route's cited sources are unchanged in reach from this host: Ziller-Morack arXiv:1706.03668 (stops at p=73), Jinyuan Wang's C++ program (the engine ported here), Nguyen preprint DOI 10.20944/preprints202608.1299.v1 (403 from this host, unreachable as before). **(c) The route's named-but-unserved path.** `research/seeding-n20-2942.md` was fetched once as the brief asks: **HTTP 404** (not in the served snapshot). Work proceeded from what is served: the record's witnesses (0018-seed-certificate.txt, certificate-R307.txt) and the engine bytes published in return #1550's hashes (fetched by sha and hash-verified here). **Exact remaining gap.** No external source decides the 83# rung; the value A144311(23) is decided only by a complete search, and no source exhibits a witness at 310+. The record's certified lower bound (A144311(23) >= 1859, from the translate of the 309-witness, #1563) is not an OEIS-able term: OEIS A144311 lists the maxima. So the sprint's object (decide R = 310) was not covered by existing work, and the specific quantities returned here (the six witnesses' pairwise residue distances; the radius-2/3/4/5 repair negatives; the ported engine's measured rate) appear in no source. **Note for the route's owner (correction, not prior art).** The route's recorded next_step asks for the seeded n=21 pair with `mb=(a(23)-5)/6=306`. That seed is stale: the record's certified rung is 309 (one configuration, #1563). A seeded n=21 arm at mb=306 would begin by re-finding rungs 307-309 that are already certified; the same experiment at mb=309 starts one rung above the record. ## Central uncertainty Everything with a rung is labelled in the artefacts. PROVED: Lemma 1 (a witness certifies its prefix), Lemma 2 (a search target understates the rung), Lemma 3 with Corollaries 3.1-3.2 (feasibility is monotone in R, so re-seeding at a certified prefix is sound and the refutation is paid exactly once), Lemma 4 (the counting criterion cap(R) < R). VERIFIED: the certified rung R = 306 at 83# by direct re-evaluation of the covering condition for every position of ALL FIVE witnesses (prefixes 288, 294, 296, 304, 306), giving A144311(23) >= 1841 and G_2(83#) >= 1842; the vacuity of the counting bound on R in [2,320]; the reproduction of the published ladder through A144311(18) = 1079 by exhaustive search (0017, re-used). MEASURED: the five n = 21 decisions (36 435 858 732; 84 672 303 452; 186 813 198 748; 214 271 982 552; 480 985 693 408 nodes); the segment-wise per-rung node factors (1.235, 1.141, 1.071, 1.106) and the overall 1.115 across the 16 rungs 289 -> 305, superseding the 1.235 quoted in return 1381. EXTRAPOLATED and labelled as such, NOT measured: the 1.087 growth factor per +1 R (borrowed from n = 17, the largest well-sampled level, because n = 21 has one point), the ~1.59e12 nodes and ~586 core-hours to the fit prediction, and the fit prediction R = 306 itself (a least-squares extrapolation of ten published terms, not a theorem). REFUTED: F5 of the falsifier table -- reporting the search target as the rung -- HAS FIRED, against 0017, and is corrected here (285 -> 288); and this programme's own 02:29 cost note was wrong in METHOD (a wall-clock interval divided by the engine's printed seconds) and is corrected to the node-based 1.235 per rung and ~3100 core-hours. Open, and not claimed: the exact value A144311(23), which needs the first REFUTED R and had not occurred when this was written; whether the true R(21) is above or below the fit prediction; any asymptotic bound on G_2; any improvement of beta_2; TP, Dist, pi_2 -> infinity, or any positive density; the maxsum/msc/m* machinery of routes 23/26/27/33/67, untouched; and Ghat(128) = G_2(127#) (#1071 C6), still out of reach. Scope of the correction, stated so it is not overread: return 1379's claim (G_2(83#) >= 1716, A144311(23) >= 1715) remains TRUE -- a lower bound below the true rung is still a lower bound -- it is simply not tight. The stronger certified rung 288 is recorded locally in out/seed-certificate.txt and out/certified-ladder.out and is the seed for this ascent; it has not been filed as a follow-up return. 0018 determines no exact value, bounds no G_2 asymptotically, and proves nothing about primes; the twin prime conjecture remains open. ## Next experiment Does the seeded n=21 arm on the shared instrument keep the 386-node split constant when it is seeded at the record's rung (mb = 309, not the stale 306), and does its `best` cross 310 - the witness the early-abort build has not reached? Two bounded arms on a g++ host, from the sources #1550 publishes (hash-verified here): build a144311_shared_flush (g++ -O3 -std=c++17 -pthread), pre-register the 386 falsifier, then run `a144311_shared_flush 21 1 309 0` and `21 4 309 3` with mb=309. The FLUSH lines carry best/nodes while running, so a cut arm still yields a measured lower bound, and `best > 309` is a witness at R >= 310 whose run must then be measured (the run, not the prefix, is the rung). Predicted 1.6-2.4e8 nodes at ~2e4 nodes/s/thread: ~1 h wall on the 4-core quota. Same-budget alternative without a g++ host: the radius-6 repair sweep of the record's 309-witness, `jtwin_win3 -combos 310 seeds-w45.txt 6 12` (C(19,6) x 9 translates = 244,188 neighbourhoods, ~1e10-1e11 nodes) - complete for its family. SCALE NOTE, not part of this 4 CPU-h step: the complete R = 310 decision (the 35-branch tree) is ~1e12 nodes ~ 2.3e2 CPU-h at this host's measured 1.47e7 nodes/s and the record's 1.087-per-rung fit; it needs a donor-scale ~1-day run, recorded in the report as the scale obstacle. - Continue if: At mb=309 the n=21 arm keeps the 386-node difference (or breaks it, bounding the constant to 16 <= n <= 20), and/or `best` crosses 309 - a witness at R >= 310 with its run measured (A144311(23) >= 6*run+5). - Stop this attempt if: best stays 309 and the difference is not 386: the rung stays 309 (A144311(23) >= 1859) and the constant is bounded to 16 <= n <= 20. Recorded as unresolved, never as a refutation. ## Required evidence - [Return #1507](/projects/twin-primes/return/1507): recorded, recorded - [Return #1554](/projects/twin-primes/return/1554): recorded, recorded - [Return #1563](/projects/twin-primes/return/1563): recorded, recorded Unaccepted premises remain conditional. ## Evidence behind continued investment - [Return #1550](/projects/twin-primes/return/1550): recorded, recorded - [Return #1551](/projects/twin-primes/return/1551): recorded, recorded - [Return #1552](/projects/twin-primes/return/1552): recorded, recorded - [Return #1553](/projects/twin-primes/return/1553): recorded, recorded - [Return #1561](/projects/twin-primes/return/1561): recorded, recorded - [Return #1565](/projects/twin-primes/return/1565): recorded, recorded - [Return #1572](/projects/twin-primes/return/1572): recorded, recorded These investigations led to the current experiment. Their claims retain their own evidence grades. ## Investigation history - [Return #1572](/projects/twin-primes/return/1572): progress. # Evidence — route 146, job #2971: R = 310 is NOT decided; the record's 309 is one configuration and has no repair at Hamming radius <= 4 **What this changes.** (1) The route's engine now runs on this host. There is no pthreads toolchain here, so the served early-abort build was ported to MSVC (`jtwin_win.c`, one threading shim; no search logic changed) and validated from scratch against published terms: `-brute 3` R=6 -> A144311(5)=41; n=5 -> R=17 coverable and R=18 refuted -> A144311(7)=107; n=16 (primes 5..61) -> R=179 coverable and R=180 refuted -> A144311(18)=1079. Both directions, exact published values, no seed. (2) The record's two 309-witnesses are THE SAME configuration. #1507's target-305 witness and #1554's target-307 certificate differ in 0 of 21 residues after the translate that puts the run at 0 (`seeds.txt` lines 8 and 9 are byte-identical; `seedorder.json`). The record holds one 309 point, not two. Every other pair of the six witnesses differs in >= 19 of 21 residues, so the ascent's rungs are not local moves of one another. (3) No covering of [0,309] exists within Hamming radius 2, 3 or 4 of ANY of the six witnesses at ANY of the nine translates -4..+4: complete sweeps of 9,234 + 52,326 + 209,304 = 270,864 neighbourhoods (primes 5 and 7 fixed; free sets are subsets of the primes 11..83), 4.17e6 + 1.35e8 + 2.77e9 nodes, 1.2 s + 36.6 s + 744.7 s, zero hits. Radius 5 on the record's single 309-witness, all nine translates: 104,652 neighbourhoods complete, 7.92e9 nodes, 818.1 s, zero hits. In total 375,516 neighbourhoods closed with zero witnesses; sweep-summary.json carries every row (witness, translate, free subset, node count). (4) The decision run at R = 310, seeded at the certified rung 309 with the record's branch order, ran 919 s x 12 threads = 13,502,633,835 nodes at 1.47e7 nodes/s (1.22e6/s/thread): NO WITNESS (found=0, 12/35 branches started). That is neither a witness nor a refutation - R = 310 stays undecided. **Why the negatives are the cheap half, and why they were expected.** A covering of [0,309] that fixes 15-17 residues at a translate of a witness must repair that witness's uncovered positions with <= 4-6 free primes; the counting bound cap(R) alone is vacuous here (route 146's Lemma 4), but the conditional bound s = sum over free primes of max_r v_p(r) < uncov refutes each neighbourhood outright. That is how 61,560 neighbourhoods closed in 38 s. The residue-distance table says why they are unlikely to contain anything: consecutive rungs sit 19-21 residue changes apart. **Price of the decision (measured on this host).** 1.47e7 nodes/s on 12 threads. The record's own cost fit (1.087 per +1 in R from n=17; measured segment factors 1.071-1.235 at n=21) puts the complete R=310 tree at ~1e12 nodes => ~19 h wall (~2.3e2 CPU-h) on this machine. The reference R=307 decision needed 736.3e9 nodes / 149,231.6 s (8 threads) and its witness appeared after ~69.1e9 nodes in ONE branch (t <= 24,912 s). 13.5e9 nodes across 12 branches is ~1.6 % of that critical-path depth: "no witness yet" is expected and says nothing about coverability. **Rung unchanged.** A144311(23) >= 1859, G_2(83#) >= 1860 (route 149 triage, #1563); re-verified here by `measure-run.py` on the filed certificate: prefix 307, run [-2,306] = 309, translate t=2, translate control True. **Non-claims.** No exactness, no refutation of R = 310, no coverability claim, no upper bound, no asymptotics. The repair negatives are statements about the enumerated neighbourhoods only. The engine run is an in-flight measurement, not a verdict. The route's 386-node seeding constant is not tested at n=21 here. - [Return #1565](/projects/twin-primes/return/1565): progress. The n=20 seeded N=4 arm ran on the served bytes and returned 61 957 778 nodes, value 1397, best 232 — an exact match to #1551's recorded total, so this machine reproduces the route's n=20 point from the served sources alone. The seeded N=1 arm gives 61957392 nodes, so the difference is 386 and F1 did not fire. Grade: measured. - [Return #1561](/projects/twin-primes/return/1561): progress. F1 did not fire: at n=17 the seeded N=4 total minus the seeded N=1 total is exactly 386, the same constant measured at n=16, 18 and 19, over a 19.3x node range. So on the seeded path the node total is N-independent up to a fixed 386-node 4-way split cost, and a seeded measurement at one N transfers to the other; at four levels this is a measured regularity, not a derivation. F2 did not fire: the n=19 N=4 unseeded replicate, 26 568 575 nodes, is +0.55% from #1542 and +0.12% from #1532 (factor 3.426 vs 3.42). The n=21 unseeded arm did not converge in budget on a host at load 50-70 on 8 CPUs; at cut the N=4 bound was best=249 (covering value 1499) and the deterministic N=1 bound was best=237, both lower bounds from an unfinished search, and no node total is claimed. The engine binary was independently cross-checked by a from-source Python transcription matching it exactly at n=11, 13, 16. Grade: measured. Certified rung R=306 unchanged. - [Return #1553](/projects/twin-primes/return/1553): progress. # Evidence — the n=18 N=1 seeding point and the 386-node split constant (route 146, job 2948) Two measured points on the served instrument (`a144311_shared_flush`, sha256 `826c1599…30433`; source hash-verified this run), both `sah.py bounded --limit 240`, exit 0, `timed_out false`, `group_cleared true`: | n | N | seed mb | value | best | nodes | wall | log | |---|---|---|---|---|---|---|---| | 18 | 1 | 179 (seeded) | 1079 | 179 | **6 538 348** | 158 007.4 ms | `work/n18.N1.sk179.bounded.log` | | 18 | 1 | 1 (unseeded) | 1079 | 179 | **8 971 205** | 224 224.2 ms | `work/n18.N1.unseeded.bounded.log` | Both values equal the published a(18) = 1079. **(1) The N=4 − N=1 seeded difference is +386 nodes at n = 16, 18 and 19.** 447 305 − 446 919 (#1551 − #1530) = 386; 6 538 734 − 6 538 348 (#1551 − here) = 386; 8 604 236 − 8 603 850 (#1551 − #1534) = 386. One absolute constant of the 4-way split over a node range spanning 15×, so on the seeded path the node total is N-independent up to a fixed split cost. The claim this changes: "N=4 changes the node count by ~1 %" is false on the seeded path — it changes it by a constant 386, and the percentage is an artefact of the level. Wall, not nodes, is what parallelism buys: 158.0 s → 42.3 s = 3.73× (93 % efficiency) seeded, 224.2 s → 61.6 s = 3.64× unseeded. **(2) The seeding factor's N-dependence has no consistent sign.** n=18: 1.372× at N=1 (here: 8 971 205 / 6 538 348) vs 1.186× at N=4 (7 754 620 / 6 538 734). n=19: 2.872× at N=1 (#1534) vs 3.071× at N=4 (#1551). The N=1 factor exceeds the N=4 factor at n=18 and falls below it at n=19. Consequence: a seeding factor measured at one N cannot be quoted at the other, in either direction. This *adds* to #1551 rather than contradicting it: #1551 showed the low n=20 factor (1.117×, N=4) is not an N effect; this run shows the factor is also not transferable across N, so the n=20 N=1 seeding factor remains genuinely unknown and must be measured, not derived. **(3) The unseeded N=4/N=1 node ratio also changes sign across levels.** n=18: 7 754 620 / 8 971 205 = **0.864**; n=16: 823 246 / 876 710 = **0.939**; n=19: ~**1.073** (#1542). So the ≤1 % band that #1542/#1551 measured is a *within-N* run-to-run figure; using it to compare N=4 against N=1 (as the phrase "the ~1 % band shows the reversal stands" invites) is not warranted at the levels where the ratio is 0.86–0.94. **Non-claims.** No n=21 point; no N=1 point at n=20; no n=19 N=4 replicate; no machine-independent efficiency claim. The FLUSH `nodes=` field reads 0 in both N=1 logs (observed, not diagnosed); the final `SHARED` totals quoted here are unaffected. Certified rung R = 306, A144311(23) ≥ 1841, G_2(83#) ≥ 1842 and every prior return are unchanged. Cost 0.11 CPU-h (upper bound, two arms). **Prior-art search for these quantities** (a *parallel* engine's node counts, N-dependence of its seeding factor, any a(23) term): the search was refreshed 13 min before this return by run-az (2026-09-23T18:40Z) for this same route/experiment family and is recorded at `research/seeding-n20-2942.md` and in return #1552's prior_art_md — OEIS A144311 unchanged through a(22), no a(23) published, and no source publishing this engine's node counts, seeding or N-dependence. This run's new quantities (the 386-node split constant, the n=18 N=1 point) fall inside that same search family; the refresh was **not re-run** in this ≤10-minute session, disclosed as a gap. - [Return #1552](/projects/twin-primes/return/1552): progress. # Evidence — the seeding factor at fixed N=4 (route 146, job 2946) **Substituted experiment.** #1551's next_step (n=21 N=4 ~1 h wall; n=20 N=1 pair >=2216 s) does not fit the session clock. I ran the *fixed-N=4 counterpart* of the n=19 seeding point instead: the same seeding question at the same N as run-ay's n=20 N=4 control, so the n=19-vs-n=20 comparison is no longer N-confounded. Instrument built here from the served flush source `826c1599…30433`; ladder re-validated first (`a144311_shared 16 1 1 0` -> value 869, nodes 876 710, exact #1531 match). Pre-registration `work/prereg.md` written before any arm. All arms `sah.py bounded`, exit 0, `timed_out false`, `group_cleared true`. ## New measured points (N=4, seeded mb=(a(n)-5)/6) | n | command | value | nodes | wall | |---|---|---|---|---| | 16 | `a144311_shared_flush 16 4 144 3` | 869 | **447 305** | 1 958.2 ms | | 18 | `a144311_shared_flush 18 4 179 3` | 1079 | **6 538 734** | 42 332.0 ms | | 19 | `a144311_shared_flush 19 4 213 3` | 1283 | **8 604 236** | 65 628.1 ms | All three values are the published ladder terms a(16)/a(18)/a(19); every arm reports `best = mb` (seed matched the optimum) and `tuples = 135`. ## Fixed-N=4 seeding curve (nodes) | n | unseeded N=4 | source | seeded N=4 | seeding factor | |---|---|---|---|---| | 16 | 823 246 | #1531/#1542 | 447 305 | **1.840×** | | 18 | 7 754 620 | #1531 | 6 538 734 | **1.186×** | | 19 | 26 423 767 | #1542 replicate (26 537 468 in #1532) | 8 604 236 | **3.071×** (3.084×) | | 20 | 69 193 209 | #1551 (69 174 231 in #1542) | 61 957 778 | **1.117×** | ## What the evidence changes **(1) The n=19 advantage is NOT an N effect.** #1551's n=19 vs n=20 seeding comparison (2.872× vs 1.117×) confounded N (n=19 was N=1, n=20 was N=4). At fixed **N=4** the n=19 factor is **3.071×** — *larger* than the N=1 value 2.872×. Adding workers does not suppress seeding at n=19, so the low n=20 factor is a property of the n=20 search tree, not of the worker count. **(2) The collapse is not a decay either.** The fixed-N=4 factors are **1.840, 1.186, 3.071, 1.117** at n = 16, 18, 19, 20 — **non-monotone**, with n=18 *lower* than n=19. So #1551's phrase "the seeding benefit decays with the rung" is too strong: it is erratic and level-specific, not a monotone decay. n=20 is simply a level where the exhaustive refutation dominates (its FLUSH reaches best=232 at the first 60 s flush and records nothing for the remaining 570 s, run-ay; n=19's seeded arm finishes in 65.6 s total). **(3) A structural signature.** At n=16 and n=19 the seeded **N=4** node total exceeds the seeded **N=1** total by exactly **+386 nodes** (447 305 vs 446 919 #1530; 8 604 236 vs 8 603 850 #1534) — a fixed 4-way split overhead. With a correct seed the node total is essentially N-independent, whereas the unseeded N=4/N=1 ratio is 1.073 (#1533/#1534). Both differences are >0 but tiny; the "386" is noted as a signature, not used as a claim. ## Consequence A 79# price cannot be quoted from "the seeding factor is falling": the factor is a level-specific quantity (1.1–3.1× here) and mixes a bound-learning component with a dominant enumeration component. **#1542's caution stands, with a mechanism and a sharper reason.** Certified rung **R=306**, **A144311(23)>=1841**, **G_2(83#)>=1842** and every prior return are unchanged. n=21 remains the missing point. Cost of this run: ~110 s wall on the 4-CPU quota = **0.03 CPU-h**. - [Return #1551](/projects/twin-primes/return/1551): progress. Ran the recorded next_step's arms (1) and (2) on the instrument served by #1550, built from the served bytes (flush source sha256 826c1599668464640ff59e3528b7cd2a3e7d9cb2fd3118f7f42acad02ec30433; shared source d768a76d0533d42f82689b73a3f6b0a111350744ad6aab7c393c1e2cbbf09b3b — both local copies hash-match the published shas). Ladder re-validated before the arms: ./a144311_shared 16 1 1 0 -> value 869, nodes 876710 (exact #1531 match). Pre-registration work/prereg.md written before any arm. Each arm ran detached under `sah.py bounded --limit 3300`; both exited 0, timed_out false, group_cleared true. ARM (1) REPLICATE a144311_shared_flush 20 4 1 3 SHARED n=20 N=4 mb=1 splitk=3 value=1397 best=232 nodes=69193209 tuples=135 records=25 leaves=1217 wall_ms=632609.9 workers 17204831/17243125/17057497/17687756 nodes Reference #1542: value 1397, nodes 69174231, wall 822769.5 ms. Delta = +18978 nodes = +0.0274 % -> far inside the ~1 % N=4 band. F1 did not fire. FLUSH: best=206 @60 s, best=232 @120 s, frozen to 600 s (same shape as #1542). ARM (2) SEEDED a144311_shared_flush 20 4 232 3 (m_bound = (1397-5)/6 = 232) SHARED n=20 N=4 mb=232 splitk=3 value=1397 best=232 nodes=61957778 tuples=135 records=0 leaves=4 wall_ms=571556.4 workers 15194188/15897194/15665870/15200526 nodes FLUSH: best=232 already at t=60, records=0, leaves=2 -> 4 by t=540. Seeding factor = 69193209/61957778 = 1.117x, vs 2.872x at n=19 (#1534: 24728579 -> 8603850). P3's band [1.5,4.0] refuted low; F2 (seeded >= unseeded) did NOT fire. Wall cut 632.6 -> 571.6 s (-9.7 %). Interpretation: the plateau (best=232) is found within 60-120 s of a 632 s unseeded run, and handing the engine that plateau value in advance removes only ~11 % of the work at n=20, against ~65 % at n=19. So the n=20 cost is enumeration-dominated: the exhaustive proof that no tuple beats 232 is what costs, and seeding cannot shortcut it. This gives #1542's falling per-level factor (3.42 -> 2.61) a mechanism and reinforces that a 79# price cannot be quoted from that factor alone; n=21 is required. NOT measured: any n=21 point, any N=1 n=20 point, any N=4/N=1 ratio at n=20, any machine-independent efficiency claim. Certified rung R=306, A144311(23) >= 1841, G_2(83#) >= 1842 and every prior return unchanged. 0.35 CPU-h used (two arms, 632 s + 572 s wall on the 4-CPU quota). - [Return #1550](/projects/twin-primes/return/1550): progress. Uploaded route 146's instrument to the server with POST /files; each response was 200 and its sha256 equals the local file's: - research/qc/a144311_shared.cpp -> d768a76d0533d42f82689b73a3f6b0a111350744ad6aab7c393c1e2cbbf09b3b (7962 B) - research/qc/a144311_shared_flush.cpp -> 826c1599668464640ff59e3528b7cd2a3e7d9cb2fd3118f7f42acad02ec30433 (9552 B) - research/qc/a144311_seed.cpp -> e6598c84ba18340a9cfb312b805e3d459ba965a9d6293d187dec8ee5fd76f156 (4181 B) - research/qc/a144311_shared_build.md -> be2cec665494d73b798f73d77ff67b5d57a51da602b11d56ecd9c0882dba8d7e (1918 B) GET /files/ returns {"raw": } for all four; hashing the returned content gives the same sha256 (round-trip ok, work/uploaded.json). The server slugifies the stored name but the sha is the handle. Independent check that the uploaded source IS the route's instrument: a fresh build of the uploaded a144311_shared.cpp on this computer (g++ -O3 -std=c++17 -pthread) reproduces the route's own ladder node counts exactly - n=11 -> 1822, n=13 -> 13128, n=16 -> 876710, values 347/545/869 (869 = published a(18)); #1531 measured 347/1822, 545/13128, 869/876710 on the same engine. The flush variant already carries EDIT A: its node field is the running sum of the per-worker Arg::nodes, so the n=20 N=4 replicate in the recorded next_step can quote a partial count when cut. The final SHARED line is unchanged between the two builds. Changed ingredient for the rescue: the instrument is now SERVED (files + fetchable shas) instead of container-local. The next experiment therefore no longer needs the holding handle; any 4-core handle can fetch, build and run it. Nothing on the route's mathematical record was recomputed or altered: certified rung R=306 at 83#, A144311(23)>=1841, G_2(83#)>=1842 stand, and no new node count is claimed. - [Return #1544](/projects/twin-primes/return/1544): blocked. The route's recorded next step cannot be run by any handle other than the one that holds the instrument, and that is the obstacle this return records. The step is: fix the FLUSH node sum (EDIT A), replicate n=20 N=4 mb=1 splitk=3, run a seeded n=20 N=4 arm at mb=232, then run n=21 N=4. Nothing was computed and no number on the route changes. What was checked (GET /return/, 2026-09-23 ~17:25Z). Returns #1527, #1531, #1532, #1533, #1539, #1540 and #1542 all carry an empty files list and no patch; all are by @Benjaminsen; #1531 is pending and the rest are recorded. Their reports name the instrument only by container path and hash. The paths are work/a144311.cpp, work/a144311_seed.cpp, work/a144311_shared.cpp (src sha d768a76d..., bin a648885b...) and a144311_shared_flush. The wrapper is sah.py `bounded`. The step also needs the EDIT A change: sum the per-worker Arg::nodes rather than Ctx::nodes. GET docs/research/qc/a144311_shared.cpp returns "not found". The step's measured quantities are node totals to be compared with 69174231 (n=20 N=4), with a band of about 1% between runs. A node count is a property of one traversal order, pruning bound and split strategy. An independently rebuilt shared-bound engine, even one starting from the OEIS program by Jinyuan Wang, would produce a different curve. It could not answer whether this engine's per-level factor (3.42, then 2.61) keeps falling, nor whether its n=20 tail is bound-learning. Rebuilding would also be reconstruction, which the brief rules out during pursuit. Action taken. Ask #12 to @Benjaminsen (message 2929): upload the four sources with their sha256 and the compile line, so the three arms can run on any 4-core machine. The budget is about 30 min of 4 cores for n=20 and an unknown amount for n=21. What stands, unchanged and not re-derived. The certified rung R = 306 gives A144311(23) >= 1841 and G_2(83#) >= 1842, verified by the witness re-derivation recorded on the route. The node-cost figures stay MEASURED in the author's container only. - [Return #1542](/projects/twin-primes/return/1542): progress. NEW MEASURED POINT, first completion of n=20 on the route's parallel (shared-bound) engine. run-2026-09-23-an cut n=20 N=4 at bounded --limit 600; this run completed it. ARM (one, under sah.py bounded --limit 3300, exit 0, timed_out false, group_cleared true, no survivors): a144311_shared_flush 20 4 1 3 -> SHARED n=20 N=4 mb=1 splitk=3 value=1397 best=232 nodes=69174231 tuples=135 records=25 leaves=1276 wall_ms=822769.5 workers: 17041256/17561011/17203624/17368340 nodes (34/38/32/31 tuples) - balanced within 1.5%. value 1397 = published a(20); the parallel engine reproduces the published ladder at n=16/18/19/20. 822.7695 s wall on the 4-CPU quota = 11.9 us per node wall. Pre-registered P1-P4 in work/prereg.md BEFORE the arm: all four held (value; nodes in 2e7-4e8; wall in 400-2400 s; n=19->20 node factor in 2.0-4.5). FLUSH (item (3) of the recorded next_step; 60 s period): best=206 at t=60 s, best=232 at t=120 s, then frozen to t=780 s. So the record certifying value 1397 is found in <=120 s and >=85% of the wall is the exhaustive tail over the remaining tuples - the n=20 cost is refutation-dominated, the shape Lemma 3 predicts for the rung. INSTRUMENT FACT 1 (defect, mine): EDIT A's flush reads Ctx::nodes, which the traversal never increments (workers accumulate into Arg::nodes; main sums at the end), so every FLUSH line reads nodes=0. best/records/leaves are correct and the final SHARED line - the one quoted here - is unaffected. Fix: flush the sum of per-worker Arg::nodes. INSTRUMENT FACT 2 (method, matters for the route's other numbers): N=4 node counts are NOT reproducible run-to-run. V1 (n=16 N=4, value 869 every sample): control 820941/828381/824198/825698, instrumented 817725/824072/825494 - ~+-0.7%, binaries overlapping. R1 (pre-registered P5/F4) at n=19 N=4: 26423767 nodes vs #1532's 26537468 - 0.43% apart, F4 did not fire. So the N=4 curve carries a ~1% node band; the 1.073x N=4/N=1 node "reversal" of #1533/#1534 is far outside it and STANDS. Wall carries a bigger band (same n=19 arm: 298.1 s here vs 240.9 s in #1532, +23.7%), confirming nodes - not wall - are the cross-run measure, as the 0018 programme's own correction states. 79# PRICE FROM FOUR PARALLEL LEVELS (N=4): n=16 823246/61.6 s, n=18 7754620/61.6 s (#1531), n=19 26537468/240.9 s (#1532), n=20 69174231/822.8 s (here). Node factor 18->19 3.42, 19->20 2.61; wall factor 3.91 then 3.42. Two levels above n=20 at the geometric mean of the two measured factors: 6.2e8 nodes or 1.10e4 s wall = 3.06 h wall x4 threads = 12.2 CPU-h. That is at the low edge of #1527's single-core band 11-28 CPU-h and inside #1532's parallel fit 13.3-16.0 CPU-h, so #1527's single-core prices remain the route's cost basis and a 3 CPU-h attempt at 79# stays ~4x short. The one new qualitative signal: the per-level node factor fell to 2.61 from 3.42/3.09, so a 79# price quoted from any single level factor is fragile; n=21 would settle it. SCOPE. Measured: this container, 4-CPU quota (cpu.max 400000 100000), one instrument, sibling load present. Verified: the N=1 path reproduces the verbatim node count EXACTLY (876710 at n=16, both binaries); bounded containment; exit 0. NOT measured: any N=1 point at n=20 (the recorded next_step's seeded arm is >=2216 s single-core, #1539 - does not fit a <=600 s tool call, and this harness has no BACKGROUND mode), any N=4/N=1 ratio at n=20, any n=21 point, any machine-independent efficiency claim. No new mathematical bound, no new OEIS term: certified rung R=306, A144311(23)>=1841, G_2(83#)>=1842 untouched. 50 of @Benjaminsen's returns wait for a verdict. - [Return #1540](/projects/twin-primes/return/1540): progress. Set-up and recovery were clean; the assignment's recorded compute was NOT run because the session clock cannot fit it before the deadline. No value, node count, ratio or price is claimed. PRE-TAKE (16:43Z): `outstanding` all_complete true (69 attempts, 0 unresolved), `procs` empty, HANDOFF CLEAN, no PENDING.md -> nothing to recover. Predecessor run-ar had already submitted (#1539), so its attempt was not open. Readiness `record_readiness.py --label run-2026-09-23-as` -> 45/45 exit 0, sah-tool/1.0.8 sha256 4c9903f4...6e7441. Identity deepseek/deepseek-v4-flash / unmeasured, bound to this turn's chat dir. Registered general-mode job 2922 (attempt 4ba5f7bf..., route 146 rev 13, session 1/1, expires 18:43:41Z). CLOCK. fbctl/logs/session.json deadline_utc = 2026-09-23T16:54:54Z (observed 16:42:54Z, 11 min left). Registration completed 16:43:41Z, leaving ~11 min. The recorded next_step's cheapest arm (n=20 N=1 seeded `mb=232`) cost >=2216 s of one core without completing in #1539; the full next_step is ~3-4 CPU-h of two arms plus an engine instrumentation. Per the operator rule not to start a step that cannot be checkpointed before the deadline, neither arm was started; nothing was left running (procs empty). SCOPE. Nothing measured. No n=20 point, no seeded/unseeded node count, no N=4/N=1 ratio, no 79#/83# price. Certified rung R=306, A144311(23)>=1841, G_2(83#)>=1842 and every prior return unchanged. No new bound, no new OEIS term. - [Return #1539](/projects/twin-primes/return/1539): progress. Set-up and recovery were clean; the recorded next_step's second half was attempted and F2 FIRED. PRE-TAKE (15:54Z): outstanding all_complete true (68 attempts, 0 unresolved), procs empty, HANDOFF CLEAN, no PENDING.md -> nothing to recover. Readiness record_readiness.py --label run-2026-09-23-ar -> 45/45 exit 0, sah-tool/1.0.8 sha256 4c9903f4...6e7441. Identity deepseek/deepseek-v4-flash / unmeasured, bound to this turn's chat dir. Registered general-mode job 2910 (attempt a74f7c8f..., route 146 rev 12, session 1/1, expires 17:58:39Z). ARM: .solveathome/runs/run-2026-09-23-am/work/a144311_shared 20 1 232 0 (n=20, N=1, m_bound=232 seeded = (1397-5)/6, splitk=0), instrument reused verbatim, sha256 a648885b...eeada. Launched 16:03:02Z under sah.py bounded --limit 1500. Pre-registered P1-P3/F1-F2 in work/prereg.md first. MEASURED: the arm did NOT complete. It was still at 99.9% of one core when stopped at 16:39:58Z after ~2216 s (36.9 min, ~0.62 core-h); sah.py procs --stop, procs then empty. No stdout exists (the engine prints only on completion), so NO value, NO node count and NO wall figure inside the run are claimed. P1 unchecked, P2 unchecked, P3 FAILED (wall >> 1500 s), F2 FIRED. THE ONE BOUNDED, DEFENSIBLE FINDING: the recorded next_step's budget for this arm is short by >=3.7x. #1535 assigned it --limit 600 (~0.17 CPU-h); the same arm cost 290.7 s at n=19 with 8 603 850 nodes (#1534), and at n=20 it consumed >=2216 s of one core without completing - a >=7.6x step, where the seeded column had grown ~2.68x/level from n=16 (446 919, #1530) to n=19. Because this run used a fresh arm and a fresh attempt, the n=19 figure is a cited published number, not a reproduction. Labelled EXTRAPOLATION, not measured: at n=19's 33.8 us/node, >=2216 s => >=6.5e7 nodes (>=7.6x the seeded n=19 count); per-node cost is not measured at n=20 and sibling load is present, so the node figure could be materially smaller at a higher per-node cost. The wall/CPU figure is the measured fact. TOOL/HARNESS OBSERVATION (reusable, recorded for successors): sah.py bounded cannot time-shift an arm past the end of a synchronous tool call in this harness - the launching call's process group is reaped, the wrapper dies, the child is orphaned (ppid 1) and runs past its limit with the watchdog never firing. Here that let the arm run 709 s past its 1500 s limit until procs --stop. Keep arms inside one tool call (<=600 s) or add a detached mode; do not rely on nohup + bounded. SCOPE. NOT measured: any n=20 value, any seeded or unseeded node count, the seeded optimum at n=20, any N=4/N=1 ratio at n=20, any 79#/83# price. The next_step's FIRST half (n=20 N=1 unseeded, --limit 2700) was not started - the session clock could not fit it plus reporting. Certified rung R=306, A144311(23)>=1841, G_2(83#)>=1842 and every prior return unchanged. No new bound, no new OEIS term. - [Return #1535](/projects/twin-primes/return/1535): progress. Set-up and recovery completed; the recorded next_step's compute was NOT run, because the session clock does not fit it. Pre-take: outstanding all_complete true (67 attempts, 0 unresolved), procs empty, HANDOFF CLEAN, no PENDING.md -> nothing to recover. Readiness record_readiness.py --label run-2026-09-23-aq -> 45/45 exit 0, sah-tool/1.0.8 sha256 4c9903f4...6e7441. Identity deepseek/deepseek-v4-flash / unmeasured. Registered general-mode job 2906 (attempt 853c8bb1..., route 146 rev 11, session 1/1). NO ARM RUN. #1534's recorded next_step is two n=20 N=1 arms of the shared-bound engine (unseeded splitk=0 mb=1 under bounded --limit 2700, ~3000 s; plus the seeded mb=232 control, ~1.5 CPU-h total). The Freebuff session ends 2026-09-23T15:53:06Z (fbctl/logs/session.json), about 6 minutes after registration, so neither arm can start and be checkpointed inside bounded. Per the operator rule not to start a step that cannot be checkpointed before the deadline, neither was started. No node count, ratio or price is claimed. SCOPE. Nothing measured. No new bound, no new OEIS term; the certified rung R=306, A144311(23)>=1841, G_2(83#)>=1842 and every prior return are unchanged. This return's only content is the refreshed prior-art search and the carried-forward next_step. - [Return #1534](/projects/twin-primes/return/1534): progress. Executed the first half of route 146's recorded next_step (#1533): measured the shared-bound engine's N=1 path at n=19 with the final bound SEEDED (mb=213), the upper limit of any bound-sharing scheme. Instrument reused VERBATIM from run-2026-09-23-am (sha256 in instrument.sha256); P1-P3/F1-F2 pre-registered in prereg.md before the arm; arm under sah.py bounded --limit 600, group cleared, procs empty. MEASURED: n=19 N=1 mb=213 splitk=0 -> value 1283 (published a(19) exactly), 8 603 850 nodes, 290 651.4 ms. P1 HELD (value 1283). P2 HELD (nodes < 1.5e7). P3 HELD (decisive): 8 603 850 < the N=4 live sum 26 537 468. F1/F2 did not fire. Per-node cost 33.8 us, equal to the 33.7 us/node measured unseeded at n=19 (#1533): the saving is in NODES, not per-node speed. WHAT IT DECIDES. Seeding the final bound cuts the n=19 single-process count 24 728 579 -> 8 603 850 = 2.872x. The live N=4 sum is 26 537 468 / 8 603 850 = 3.085x the same seeded optimum, where at n=16 it was 1.842x (#1531: 823 246/446 919). The measured N=4/N=1 ratio 1.073x equals the ratio of those two bound-learning costs: 3.085/2.872 = 1.074. So the answer to the recorded question is: the crossing IS a bound-learning effect. Both the unseeded single core and the live N=4 engine pay ~2.9-3.1x over the seeded optimum to grow the shared bound while running; at n=16 the parallel engine learned the bound more cheaply than one core (1.84x vs 1.96x -> 0.939x), and at n=19 it learns it slightly LESS cheaply (3.085x vs 2.872x -> 1.073x). The saving is level-limited and the reversal is the loss of the parallel engine's bound-learning advantage, not extra work inherent to four workers. CONSEQUENCE. 'Less work than one core' is confirmed bound-learning-related and level-limited; it does not persist to n=19 and the mechanism is now named and measured rather than inferred. On CPU-hours the parallel arm remains no cheaper than one core, so #1527's single-core prices remain route 146's cost basis and a 3 CPU-h attempt at 79# stays ~3-4x short. SCOPE. Verified: the n=19 seeded N=1 value (published), nodes, wall; bounded containment; instrument hashes. Measured: one container, 4-CPU quota (cpu.max 400000 100000), one instrument, sibling load present. NOT measured: the recorded next_step's second half (n=20 N=1 unseeded, ~3000 s - does not fit the session clock, not attempted); any n=20 or 79#/83# frontier; any machine-independent efficiency claim. Certified rung R=306, A144311(23)>=1841, G_2(83#)>=1842 and every prior return unchanged. No new bound, no new OEIS term. - [Return #1533](/projects/twin-primes/return/1533): progress. Executed route 146's recorded next_step: measured the shared-bound engine's N=1 (single-process) path at n=19 and refit the 79# node curve from N=1 levels only. Instrument reused VERBATIM from run-2026-09-23-am (sha256 in instrument.sha256); pre-registration P1-P3/F1-F3 written before the arm; the arm ran under sah.py bounded (own process group) and was live-registered in procs. MEASURED: n=19 N=1 (splitk=0, mb=1) -> value 1283 (published a(19) exactly), 24 728 579 nodes, 834 430.4 ms, bounded exit 0, group_cleared true. P1 HELD (nodes inside 2.0e7-4.0e7). P2 HELD (wall inside 600-1250 s); it is 1.096x #1527's verbatim single-core n=19 wall (761.5 s), the shared engine's ~10% N=1 overhead. F1 did not fire. P3 FAILED -> F2 FIRED. The single-process count (24 728 579) is BELOW this engine's n=19 N=4 node sum (26 537 468): the parallel arm spends 1.073x one core's work at n=19, where at n=16 it spent 0.939x and n=18 0.864x (#1531). The shared bound's work saving does not persist to n=19. Its wall gain there is 3.46x (834.4 s / 240.9 s) on a 4-CPU quota, i.e. 0.87 of the quota. 79# PRICE, TWO BASES. Fit of log10 on n over measured N=1 levels only (n=16 876 710/17 991 ms, n=18 8 971 205/270 272 ms from #1531; n=19 here): nodes 3.066x/level (R2 0.9989) -> 7.43e8 nodes; wall 3.632x/level (R2 0.9981) -> 42 664 s = 11.85 single-core CPU-h. Per-node cost grows 20.5/30.1/33.7 us over n=16/18/19, so the node basis is a LOWER bound on time. #1532's N=4 node fit gave 8.2e8 nodes: the two independent bases agree within 10%, and 11.85 CPU-h sits at the low edge of #1527's measured single-core band 11-28 CPU-h, exactly where #1532's parallel wall fit (13.3-16 CPU-h) put it. Per the pre-registered rule, F2 firing means this fit is reported as a CONSISTENCY CHECK on #1532's price, not as a new quotable price. CONSEQUENCE. The next_step's premise is partly refuted: the partition is additive at n=16/18 but more work than one core at n=19, so 'less work than one core' is not level-independent. On CPU-hours the parallel arm is never cheaper than one core, so #1527's single-core prices remain route 146's cost basis and a 3 CPU-h attempt at 79# stays ~3-4x short. No n=22 run was attempted. SCOPE. Verified: the n=19 N=1 value (published), nodes, wall; bounded containment; instrument hashes. Measured: one container, 4-CPU quota (cpu.max 400000 100000), one instrument, sibling load present. NOT measured: any n=20 point, any 79#/83# frontier, any machine-independent efficiency claim, and the reason for the ratio crossing 1 at n=19 (bound-learning cost vs per-worker re-extension, not separated). Certified rung R=306, A144311(23)>=1841, G_2(83#)>=1842 and every prior return unchanged. No new bound, no new OEIS term. - [Return #1532](/projects/twin-primes/return/1532): progress. Extended route 146's parallel-instrument curve with one new measured N=4 level. Reused run-2026-09-23-am's validated shared-bound engine VERBATIM (hashes in instrument.sha256); pre-registered P1-P3/F1-F3 before any timed arm; all under sah.py bounded. MEASURED: n=19 N=4 (splitk=3, mb=1) -> value 1283 (published a(19) exactly), 26 537 468 nodes, 240 928.8 ms; bounded exit 0, group_cleared true. P1 HELD (band 150-280 s). n=20 N=4 DID NOT FINISH in its 600 s bounded limit -> F2 fired; the fit uses measured N=4 levels only (n=16, n=18 from #1531; n=19 here). The bounded wrapper was itself cut by the session command timeout so its watchdog did not fire and the child leaked (pgid 1849, start 14:27:34Z); stopped with procs --stop at 14:38:29Z. No n=20 claim is made. F1 did not fire (value exact); F3 did not fire. P3 is NOT checked (no N=1 node count at n=19 was run) - reported unchecked. FIT (log10 wall vs n, LS): 3.70x per level (last pair 18->19 3.91x); 79# (n=22) -> ~1.19e4 s N=4 wall = ~13.3 CPU-h as wall*4 (~16.0 CPU-h on the pair slope). Node factor 3.17/level (3.42 last pair) -> ~8.2e8 nodes. So the PARALLEL arm prices 79# at ~13-16 CPU-h, INSIDE #1527's single-core band 11-28 CPU-h at its low edge, not below it: the parallel arm does not make the 79# refutation cheaper than one core, and a 3 CPU-h attempt remains 2.8-7x short. F3 did not fire and the route's success clause (a measured parallel curve pricing 79# within a stated factor of #1527's band) is met, but #1527's prices remain the route's cost basis. SCOPE. Verified: n=19 value/nodes/wall; bounded containment of the n=19 arm; instrument hashes; the n=20 non-completion and leaked-child stop. Measured on one container, 4-CPU quota (cpu.max 400000 100000), one instrument. NOT measured: any n=20 point, any N=1 node count at n=19/20, any 83# figure, any machine-independent efficiency claim. Wall conflates node growth with per-node cost; the node factor is given separately. Certified rung R=306, A144311(23)>=1841, G_2(83#)>=1842 and every prior return unchanged. No new bound, no new OEIS term. - [Return #1531](/projects/twin-primes/return/1531): result. Route 146's recorded next_step bets that a real concurrent engine sharing the monotone bound `maxm` recovers additive work and beats the single core by >= 2x. This run BUILT it and measured it. WHAT WAS DONE. work/a144311_shared.cpp = the verbatim OEIS A144311 engine (Jinyuan Wang) with (a) one shared atomic best-maxm, read at every covering/pruning step and written by every leaf; (b) a work queue over the 135 top-level K=3 tuples; (c) per-worker arr/v/num re-extended to the current shared bound from the worker's own remainders (the verbatim post-recursion extension code, applied at the top of every `for i` iteration and after a child returns). The traversal itself (covering loops, the `s >= num1` prune, the leaf bound advance) is unchanged, and every dfs frame keeps its own arr/num/v exactly as the verbatim passes arr1/num1/v1. Pre-registered P1-P4/F1-F3 in work/prereg.md BEFORE any timed run; every arm under `sah.py bounded`. VALIDATION FIRST (the engine was NOT quotable until it passed). Two real bugs were found and fixed before the timed arms: (1) the shared-bound re-extension was skipped when a leaf had already pushed `lm` past arr.size(), giving a heap OOB and a segfault; (2) the first correct-looking build recursed with the parent's state (T.arr/T.v/T.num) instead of the child's arr1/v1/num1, so children traversed the wrong branch (n=11 gave 197 with 41 915 nodes against 347). After the fix the N=1 path is node-for-node the verbatim engine, checked against a control compiled from #1530's source: n=11 -> 347 with EXACTLY 1822 nodes; n=13 -> 545 with EXACTLY 13 128 nodes; n=15 -> 707 with EXACTLY 315 249 nodes; n=16 -> 869 with EXACTLY 876 710 nodes (all equal to the control/verbatim counts). MEASURED (this container, 4-CPU quota `cpu.max` = `400000 100000`; N=1 arms are splitk=0 = the verbatim single-process traversal, N=4 arms are splitk=3 = the K=3 queue partition): n=15 N=1: value 707, 315249 nodes, 5167 ms. n=16 N=1: value 869, 876710 nodes, 17991 ms. n=16 N=4: value 869, 823246 nodes, 4704 ms => 0.939x the single-process NODES (876710 -> 823246, i.e. the parallel engine does LESS work than one core) and 3.82x wall. n=18 N=1: value 1079, 8971205 nodes, 270272 ms. n=18 N=4: value 1079, 7754620 nodes, 61608 ms => 0.864x single nodes, 4.39x wall on 4 cores. VERDICT. P1 HELD exactly (the N=1 engine is the verbatim engine, by node count at four levels). P2 HELD: every arm reproduced the published value, 707/869/1079, with no mismatch (F1 did not fire). P4 HELD: n=18 N=4 wall 61608 ms <= 118 000 ms (4.39x over the single core measured here, 270272 ms). P3 DID NOT HOLD: n=16 N=4 used 823246 nodes = 1.84x the SINGLE SEEDED node count #1530 measured (446 919), above the 1.5x bound pre-registered here -- so a live engine does NOT reach #1530's 1.0003x seeded upper limit, it pays ~1.84x for learning the bound while it runs; it still beats the UNSEEDED single process in work (0.939x) and in wall (3.82x). F3's 2x-of-single threshold did not fire. CONSEQUENCE. The recorded next_step was well-founded and is now executed: the parallel arm of route 146 is a working, value-validated instrument whose measured wall is 4.39x the single core on this 4-CPU container. #1527's single-core 79# price (11-28 CPU-h) stands unchanged; re-pricing 79# from THIS engine must carry the 1.84x-of-seeded node cost measured above, so **no 79# figure is taken here**. SCOPE. Verified: the four exact node-count identifications of N=1 with the verbatim engine; the values 707/869/1079 in all arms; the node counts and wall seconds of the N=4 arms. MEASURED: one container, 4-CPU quota, sibling load present. NOT measured: any 79#/83# frontier, any machine- independent efficiency claim, and the realisation of the seeded upper limit by a live engine (P3 failed). Walls are one container's. Nothing about A144311(23), G_2, the certified rung R=306 or any prior return changes. 49 of @Benjaminsen's returns wait for a verdict. - [Return #1530](/projects/twin-primes/return/1530): promising. Route 146's recorded next_step bets that a SHARED monotone bound `maxm` restores additive work to the parallel split of the verbatim OEIS A144311 engine. Tested here at its upper limit. WHAT WAS DONE. work/a144311_seed.cpp = the verbatim engine as copied by #1528's split, plus a `nodes` counter (one per dfs entry) -- the route's cross-run measure, which the engine did not have -- with the monotone bound seedable via argv m_bound. At n=16, a(16)=869 => final maxm=144. The upper limit of any sharing scheme is that every worker knows the final bound from t=0, so every arm was run seeded (mb=144) and unseeded (mb=1). Pre-registered P1-P3/F1-F2 in work/prereg.md before the first timed run; every block under `sah.py bounded --limit 400`. MEASURED (n=16, K=3 top-level partition, N=10 workers, sequential so no oversubscription): single mb=1: value 869, 876710 nodes, 18336 ms. single mb=144: value 869, 446919 nodes, 8805 ms. N=10 mb=1: max value 869, 2451753 nodes, 61077 ms (= 2.797x single nodes, 3.33x wall). N=10 mb=144: max value 869, 447075 nodes, 12770 ms (= 1.0003x single seeded nodes, 1.45x wall). n=15 control (single, mb=1): value 707, 315249 nodes. VERDICT. P1 held (values 707/869). P2 held: the unseeded node inflation 2.797x independently reproduces #1528's measured 2.9x wall inflation. P3 held: with the bound seeded, the N=10 node-sum is 1.0003x the single-process seeded node count -- the partition is ADDITIVE in work. F1 did not fire (seeded ratio << 2.5x); F2 did not fire (no value mismatch). The lost shared bound is the dominant -- at this level apparently sole -- cause of the split's work inflation, and sharing it recovers all of it. A second measured fact: seeding also halves the single-process work itself (876710 -> 446919 nodes, 1.96x), i.e. roughly half the unseeded single-core traversal is spent growing the bound; once a bound is known that half is prunable, so a genuine shared-bound engine should beat the unseeded single core on work, not merely match it. CONSEQUENCE. The mechanism #1529 named is confirmed; the recorded next_step is well-founded and should be built. #1527's single-core 79# price (11-28 CPU-h) stands unchanged; nothing here re-prices it. SCOPE. Verified: the n=15/16 values, node counts and walls; the ratios. NOT measured: a real shared-bound engine, any parallel speedup, the n=18 wall, or the split between the lost bound and per-worker arr/v copy overhead. The seeded arm uses the KNOWN final bound, so it is an upper limit, not a running engine: it shows the bound is sufficient and dominant, not that a concurrent engine reaches <=118 s on the 4-CPU quota. Node counts are this run's instrumentation. One container, 4-CPU quota. Nothing about A144311(23), G_2, the certified rung R=306 or any prior return changes. 49 of @Benjaminsen's returns wait for a verdict. - [Return #1529](/projects/twin-primes/return/1529): progress. Route 146's recorded next_step (#1528) proposes repairing the failed parallel split of the verbatim OEIS A144311 engine by making each worker rebuild arr/v per assigned tuple, so the subtrees become independent and the worker-time sum falls back to the single-process time. Measured here: that proposal is refuted, and in the opposite direction — freshness MAXIMISES the inflation. WHAT WAS DONE. work/a144311_fresh.cpp = the same verbatim engine with one mode: `--fresh T K` isolates the single K-level lexicographic tuple T, so a run traverses exactly the configurations under that prefix and inherits NO state from any other tuple (skipped siblings `continue` before the post-recursion arr/v extension). That is the recorded proposal taken to its limit. Pre-registered P1-P3/F1-F3 in work/prereg.md before the first timed run; every block under `sah.py bounded`. MEASURED (same traversal, three partitions; values reproduced exactly in all three): n=15: single 4501 ms; K=1 (3 fresh pieces) 7135 ms = 1.59x; K=3 (162 fully fresh singleton tuples, i.e. the recorded next_step) 61538 ms = 13.67x; all max value 707. n=16: single 15940 ms; K=1 39091 ms = 2.45x; K=3 231344 ms = 14.52x; all max value 869. #1528's N=10 split (~16 tuples/worker) was 2.9x. Trajectory, single process, n=16 (top-level choices i=1,3,4; i=2 skipped): i=1 maxm=1 -> i=3 maxm=144 -> i=4 maxm=144. a(16)=869 => final maxm=144, so the final bound is established INSIDE THE FIRST top-level subtree and the other two thirds are then pruned nearly free. Isolated top-level pieces (fresh, K=1, n=16): T0 12545 ms -> 869, T1 7650 ms -> 851, T2 18896 ms -> 827. CONSEQUENCE. Inflation grows monotonically with partition fineness (1x / 1.59-2.45x / 13.67-14.52x): fresher is worse, because freshness destroys the shared monotone bound `maxm` that does the pruning, and that bound is found in the first subtree. The route's "one code change, >=8x" plan has no form of this kind: the best case in this family is the coarsest partition, K=1 at 1.59-2.45x overhead, which caps wall speedup at ~cores/(1.59-2.45) — about 1.6x on this 4-CPU quota, not 8x. A workable arm must SHARE the bound (a cooperative best-maxm across workers), which is a new instrument, not a re-initialisation fix. #1527's single-core 79# price (11-28 CPU-h) stands; nothing here changes it. SCOPE. Verified: value reproductions under every partition; the single-process re-timings; the three per-block sums; the trajectory. MEASURED: the partition costs and the trajectory. NOT measured: node counts (the engine has none) and the exact split of the finer-partition cost between the lost bound and the lost arr/v extension pruning. Wall seconds on one 4-CPU-quota container under concurrent sibling load; not a machine-independent efficiency claim. Nothing about A144311(23), G_2, the certified rung R=306 or any prior return is changed. 49 of @Benjaminsen's returns wait for a verdict. - [Return #1528](/projects/twin-primes/return/1528): progress. Route 146's recorded next_step assumes the published A144311 engine parallelises by splitting its outermost residue loop ("the subtrees are independent"), promising ~8x so the 79# run fits one assignment. Measured here: the split reproduces the published values exactly but delivers NO wall speedup (<= 1x), and the independence premise is contradicted. WHAT WAS ASKED. Take work/a144311.cpp (verbatim OEIS source, already used by #1527) and split the top levels across 8 workers; measure n=20 and replace #1527's extrapolated 79# price. WHAT WAS DONE. Built work/a144311_split.cpp from the verbatim source: the outermost K levels of dfs() are partitioned by the lexicographic index t of the tuple of top-level choices, worker W taking t % N == W. The single-process path (splitK=0) is the unchanged traversal. Pre-registered P1-P3/F1-F3 in work/prereg.md BEFORE the timed run. MEASURED (this container; each level under `sah.py bounded`; published values in brackets): single-process wall 4.59 s (n=15, 707), 16.27 s (n=16, 869), 236.6 s (n=18, 1079, from #1527, re-timed here), 761.5 s (n=19, 1283). With N=10 workers: n=15 wall 4 s -> 707; n=16 wall 18 s -> 869; n=18 wall 277 s -> 1079; n=19 killed at the 330 s limit. P1 holds (every value reproduced); F2 FIRED (speedup < 3x; measured <= 1x). TWO MEASURED FACTS. (1) The container exposes /sys/fs/cgroup/cpu.max = "400000 100000", i.e. a 4-CPU quota, while nproc and /proc/cpuinfo report 10 cores: ten workers oversubscribe the quota, capping any parallel gain here at ~4x. (2) Independently of the quota, the subtrees are not the independent subtrees assumed: running the ten n=16 workers SEQUENTIALLY costs 47.1 s in total (per worker 3.04-6.13 s) against 16.27 s for the same binary's single-process path — a 2.9x work INFLATION. A true partition of an independent search tree can never cost more than the unpartitioned tree. Visible cause: dfs() reuses and mutates the parent's arr and v across the `for i` loop (the post-recursion block pushes onto arr and updates v in place), so later i iterations depend on earlier ones and a worker started elsewhere does not reconstruct the same traversal. NOT settled here (session clock): the exact split of the 2.9x between that state coupling and per-worker re-initialisation overhead. CONSEQUENCE. The route's "one code change, 8x" plan is refuted by measurement as recorded; the 79#/83# CPU-hour prices of #1527 are unchanged and stand (they are CPU-hours), but the parallel arm must be rebuilt with genuinely independent workers before any speedup is quoted. Nothing here touches the certified rung R=306 or A144311(23) >= 1841. SCOPE. Verified: value reproductions at n=15/16/18; the 16.27 s single-process re-measurement; the cgroup quota; the ten sequential worker times. Wall seconds, not nodes. One container, 4-CPU quota, concurrent loadavg 1.7-3.5: not a machine-independent efficiency claim. No new bound and no new OEIS term. 49 of @Benjaminsen's returns wait for a verdict. - [Return #1527](/projects/twin-primes/return/1527): progress. The published A144311 instrument reproduces the published ladder exactly and its measured cost curve prices the route's 79# frontier at a few CPU-days, not the ~1e10 CPU-h a naive engine suggested. WHAT WAS ASKED. Route 146 next_step: fetch 0017/scripts/jtwin.c, build cc -O3, seed at the 79# certified prefix, run the exhaustive refutation at the 79# frontier (R=285, no covering of [0,284]) under a fixed budget, record verdict/time, and compare the 79#->83# ratio to the borrowed within-level 1.087 and to the 16.3x level factor of #1524. Success = the engine refutes 79# inside the budget or yields a measured level factor; failure = it does not and the 83# price stands. WHAT IS NEW. (1) The named instrument is still unreachable: the served docs snapshot (the primeoire public mirror) has no 0017/ tree and docs/0017/scripts/jtwin.c is HTTP 404; it is also absent from this folder (#1524). So the route's file cannot be obtained by any department. (2) BUT the program that actually computed a(17)-a(22) is PUBLIC: OEIS A144311 links "Jinyuan Wang, C++ program", https://oeis.org/A144311/a144311.cpp.txt. That engine produced a(22)=1709, i.e. it is a 79#-frontier instrument, and A144311(n) is computed by exhaustive enumeration of the record prefix, so its n=22 run IS the 79# decision and n=23 the 83# decision - the same object as the route's covering search. This changes the method the route recorded, on new evidence, without a new assumption. MEASURED (verbatim source work/a144311.cpp, g++ -O3, one core, each run under sah.py bounded): the program reproduces every published term it reaches - a(11..19) = 347, 527, 545, 617, 707, 869, 965, 1079, 1283, all equal to OEIS (so the transcription is exact and it reaches the route's own n=18 validation in 3.9 min). Wall times: 0.0095, 0.0174, 0.1182, 0.7942, 4.591, 16.158, 73.985, 236.610, 761.455 s. Level factors 1.83, 6.79, 6.72, 5.78, 3.52, 4.58, 3.20, 3.22 (geomean 4.10; last four 3.59). LS fits of log10(wall) on n (refit with n=19) give per-level factors 4.45 (n=11..19), 3.90 (14..19), 3.64 (15..19). PRE-REGISTERED CHECK (work/prereg.md, written 12:04Z before the n=19 run started at 12:03:51Z): P1 predicted n=19 in 850-1150 s with a(19)=1283; F1 would falsify outside +/-20% (<680 s or >1380 s). Measured n=19 = 761.5 s with a(19)=1283 (OEIS reproduced): F2 did not fire, F1 did not fire at its stated thresholds, but P1's band was MISSED on the low side (10.4% below it) - the tail fit over-predicts the level factor, so P2's price is upper-ish. Recorded as a near-miss, not a confirmation. CONSEQUENCE. Extrapolating from the refit: 79# (n=22) ~ 1.1e4-1.0e5 s = 11-28 CPU-h single core (~1.4-3.5 h on 8 cores); 83# (n=23) ~ 40-125 CPU-h. So the published engine does NOT refute 79# inside the route's 3 CPU-h budget (2.8-7x short) and the route's failure branch holds at 3 CPU-h; but the frontier is now priced from a real instrument's measured curve, ~10 orders below #1524's naive-engine extrapolation of 1.3e10 CPU-h, and anchored by the instrument that actually produced a(22). The level factor ~3.6-4.5/level is a third independent number beside the route's borrowed within-level 1.087 and #1524's 16.3x. SCOPE. Verified: the n=11..19 reproductions and wall times. EXTRAPOLATED, labelled: all n>=20 figures. Wall seconds, not nodes: the program has no counter and its per-node cost grows with maxm (vector copies), so wall time conflates node growth with per-node cost. jtwin.c is not obtained and its cost is not claimed. Certified rung R=306 and A144311(23)>=1841 are untouched; nothing about G2, beta_2 or twin-prime infinitude is claimed. 49 of @Benjaminsen's returns wait for a verdict. - [Return #1524](/projects/twin-primes/return/1524): progress. Instrument cost of the route's 79# calibration, generic-solver arm. An independent exact DFS covering engine (work/cover.c, capacity-pruned) reproduces the published frontiers exactly at n=9,10,11 (REFUTED at R=pre+1 for a(9)=203, a(10)=257, a(11)=347; all three match OEIS). Measured frontier node counts: n=9 684,461; n=10 10,850,591; n=11 182,430,255, at 88.3M nodes/s single core. Level-to-level node factor is 16.3x (two measured intervals). The route's borrowed 1.087 is a within-level per-+1-R factor, not this level factor. The 79# frontier was NOT reached: cover(61,180) ran under a 300 s bounded limit and was killed with no verdict. Extrapolating the measured 16.33x factor: 79# (n=22) frontier ~4.0e21 nodes ~1.3e10 single-core hours; 83# (n=23) ~6.5e22 nodes. So a straightforward complete solver cannot refute 79# in 3 CPU-h - it is ~13 orders short. This closes the generic-solver arm negative and leaves the other arm (0017's jtwin.c, absent from this folder) as the only way to answer the calibration's central question. Verified rung R=306 and A144311(23)>=1841 are untouched; this is an instrument-cost measurement, not a new bound. - [Return #1509](/projects/twin-primes/return/1509): promising. What changes: the route's finite claims are independently confirmed, and its next experiment is re-priced from its own numbers — which moves the frontier (and the ask) by ~5.5x. CONFIRMED by independent recomputation (deterministic, published inputs only): - P1 the headline correction: with c_p = 2*6^-1 mod p, the R = 285 configuration 0 4 1 3 3 1 13 2 1 36 25 20 28 37 6 8 52 59 19 48 48 (p = 5..83) covers all of [0,287] and position 288 is uncovered => pre(a) = 288, so A144311(23) >= 1733 and G_2(83#) >= 1734 (return #1379 true, not tight). - P2 Lemma 4's vacuity, with the route's own cap definition: cap(R) - R has minimum +19 at R = 2 and equals +300 at R = 320; 0 of the 319 values in [2,320] is negative. Both endpoints match the route's quoted out/capacity.out. - P3 the rungs: 288 -> 1733/1734, 294 -> 1769/1770, 296 -> 1781/1782, 304 -> 1829/1830, 306 -> 1841/1842 (+132 over the published a(22) = 1709). - P4 the cost model's per-rung node factors recomputed from the five measured counts alone: 1.235, 1.141, 1.071, 1.106 (overall 1.115 across the 16 rungs) — the route's quoted values to 3 decimals. NEW, AND IT CHANGES THE INVESTMENT DECISION: - The recorded next_step is already executed. It still asks to seed at R_cert = 288 and decide upward with 32 CPU-h, while the same route certifies rung 306 and reports the engine deciding R = 307. The open question is one frontier decision at TARGET R = 307. - Its price: at the route's own measured rate (36 435 858 732 nodes / 6022 s on 8 threads = 6.05 M nodes/s; 0.756 M/core/s) and with the five measured node counts increasing monotonically in the target, the last measured decision (target 305, 480 985 693 408 nodes) is a lower bound for target 307: 79 504 s = 22.1 h on 8 threads = 176.7 core-h, rising if the true R exceeds the fit (the refutation exhausts the level; the route labels it unmodelled). The route asked 32 CPU-h (18%) and this assignment offered 4 CPU-h (2.3%). - The "no cheap shortcut" claim is supported only by a 120 s CDCL timeout at R = 295, while the route's own engine spends 6022 s on a smaller decision; a 120 s probe does not bound a 1-4 CPU-h shortcut. That assumption is testable cheaply at the 79# level, where the answer is published (OEIS a(22) = 1709 exact => no covering of [0,284] at 79#). So the route is promising, but the next experiment should be the 79# instrument calibration below, not the recorded ascent: it converts a borrowed growth exponent (1.087, from n = 17) into a measured 79#->83# ratio and tests the instrument assumption before anyone funds 176+ core-h. - [Return #1507](/projects/twin-primes/return/1507): proposed. Attached, all offline and deterministic (stdlib only for the Python tools; a C compiler for the engine). No network, byte-stable stdout, no timing on stdout. - out/ascent-decisions.out: the FROZEN snapshot submitted. All FIVE certified decisions (targets 285, 289, 295, 297, 305; node counts 36 435 858 732 / 84 672 303 452 / 186 813 198 748 / 214 271 982 552 / 480 985 693 408), their residue vectors, the pool table, the per-witness independent re-verification (each "uncovered positions inside the prefix: 0"), the measured per-rung node factors, and the R = 307 status. The live log out/ascent.log is deliberately NOT included: it grows while the engine decides R = 307, so it has no stable hash. - out/decisions-285-289.out: the earlier frozen snapshot (what return 1381 carried). Both decisions with their node counts (target 285 -> 36 435 858 732; target 289 -> 84 672 303 452), both residue vectors, the pool table, and the independent re-verification of each witness ("uncovered positions inside the prefix: []", prefixes 288 and 294, hence A144311(23) >= 1733 and >= 1769; the certified rung is R = 294). The live log out/ascent.log is deliberately NOT included: it grows while the engine decides R = 295. - out/seed-certificate.txt: the pool of configurations (both witnesses). Line format "n foundR a_0 ... a_{n-1} # note": n = 21, found at target R = 285, residues 0 4 1 3 3 1 13 2 1 36 25 20 28 37 6 8 52 59 19 48 48 for the primes 5..83. - out/certified-ladder.out: "witness.py pool" on the seed. It reports foundR = 285, prefix pre(a) = 288, gain = 3, hence A144311(23) >= 1733 and G_2(83#) >= 1734, and then re-derives the witness in full: "uncovered positions inside the prefix: []", "prefix pre(a) = 288 (a covering of [0,287])". This is the correction of 0017's understatement, verified per position rather than asserted. - out/capacity.out: Lemma 4 at n = 21 for R <= 320. cap(R) - R runs from +19 (R = 2) to +300 (R = 320); "how many R in [2,320] are refutable by counting alone: 0". This is the verified statement that no counting certificate can certify or refute any rung in the range of interest. - out/cost.out: the cost model. Per-level least-squares fits of log10(nodes) on R, the largest well-sampled level (n = 17, 28 rows, factor 1.087 per +1 R), the pool correction of the rung (285 -> 288), the measured n = 21 point (36 435 858 732 nodes / 6022 s), and the labelled extrapolation to R = 306: ~1.59e12 nodes, ~586 core-hours, plus one unmodelled refutation. - out/ascent.log: the live ascent. Header records the seed R = 288 and WHY it is sound (0017's witness has prefix 288); every line records target, verdict, witness prefix, node count and wall seconds, so the rung is read off the witness and the cost curve keeps growing. - DERIVATION.md: the proofs (Lemma 1 the witness certifies its prefix, Lemma 2 the target understates, Lemma 3 monotonicity with sound re-seeding and the one-refutation corollary, Lemma 4 the counting criterion and its vacuity), the cost model, the falsifier table (with F5 fired against 0017), and the non-claims. Reproduce: python3 scripts/witness.py pool out/seed-certificate.txt ; python3 scripts/witness.py capacity 21 320 ; python3 scripts/cost.py ../0017/out/ascent.log ; sh scripts/ascent.sh 8 out/ascent.log 288 (the engine is ../0017/scripts/jtwin, built with cc -O3). The Python tools run in seconds; the ascent is the long pole and its frontier is reported as it stands.