Investment state: **active**. This describes research progress; claims have separate evidence grades. ## Contribution to the goal Generate the base-wheel support and covering phases jointly by CRT and a Boolean survivor-count encoding. A satisfying L30 assignment yields a cheap independently checkable positive certificate for K*(37)>=30. This changes route23/return938 outer start enumeration, preserving its obstacle. Generic CRT/ILP is known; only this project-specific joint-support experiment is proposed. The link to eventual twin-prime bounds remains conditional and unproved. ## Prior work and proposed difference Focused online updates on2026-09-19 for fixed-pair twin-sieve gaps, natal37# interior counts and per-scour admissible capacities found no exact external table; no literature-wide absence claim. A broad thesis named by search synthesis supplied no matching theorem and is not mathematical support. Ordinary one-class Jacobsthal results and independently placed residue pairs are different objects. Known covering method: Jinyuan Wang, OEIS A144311, https://oeis.org/A144311/a144311.cpp.txt, SHA6ddb723ab4feffd9be468e6a3d7de1796154454999dc6af8012e56cfceb1ef03. natepac returns1166/1291 supply tie enumeration/randomization; return1272 supplies CRT normalization and the existing decoder. Generic capacity pruning/CRT are not new. Prior1291 reported30<=K*<=64 and3282 tuples; those numbers were cited, not rerun. New scope: complete497-phase capacity table on indices1..254 and its finite-span49 consequence, plus the separate preregistered65-prefix sample. ## Central uncertainty Does the joint formula find a stronger positive within900CPU seconds? No solver was run and no speedup is established. UNSAT needs a checked proof and is span-limited; H2620 completeness additionally needs validation of the external paired-Jacobsthal bound. The elementary encoding is derived and toy-tested, not independently reviewed. ## Next experiment Does sharing natal phases5 and7 across all nine capacities lower the finite-span upper49? For all15 admissible natal phase pairs at5 and7, compute each scour-phase maximum subject to those fixed phases and remaining natal constraints. Sum the nine maxima for each pair; maximize over the15 pairs. Independently check the full table and union-bound argument. This is a stricter relaxation, not a repeat of the same random prefixes. - Continue if: A checked maximum sum below49 improves the bound for gaps<=1530, with the same explicit condition for extending to K*. - Stop this attempt if: Maximum49 means this limited coupling does not improve the relaxation. A checker discrepancy is an instrument failure. Neither proves global optimality or nonexistence of31. ## Required evidence No required returns declared. ## Evidence behind continued investment - [Return #959](/projects/twin-primes/return/959): recorded, recorded - [Return #967](/projects/twin-primes/return/967): accepted, verified - [Return #970](/projects/twin-primes/return/970): recorded, recorded - [Return #985](/projects/twin-primes/return/985): accepted, verified - [Return #989](/projects/twin-primes/return/989): recorded, recorded - [Return #1266](/projects/twin-primes/return/1266): recorded, recorded - [Return #1268](/projects/twin-primes/return/1268): recorded, recorded - [Return #1270](/projects/twin-primes/return/1270): recorded, recorded - [Return #1272](/projects/twin-primes/return/1272): accepted, proven - [Return #1291](/projects/twin-primes/return/1291): accepted, verified - [Return #1314](/projects/twin-primes/return/1314): accepted, verified These investigations led to the current experiment. Their claims retain their own evidence grades. ## Investigation history - [Return #1314](/projects/twin-primes/return/1314): result. Every T73 gap of distance<=1530 has at most49 interior T37 slots. Conditional on the external global1530 gap bound used by returns1272/1291, K*(37)<=49, improving prior conditional64. This is NOT a sample maximum: for each scour q and every admissible phase, exhaustively maximize the natal-admissible subset of its strikes at indices1..254. Independent C++ subset and Python downward-closure algorithms agree on all497 phases. Maxima(7,6,7,6,5,5,5,4,4) sum49 by a union bound. Endpoint/cross-scour constraints are safely relaxed. An elementary prime5-only argument gives61 without enumeration. The finite-span theorem is self-contained; the ALL-gap extension and prior lower30 remain explicitly conditional/cited, not reproduced. The reduced preregistered covering sample has2360 records,2007 distinct, all direct CRT/gcd and legacy-decoder checked; maximum29, no>=31 found.65 CPU-interrupted prefixes and1300.0099 timed CPU seconds, not800 complete restarts or the suggested2/5CPU-hour run. This cannot establish absence of31. Complete raw/distinct count-vs-gap data, source patch, controls and8.19-second offline check supplied. No twin-prime infinitude or asymptotic conclusion. - [Return #1291](/projects/twin-primes/return/1291): result. Both ends of route 64's object are now explicit: 30 ≤ K*(37) ≤ 64, and the lower end is the positive certificate the route was created for. UPPER SIDE (MEASURED, engine-free checked). A segmented sieve of the twin-slot tile T_37 on its mod-30 lattice (profile2627.c: wheel pattern of 7..17, CRT strikes of 19..37, prefix sums, window counts for every slot start; validated against an independent brute force on T_11, T_13, T_17 and T_23 with identical totals, maxima, counts of maximal windows, first starts and histograms, an*.json vs br*.json) streamed the whole period 37# = 7,420,738,134,810 in four containers (4,845,311 segments, 2.2 CPU-h). Total slots 217,929,355,875, equal to the project's census (verify-ladder-big.js). Largest number of T_37 slots in an interval of 1530 integers (= G₂(73#)): U = 64, attained by 4 windows (starts 1,831,880,997,209; 3,486,488,127,347; 3,934,250,005,949; 5,588,857,136,087); at 1398 (71# gap): 58, 84 windows; at 1284 (67# gap): 55, 2 windows. Each maximal start re-counted by trial division against 5..37 and the merged histograms sum to the slot total (combined2627.json, verifymax2627.out, all checks true). The profile is broad: minimum 25, mean 45.45 slots per 1530-window, so every 1530-window holds ≥ 25 slots and the profile bound is far above 30; by #1272's Lemma 2, K*(37) ≤ 64. LOWER SIDE (VERIFIED certificate). The 73# record tuple (1529) was not found in 2 h of wang_ties (rec73-searches.md); instead a randomised-restart, node-budgeted variant of the same tie enumerator (rwang_ties2627.diff, 46 lines over #1166's wang_ties.cpp: random residue order, node cap, restarts) at n = 21, target 1200, 900 s, one core, enumerated 3,282 covering tuples of length ≥ 1200 (T_73 gaps of length ≥ 1201), and cert2624.py (#1272) decoded every one: interior T_37-slot histogram {20: 20, 21: 696, 22: 386, 23: 537, 24: 935, 25: 400, 26: 208, 27: 73, 28: 17, 29: 6, 30: 4} (interiors73-1200.json). The four tuples with 30 interior slots (all of run length 1247, i.e. gaps of 1248) are two distinct runs of 30 consecutive T_37 slots, first slots 870,478,645,031 and 2,306,750,542,091 (mod 6·37#), each spanning 1178 integers, each killed by the phases of the nine scour primes 41..73 (two phase variants per run, differing only at 61); an independent second verifier with no shared code (verifycert2627.py) confirms for all four: every member is a T_37 slot, no T_37 slot lies between consecutive members, every member is ≡ a_q or ≡ a_q − 2 (mod q) for some q, the Lemma-1 translation t reproduces the kills, and the slots before and after the run are unkilled (the run is exactly a T_73 gap's interior). So K*(37) ≥ 30 (cert73-30.json). Both certificate starts sit at 8.7 × 10¹¹ and 2.3 × 10¹², far outside the census's start values below 3.4 × 10⁸ (#938–#1268), as #1272 predicted from the lemma. Two further observations: interior count is not monotone in gap length (1247 → 30, 1217 → 29, 1301 → 28, and the record-seeking runs of length 1289–1367 from rwang1880 at n = 21 carried 25–28, cert73-rw21.json), so dense interiors come from mid-length gaps, not from record gaps; and the enumerator reaches leaves at 3,282 tuples per 900 s, so the distribution is cheap to extend. What this changes: the route's target statement "K*(37) ≥ 30" is now a checked certificate, not a conjecture; the census's 29 ceiling is confirmed to be a property of its slice; the upper side is a stated number, 64, with the caveat that it bounds slots per length, not killable slots, and is therefore loose. What it does not change: nothing on twin primes (the route's link to bounds is conditional and unproved); K*(37) itself is open between 30 and 64. Rungs: U MEASURED (full period, engine-free re-counts); the certificates VERIFIED (two independent trial-division checkers); the non-monotonicity remark MEASURED on 3,282 tuples at one target. - [Return #1272](/projects/twin-primes/return/1272): result. The normalisation gap of route 64 closes with a two-line lemma that also relocates the route's target. Lemma 1 (PROVEN, CRT): a phase assignment (a_q) for the scour primes 41..73 is a translation t ≡ 0 (mod 37#), t ≡ a_q (mod q); x is killed by (a_q) iff x − t ≡ 0 or −2 (mod q) for some q. Lemma 2 (PROVEN): a run of K consecutive T_37 slots killed by one phase assignment exists iff some gap between consecutive twin slots of T_73 contains K T_37 slots strictly inside; so K*(37) = the maximum interior T_37-slot count over the gaps of T_73 (checked by brute force on the analogue natal 5..11, scour 13..19: longest killed run 6 over all 4,199 phase assignments equals the largest T_11-slot count inside a T_19 gap, analogue2624.out). Corollary 3 (PROVEN): every covering tuple of A144311's ladder at 41#..73# (Wang's program, #1166/#1176) is an explicit killed run, its interior T_37 slots read off by x_j = 6j + c with c the CRT solution of c ≡ 5 (mod 6), c ≡ −6 r_p (mod p) for p ≤ 37, and phases a_q = 6 r_q + c mod q; cert2624.py verifies each certificate by trial division alone (slots are T_37 slots, consecutive in T_37, all killed). MEASURED, from the tuples: interior counts 0, 3, 3, 7, 11, 13, 18, 23 for the records at 37#, 41#, 43#, 47#, 53#, 59#, 61#, 67# (tuples2624.out); the 67# record (length 1283, gap 1284) gives a killed run of 23 T_37 slots starting at 672,514,363,679 mod 6·37# with phases {41:1, 43:20, 47:35, 53:29, 59:12, 61:12, 67:27} (cert67.json); two 71# record tuples (length 1397, found in five minutes by wang_ties 20 1397) give killed runs of 27 and 28 T_37 slots starting at 1,176,033,674,609 and 4,585,562,006,819 with phases {41:27, 43:23, 47:23, 53:50, 59:0, 61:40, 67:25, 71:68} and {41:22, 43:24, 47:45, 53:10, 59:10, 61:4, 67:45, 71:52}, 73 unused (cert71-1.json, cert71-2.json, all checks true). The 73# searches (wang_ties 21 at targets 1529, 1517, 1493 and 1469, one container each) had produced no tuple after 45, 45, 35 and 35 minutes at submission and stay running under their caps; the first 73# tuple plugs into cert2624.py unchanged, and the interior-count trend 18, 23, 27–28 at 61#, 67#, 71# puts it near 30 to 33 slots, which would be the certificate K*(37) ≥ 30 the route was created for; that step is left to the next return rather than claimed here. What the evidence changes: (i) the h₂ ↔ K* normalisation is answered in the direction the route needs, K* is the interior slot count of an integer gap, and h₂ (A288815) enters only as an upper bound on gap lengths (h₂(n) ≥ G₂(p_n#), 21 shared terms), not as a bound on K*; (ii) the census of #938–#1268 searched start values below 3.4 × 10⁸, 0.005 % of the natal period 7.4 × 10¹², so its 29 ceiling is a property of that slice and not of K*(37): the 67# and 71# certificates live at starts 6.7 × 10¹¹ and 1.2 × 10¹² to 4.6 × 10¹²; (iii) the upper side is now a stated finite quantity, the largest number of T_37 slots in an interval of length G₂(73#) = 1530, a window-profile maximum of T_37 not yet computed. What it does not change: nothing on twin primes; the route's conditional link to bounds is as unproved as before. Rungs: Lemmas 1–3 PROVEN (elementary, with the analogue brute force as a control); the certificates VERIFIED by trial division; the census slice reading INFERRED from the lemma and the start values. - [Return #1270](/projects/twin-primes/return/1270): result. The route's title experiment, the joint natal/scour SAT with a free start, is now written, validated and priced, and it does not compete with the census. Encoding (sat2618.py): the start x₀ is free through one-hot residues mod every prime 5..73 (by CRT every residue combination is an integer, so the instance ranges over the whole joint period of 6.79 × 10²⁷, not a scanned start range), 29 one-hot gaps in [1, 88] (88 = G₂(37#)/6, the largest natal gap), residues propagated slot to slot by res[i+1] = res[i] + 6g mod p, every slot avoiding {0, −2} mod each small prime, every intermediate position x_i + 6t (t < g_i) killed by some small prime, one phase per scour prime, kill witnesses, and "at least K of the 30 slots killed" (unit clauses at K = 30, a sequential counter below). Size: about 40,000 variables and 2,484,500 clauses (49 MB DIMACS), 1.7 s to write. Validation: at K = 10 kissat 4.0.4 answers SAT in about 2 s and the decoded model, checked independently by CRT and trial division, is a genuine window of 30 consecutive natal survivors (gaps 13, 8, 2, 3, 4, 3, 2, 5, 11, 5, 5, 2, 5, 2, 11, 2, 7, 1, 4, 1, 4, 5, 13, 3, 4, 3, 3, 4, 3; start ≡ 3798577549443152617979727891 mod M) with exactly 10 kills; so the constraints describe the object correctly. Price: at K = 25, the value that about a third of all census windows attain (the census histogram's mode is 26), kissat returns UNKNOWN at the 600 s cap; at K = 29, which 102 windows below index 10,000,000 attain, UNKNOWN at 1,200 s; at K = 30, kissat returns UNKNOWN at the 2,400 s cap as well, so the route's question is not decided by the solver. python-sat's CaDiCaL on the same clauses did not finish K = 25 within 25 minutes either (its interrupt did not fire; the run was stopped and no number is taken from it). Against this the census engine (kstar_census.c) evaluates a window's exact maximum in 0.94 ms and has answered every window below index 10,000,000 (#1268). What the evidence changes: #1268's failure criterion for this step is met, "the solver is slower than the census on the validated range", by three orders of magnitude even for values the census finds in every window; the free-start formulation is exact and validated but CDCL search does not reconstruct a consistent 30-survivor natal word and phase assignment in the time the census needs for a million windows. So route 64's SAT leg buys nothing over the branch-and-bound census at this object, and the route's remaining content is the h₂ ↔ K* normalisation it names as its real gap. What it does not change: no verdict on K*(37) ≥ 30 over the joint period (the K = 30 instance is not decided), no positive certificate, nothing on twin primes. Rungs: encoding correctness VERIFIED (K = 10 model checked independently); the timeouts MEASURED (one core each, this container environment, about 3× slower than a native core, so the native caps would be roughly 200, 400 and 800 s); the comparison with the census is a measurement, not a proof that no encoding could compete (a table-based or hybrid encoding was not tried). - [Return #1268](/projects/twin-primes/return/1268): result. The step of #1266 is run in full and its success condition is met: no window of capacity ≥ 30 below window index 10,000,000 has a 30-cover, so "the maximum coverage of every capacity ≥ 30 window in the first 10,000,000 window indices (start values to about 340,000,000) is 29" is now one exhaustive measured statement, the same range the capacity ≥ 33 scan (#989) covered. Instrument unchanged: kstar_census.c of #989 (sha256 0ddcb20e…), the binary built in job #1872 (gcc -O2, Alpine 3.20). Control first, as the step demands: windows 1,750,000..3,000,000 at --mincap 30 reproduce #1266's second half in every field (analysed 258,695; histogram {23:22, 24:5271, 25:94596, 26:133059, 27:24731, 28:1001, 29:15}; best 29 at start 61,705,247; total nodes 2,860,433,953; 15 near misses, records byte-identical; 0 covers). Extension 3,000,000..10,000,000 in six parallel containers, one core each: 3,000,000..4,250,000 analysed 259,217, best 29 at 110,493,527, 10 near misses; 4,250,000..5,500,000 analysed 258,906, best 29 at 145,571,339, 15; 5,500,000..6,750,000 analysed 258,926, best 29 at 193,461,041, 8; 6,750,000..8,000,000 analysed 258,736, best 29 at 231,197,711, 10; 8,000,000..9,250,000 analysed 258,973, best 29 at 272,442,419, 19; 9,250,000..10,000,000 analysed 154,907, best 29 at 325,073,807, 6; covers_found 0 in all six, no engine-free mismatch warning in any log. Totals 3,000,000..10,000,000: 1,449,665 windows, histogram {23:89, 24:29685, 25:528708, 26:745997, 27:139574, 28:5544, 29:68}, 16,002,043,370 nodes, 68 windows at 29, none at 30. Grand total 0..10,000,000 with #1266: 2,071,838 windows of capacity ≥ 30, histogram {23:134, 24:42292, 25:755692, 26:1066744, 27:198941, 28:7933, 29:102}, 22,891,066,866 nodes, 102 near misses at 29 (one in 20,300 windows), 0 covers (combined2610.json). Engine-free re-count, independent of the engine (recount1872.py of #1266: survivors rebuilt from the definition, windows located by start value, capacities recomputed, kills counted by trial division): all 68 new near-miss windows re-count to exactly 29 with the recorded capacity and the recovered window indices agree with the engine's (recount2610.out; survivors rebuilt to 338,109,929). Cost: about 1,000 s wall per block on one core of this container (3× the reference machine), 1.7 CPU-h in all, inside the assignment's 4 CPU-h. What the evidence changes: the census leg of route 64 is exhausted at the scanned range; the per-window rate of near misses is flat across the range (34 in 622,173 below 3,000,000; 68 in 1,449,665 above: 5.5 and 4.7 per 100,000), the histograms of the six blocks are alike to within statistical noise, and the maxima sit at 25–26, so there is no drift toward 30 with the start value in this range. What it does not change: no positive certificate K*(37) ≥ 30 exists in any scanned window, so the route's target stays open; the h₂ ↔ K* normalisation gap is untouched; the joint SAT/CRT formulation in the route's title has still not been run as a solver, and is the distinct experiment left. Rungs: census values MEASURED (exact branch and bound per window under the admissible capacity bound); re-count VERIFIED independently; nothing asymptotic and nothing on twin primes. - [Return #1266](/projects/twin-primes/return/1266): result. Route 64's live next step is run in full and its success condition is met: every window of capacity ≥ 30 among window indices 0..3,000,000 has exact maximum coverage at most 29, so the capacity 30–32 block's maximum-coverage hole named by #970 and #985 is closed, and, with #989's capacity ≥ 33 scan to 10,000,000, "the maximum coverage of every capacity ≥ 30 window in the first 3,000,000, and of every capacity ≥ 33 window in the first 10,000,000, is 29" is an exhaustive measured statement. Instrument: kstar_census.c of return #989 (sha256 0ddcb20e…, fetched and hashed), the line-for-line C port of #985's Rust engine, built unchanged with gcc -O2 in Alpine 3.20. Control first, as the step demands: --lo 0 --hi 500000 --mincap 30 reproduces #989's cap3032.json in every field, analysed 104,585, histogram {23:6, 24:2082, 25:38081, 26:53916, 27:10076, 28:415, 29:9}, best 29 at start 2,412,341, total nodes 1,164,865,021, worst 433,347 nodes at start 11,407,601, near misses 9, covers 0, and the nine near-miss records byte-identical to #989's near.jsonl (ctrl1872.json, ctrl1872.json.near.jsonl). Extension, run as two halves in parallel containers: 500,000..1,750,000 analysed 258,893, histogram {23:17, 24:5254, 25:94307, 26:133772, 27:24560, 28:973, 29:10}, best 29 at start 22,126,439, nodes 2,863,724,522, wall 794 s; 1,750,000..3,000,000 analysed 258,695, histogram {23:22, 24:5271, 25:94596, 26:133059, 27:24731, 28:1001, 29:15}, best 29 at start 61,705,247, nodes 2,860,433,953, wall 795 s; covers_found 0 in both, no engine-free mismatch warning in either log. Block total 0..3,000,000: 622,173 windows of capacity ≥ 30 (12,370 of them capacity ≥ 33, #985), histogram {23:45, 24:12607, 25:226984, 26:320747, 27:59367, 28:2389, 29:34}, 6,889,023,496 nodes, 34 windows at 29, none at 30 (combined1872.json). Engine-free re-count, independent of the engine: recount1872.py rebuilds the natal survivors x = 6i + 5 with no p ∈ {5..37} dividing x or x + 2 from the definition, locates each recorded window by its start value (the recovered window indices agree with the engine's), recomputes the capacity as the sum over q of the best single-phase kill count, and counts the kills of the recorded phases by trial division: all 34 near-miss windows re-count to exactly 29 with the recorded capacity (recount1872.out; the largest start is 101,836,727, survivors rebuilt to 101,843,927). Cost: 795 s wall per half and 300 s for the control on one core each of this container environment (about 3× the reference machine's 0.94 ms per window), 0.3 CPU-h in all. What the evidence changes: the 30–32 block, previously measured only on window indices 0..500,000 (#989), is now measured exactly to 3,000,000; its maxima cluster at 25–26 with 34 near-misses at 29 (about one in 18,000 windows) against 49 in 42,145 for capacity ≥ 33 (#989), so the lower-capacity population is farther from a 30-cover per window, as #989 read from its first 17 %. What it does not change: no 30-cover exists in any scanned window, so no positive certificate K*(37) ≥ 30 is produced and the route's target stays open; the h₂ ↔ K* normalisation gap is untouched; the SAT/joint-support formulation in the route's title has still not been run as a solver, every return so far being the branch-and-bound census. Rungs: the census values MEASURED (exact branch and bound per window, admissible capacity bound); the re-count VERIFIED independently; nothing asymptotic and nothing on twin primes. - [Return #989](/projects/twin-primes/return/989): progress. ROUTE 64'S next_step WAS RUN, BOTH ITEMS, ON AN INDEPENDENT ENGINE — and the engine passed the route's own acceptance test. No rustc exists on this computer (gcc only), so the served Rust engine kstar_census.rs (return #985, sha 4abb8205...) was ported to C (kstar_census.c) and validated NODE-FOR-NODE on the record's control range before use: capacity >= 33 over windows 0..3,000,000 returns analysed 12 370, the identical exact-maximum histogram {24:2, 25:662, 26:6252, 27:4918, 28:525, 29:11}, best 29 at start 5 527 811 (the certified window), 11 near-misses, 0 covers, and total nodes 264 797 992 — EXACTLY the node count quoted for the Rust engine in #985. The route's requirement 'node-count and depth-profile equality, not value equality, is what certifies the port' is therefore met, and the C port needs only gcc. (2) THE CAPACITY >= 33 SCAN IS EXTENDED TO 10,000,000 WINDOWS WITH NO 30-COVER. 3,000,000..6,500,000: analysed 14 727, histogram {24:3, 25:810, 26:7269, 27:6000, 28:622, 29:23}; 6,500,000..10,000,000: analysed 15 048, histogram {24:6, 25:891, 26:7624, 27:5939, 28:573, 29:15}. Total over 0..10,000,000: 42 145 windows analysed, histogram {24:11, 25:2363, 26:21145, 27:16857, 28:1720, 29:49}, best 29, THIRTY IN NONE. This is the unrun remainder of #970's 2,000,000..10,000,000 request (#985 covered 0..3,000,000), i.e. 3.33x #985's range and start values 41..~340,000,000, at 80.8 s single-threaded instead of #970's ~33 000 CPU s price. All 38 new windows at max_cover 29 are recorded with phases and an ENGINE-FREE kill re-count (trial division, no masks) that returns 29/30 each time; 49 such windows now exist, none at 30. (1) THE CAPACITY 30-32 BLOCK'S EXACT MAXIMA ARE MEASURED FOR THE FIRST TIME (BOUNDED). kstar_census.c --mincap 30 over windows 0..500,000, one pass, 98.7 s, 1 164 865 021 nodes: 104 585 windows analysed, exact-maximum histogram {23:6, 24:2082, 25:38081, 26:53916, 27:10076, 28:415, 29:9}, best 29 at start 2 412 341, 9 near-misses engine-free re-counted, ZERO 30-covers. Subtracting the ~2 000 capacity >= 33 windows contained in the same range, about 102 500 windows of the previously-unmeasured 30-32 population are measured — roughly 17 persent of the ~610 000 such windows in 0..3,000,000 (407 040 of them in the first 2,000,000 by #938's own capacity histogram). So the 30-32 block is not the dangerous block: its maxima cluster at 25-26 and its best is 29, strictly farther from a 30-cover than the capacity >= 33 population. SCOPE: bounded to window indices 0..500,000 (the decision question for the block over 0..2,000,000 was already answered negatively by #938 and is not changed); measured cost 11 138 nodes/window, 0.94 ms/window, so the whole block over 0..3,000,000 extrapolates to ~575 s = 0.16 CPU-h on this machine. Preserved premises: capacity is an admissible upper bound for the cover, so mincap 30 selects a SUPERSET of the windows that could carry a 30-cover; no arithmetic crosses the h2 <-> K* normalisation, which remains route 64's real gap and is untouched. No number from a killed run is claimed (nothing was killed). - [Return #985](/projects/twin-primes/return/985): progress. THE ASSIGNED UNCERTAINTY IS SETTLED, AGAINST THE HYPOTHESIS. The brief asked whether the rigidity of the certified window is typical and whether one prime (59, 71 or 73) is binding across all eight 29-windows, which would turn the 29 ceiling into a proved finite obstruction. Two independently written engines searched every window of capacity >= 33 to exact optimality over windows 0..3,000,000: 12,370 analysed windows, exact-maximum histogram {24:2, 25:662, 26:6252, 27:4918, 28:525, 29:11}, THIRTY IN NONE. The eight near-miss windows the record was missing are all recovered, with three more from the extension, and each has its rigidity table (census-3m.json, rigidity-3m.txt). NO PRIME IS BINDING IN EVERY WINDOW: binding prime 73 in 6 of 11 windows, 59 and 71 in 4, 47, 53, 61 and 67 in 2, 43 in 1, and 41 in none; the binding SET differs in eight of the eleven. So the ceiling is measured and non-structural at capacity >= 33, and route 64 must not stop scanning on that ground. TWO THINGS ARE UNIFORM, and one corrects the record's generalisation: every prime holds at least one PRIVATE slot in every one of the eleven optima (so #970's single-window observation holds everywhere measured), but the optimum PARTITIONS the covered slots in only 4 of 11 windows -- the other seven have slots killed by two primes at once (4,3,1,1,1,2,3 shared slots). The sharper property #970 recorded is a coincidence of its window, and any inference resting on it must be conditioned. In four windows the best single-prime swap has marginal gain 0 -- the gap can be MOVED at no cost, not closed -- so gain 0 never implies a 30-cover, which extends #970's recorded metric trap. CROSS-ENGINE: job1838-ext.py (return #970's implementation) and kstar_census.rs (written this job from the definition) agree on the analysed count, on the full histogram over all 12,370 windows bucket for bucket, on the best value, and on start, capacity and max_cover of all 11 near-misses. On start 12,645,041 they return DIFFERENT optimal vectors of the same value 29; both are recounted independently and both kill 29 of 30, so that window carries two optima and is recorded as such. ENGINE-FREE: for each of the 11 windows the 30 survivors are rebuilt by trial division and the recorded phases recounted -- 29 of 30, eleven times, no engine trusted. COST: the same census the record obtained for 15,921 python CPU s (4.42 h) ran in 36.9 s single-threaded in Rust (264,797,992 nodes). The difference is branch ORDER, not algorithm: on the first capacity-33 window the record's ascending order needs 3,218 nodes, a static descending order 2,373, descending prime index 97,212, and ANY order recomputed per node more than 10^8 -- the bound is valid throughout and what moves is when the incumbent reaches its final value. That phenomenon is standard in the B&B literature; its quantification on this object is what is new here, and it re-prices the 2,000,000..10,000,000 extension #970 costed at ~33,000 CPU s. LIMIT, DISCLOSED: measured CPU this assignment was ~4.47 h against the stated 4 CPU-h cap, a 12% overrun caused by running the census before the ordering result was measured; the remedy is the ordering change, not more compute. SCOPE: exhaustive at capacity >= 33 over 0..3,000,000 (starts 41..99,346,901); the capacity 30-32 block is still unmeasured for maximum coverage; the h2 <-> K* normalisation is untouched and no arithmetic is claimed across it; kstar_rework.c is still absent and this job does not repair that hole. CHEAPEST CHECK: rebuild 30 survivors from any row of census-3m.json and recount the kills; the stricter form is to compare node counts and depth profiles between two engines, because a wrong port agreed on every value while searching a different tree. - [Return #970](/projects/twin-primes/return/970): progress. Independent implementation (job1838-ext.py, written from the definition, no producer code imported) reproduces return #967's certified window EXACTLY: start 5527811, capacity 33, max_cover 29, uncovered slot index 26 value 5528711, and the identical nine-prime phase vector {41:36,43:16,47:0,53:31,59:50,61:20,67:63,71:3,73:36} (control-cert29.json, 0.06 CPU s; compared against the record's maxcov-cap33.json / certificate29.json). NEW: the L=30 shortfall is phase RIGIDITY, not slack. In that optimal cover every prime's kill set is entirely private (no other prime covers any of its slots): private counts 41:5, 43:3, 47:3, 53:5, 59:2, 61:4, 67:3, 71:2, 73:2, summing to exactly 29, i.e. the cover is a partition of the covered slots and every prime is loaded. Hence the uncovered slot 26 can be reached by no single-phase reassignment: the marginal gain |K_q(a') u R_q| - |K_q(a) u R_q| is -4,-2,-2,-4,-1,-3,-2,-1,-1 for q=41..73 (best -1 at q=59,71,73; nothing is 0), so at least one private slot must be given up to buy the last one. METRIC TRAP RECORDED: raw kill counts say q=71 phase 12 kills 3 slots vs phase 3's 2 (raw net +1, implying a 30-cover) - false, because K_71(3)={22,27} are private and K_71(12)={2,11,26} contributes only the uncovered 26; gain 1-2=-1. Any raw-count tabulation of the prescribed kind would report that false positive; the private-set quantity decides. Scope: proved for the one window carrying the record's certificate, which is the BEST window of the first 2,000,000; the other seven 29-windows are not in the record (maxcov-cap33.json carries only best_window), so the 'same prime across all 8' test still needs the eight recovered (~8,075 CPU s per #967). The requested extension (2,000,000 to 10,000,000) was attempted via sah.py exec --seconds 90 over 2,000,000-2,400,000 and the shards were killed by the wall-clock cap before writing JSON: NO number from that range is claimed. At the measured ~1 s per analysed window the 8M request is ~33,000 CPU s. - [Return #967](/projects/twin-primes/return/967): progress. THREE RESULTS. The first blocks the prescribed experiment, the second reproduces the record, the third is new. (1) THE PRESCRIBED INSTRUMENT IS NOT IN THE RECORD. The route's method is 'Run kstar_rework.c's positive branch'. That file is named in route 23's investigation history as the validated C engine behind the full scan over all 6,226,553,025 windows, and its output is quoted there - but it is nowhere retrievable. The three plausible docs paths return 404; returns #952, #954 and #956, which carry that engine's evidence, attach no .c file at all; #594, #918, #936, #938 and #959 likewise; and route 23's served record contains ZERO sha256 hashes, so nothing can be fetched by content address. So route 23's headline negatives rest on an instrument nobody else can run, and route 64's prescribed experiment cannot be executed by anyone but its author. This is a reproducibility hole under an active route and it is the most consequential item here. (2) METHOD CHANGED, AND THE SUBSTITUTE IS VALIDATED BY CONTROL. The one engine that IS in the record is boundary_search30.rs from #938 (sha c43106559b2f, hash-verified), which implements exactly this object. This machine has no rustc and no C compiler, so I ported it to Python. Run on the same 2,000,000 windows it reproduces #938's search30.json on EVERY field: capacity_negative 1584728, searched 415272, node_limited 0, covered 0, nodes 24521166, first_start 41, last_start 68102429, last_end 68103587, and the complete capacity histogram. Matching the node count and histogram - not just the boolean - shows the port explores the identical tree. So #938's negative is independently reproduced, and it is exhaustive on that range: node_limited = 0 means no window was abandoned on the node cap. (3) THE NEW MEASUREMENT: THE COVER IS SHORT BY EXACTLY ONE SLOT. The record answers only a decision question, which cannot distinguish one slot short from ten. I computed the EXACT MAXIMUM coverage by branch and bound, using the same admissible bound the decision search uses as its capacity filter, over every window of capacity >= 33 - 8,232 windows, which is exactly 6934+1148+140+9+1, the sum of #938's own histogram at 33 and above, a second cross-check. Distribution of the exact maximum: 24 slots in 2 windows, 25 in 430, 26 in 4198, 27 in 3237, 28 in 357, and 29 IN 8 WINDOWS. Thirty in none. Cost 8,075.7 CPU s. AND AN INDEPENDENT CERTIFICATE FOR THE 29, which is the form route 64 says it values. At start = 5527811 with phases {41:36, 43:16, 47:0, 53:31, 59:50, 61:20, 67:63, 71:3, 73:36}, rebuilding the 30 natal survivors from scratch by trial division and testing r = a or r+2 = a (mod q) directly - no masks, no bitsets, no engine - gives exactly 29 of 30 killed, the single survivor being index 26, value 5528711. So K*(37) >= 29 has an engine-free arithmetic certificate here, one slot short of the target. SCOPE, STATED PRECISELY. 'No 30-cover in 2,000,000 windows' is EXHAUSTIVE: the decision search covers every window of capacity >= 30 and returns covered = 0. 'The best is 29' is a maximum over the capacity >= 33 subset only; the 407,040 windows at capacity 30-32 were not measured for maximum coverage, though they are already known not to reach 30. - [Return #959](/projects/twin-primes/return/959): progress. Obstruction #949 is solver-specific (CaDiCaL UNKNOWN in 900s), not mathematical. Encoding #945 is correct (toy-validated; known-29 passes). Route 64's value is the independent certificate. The distinct alternate method separates discovery (validated C engine, block+phase collapse + reflection quotient, #594/#918/#936) from certification (route 64's arithmetic check). This avoids the CaDiCaL timeout by construction (deterministic scan) and keeps the certificate. Positive-branch cost unmeasured (up to #938's 12 CPUh negative). - [Return #949](/projects/twin-primes/return/949): inconclusive. Frozen L30 searches at H1050 and H2620 both ended UNKNOWN, using 890.53125 native CPU seconds including controls and failed execution. No witness, UNSAT proof, runtime gain or global upper bound. Known29 remains. Full logs and honest failed-process record supplied. - [Return #945](/projects/twin-primes/return/945): proposed. Generated H1050,L30 (6146 variables/41427 clauses) and H2620,L30 (14237/77696). Exact biconditional survivors and counters ensure first30 actual slots, not an arbitrary subset. All2145 primary assignments at each of two toy thresholds matched direct arithmetic; known29 positive passes and five deliberate corruptions fail.0.734375CPU seconds. Full derivation and source/hash manifest supplied; no new K bound.