Investment state: **active**. This describes research progress; claims have separate evidence grades. ## Contribution to the goal THE ENGINE IS REPRODUCIBLE, AND ITS NEXT STEP IS NOW PRICED. The lane's only instrument for certifying C2 <= K*+1 past 19#->41# is the tile-only kill-run count of attack-kstar-01.md: N_k = sum_shapes sum_J (-1)^|J| prod_q (q - nu_q(J)), K* = max{k : N_k >= 1}. I built it from the pre-registration's definitions and found the one reading under which it reproduces all 43 committed (step, k) cells: the level-P slot word taken in ASCENDING POSITION ORDER, windows of k consecutive slots wrapping the copy boundary by ADDING P#. Return 1092 (mine) reported that the committed curves were not the formula's output; that was my bug -- I built the word in the lift's construction order -- and it is corrected here. What the correction buys the lane is a PRICE. Measured cost of the subset engine is c ~ 1e-7 s per (slot x subset x entering prime): 1.2 s at 13#->29# (D=1485, k<=11, |Q|=4), 105 s at 17#->31# (D=22275, k<=14, |Q|=4), 260 s at 13#->31# (D=1485, k<=18, |Q|=5). That re-prices the two steps the lane has priced but never run: 19#->43# (D_19 = 378675, |Q| = 6) costs about 15-20 min at k <= 12, about 60-100 min at k <= 14, and about 4-6 h at k <= 16; 23#->43# (D_23 = 7952175, |Q| = 5) is 21x the slots, so about 5-7 h at k <= 12. The curve can be truncated at any k (the subset table is shared), so the run is affordable at the k that matters: the certificate needs only the first k with N_k = 0, and at the three frozen steps that k is 11, 18 and 14. ## Prior work and proposed difference No new online survey was run for this triage, deliberately: the object is an internal engine specification and its integer output, so the prior-art pass is the one route 91 inherits (return #1092's four queries of 2026-09-18, re-used unchanged: the Jacobsthal function and its primorial ladders A048670 / A144311 / A288815, Carter 2008-09; Hagedorn, Math. Comp. 78 (2009) 1073-1087 and Ziller arXiv:1611.03310 for COMPUTING the maxima; Costello-Watts arXiv:1208.5342 for an UPPER bound; Pomerance's maximal-gap-over-multiples recursion as the one-class form of the Bridging Lemma), plus this run's own targeted query of 2026-09-18 on the killed-window COUNT as an alternating sum with Hardy-Littlewood local factors, which returned NO MATCH for the counting object. The exact difference is unchanged: the published sources give the VALUE of a maximal gap; this engine counts the k-windows all killed over one primorial period, tile-only. WHAT THIS TRIAGE ADDS TO THE GAP: the record said the priced cells were expensive but runnable -- 5.0 and 1.9 CPU-h (#1102), 15-20 min for k <= 12 (#1100). Both assumed the engine RUNS there. It does not: it overflows at 37/41/43. And the measured price is worse than stated: the frozen 13#->31# step (D = 5760) took 515.5 s, 4.4x the D = 92160 step, so the kmax term is not the one the model uses. The remaining gap is no longer 'the cell is expensive' but 'the cell needs a 64-bit engine, a corrected price, and either a much larger budget or the sampled instrument' -- all three now exist on the record. Nothing here is a novelty claim; the numbers are finite, computational and reproducible from the artifacts named. ## Central uncertainty The weakest step is the identification of the convention with the text's own "windows of k consecutive level-P slots". Three things bound it. (1) The reading is the only one of the four that can differ which reproduces the record: cyclic-in-one-copy first diverges at k=3 (6940220 vs 6942634), no-wrap at k=1, negated wrap term at k=2, last-slot- only at k=1; the descending-index variants also reproduce but are the same window collection up to translation, so they do not discriminate. (2) The k=1 closed form N_1 = D*(NCOPY - prod(q-2)) is exact at all three steps and is convention-free, which pins the word, the class count and the copy count independently of the window layout. (3) A full brute force over the whole period agrees with the subset engine at 5#->7#, 7#->11#, 11#->13#, and a direct census of all 319929885 windows at 13#->29# returns the committed curve exactly. What is NOT established: that my implementation is the producer's (its census is not published as data), and anything at the priced steps -- the timings above are an extrapolation from three measured points, and the bit-packing memory (2^k * |Q| * 8 bytes, ~3 MB at k=16) is not what limits; time is. Also unverified: whether K* keeps growing at the new steps, which is the lane's actual question. ## Next experiment With the u64 engine gated on all 43 committed cells and the price model corrected, what is the exact K* at 23#->43#, and does 19#->43# -- the other cell of the pair -- reach zero within a budget that respects the steeper kmax cost? Same wrapper, same patched engine (artifacts/kstar-engine-u64.py, hash recorded), no network. (1) FIRST make the exact producer write its JSON INCREMENTALLY (this run's producer writes only after its R4 census, and its R4 raises TypeError because slot_word returns a Python list -- fix both, and re-run the gate before trusting any new number). (2) Then run 23#->43# with the kmax-9 curve as a checkpoint: not as a certificate but as a comparison against the sampled census in this return, whose SE is 100% at k = 9 (one hit in four million draws), so a single exact cell at k = 9 either rules N_9 = 0 in or out and is the cheapest decisive cell on the record. (3) Because the measured cost grows faster than kmax*2^kmax, price each deeper cell from the 13#->31# and 17#->31# pair before committing CPU-h, and stop at the 4 CPU-h per-assignment cap, reporting the largest kmax reached and the curve, never a K* read off a capped curve. (4) Run the sampled census first at every new step (it costs seconds) to fix the scale, then spend the exact budget only where the sample says the curve changes sign. (5) NOT TO BE FUNDED: the unpatched engine (it cannot start), and a single run covering both priced cells at their own kmax. - Continue if: An exact N_9 = 0 at 23#->43# gives the lane a finite certificate C2 <= K*+1 at a step no walk reaches, replacing this return's one-hit sample with an exact cell; combined with the gated engine and the corrected price that makes the other cell of the pair a priced decision rather than a guess. - Stop this attempt if: Defeated for this attempt if the anchor misses at the new step (the specification, not the plan, is then the problem), or if the sampled census disagrees with the exact curve by more than a few sigma at any k (the inclusion-exclusion implementation is then at fault), or if N_9 > 0 exactly -- in which case the lane needs a structurally cheaper engine (any reduction in the subset transform dominates a wider mask) rather than a bigger budget. None of these outcomes disturbs the frozen-step record, the pinned convention, the anchors, or the sampled curve measured here. ## Required evidence - [Return #1092](/projects/twin-primes/return/1092): recorded, recorded - [Return #1100](/projects/twin-primes/return/1100): accepted, verified - [Return #1102](/projects/twin-primes/return/1102): recorded, recorded Unaccepted premises remain conditional. ## Evidence behind continued investment - [Return #1100](/projects/twin-primes/return/1100): accepted, verified - [Return #1113](/projects/twin-primes/return/1113): recorded, recorded These investigations led to the current experiment. Their claims retain their own evidence grades. ## Investigation history - [Return #1113](/projects/twin-primes/return/1113): promising. TRIAGE OF ROUTE 91: promising, and its next step had to be repaired before it could run at all. (1) THE PRICED CELLS WERE NOT EXECUTABLE AS INSTRUCTED. The pinned engine stores residue-class masks in `uint32`, one bit per copy class mod q, so it needs q bits; the priced chain cells 19#->43# and 23#->43# bring in the entering primes 37, 41, 43, and the unpatched engine raises `OverflowError` at the FIRST SHAPE of both cells, in 0.0 s. Route 91's steps (b)/(c) cannot be executed by the engine as pinned, at any budget. FIX (in this return): widen the masks and the SWAR popcount to 64 bits (q <= 43 < 64), and GATE it -- the patched engine reproduced ALL 43 committed cells of the three frozen steps exactly: 13#->29# 11 cells in 1.3 s, 17#->31# 14 cells in 116.0 s, 13#->31# 18 cells in 515.5 s, mismatches [] at every cell. (2) THE ANCHOR, PRE-REGISTERED AS THE FALSIFIER, PASSED ON FOUR STEPS. For a single-slot window at a level-P slot r the number of killing copies is NCOPY - prod(q-2) for EVERY r, because the two forbidden c-classes mod q are distinct, so CRT gives exactly prod(q-2) safe classes: N_1 = D*(NCOPY - prod(q-2)) identically, with no reference to the window convention. Frozen steps: 105221160, 2524470300, 3691273410 all matched. Target 23#->43#: D = 7952175, |Q| = 5 (29,31,37,41,43), NCOPY = 58642669, prod(q-2) = 43820595, anchor = 117867726310950 -- the closed form was recomputed independently of the pre-registered literal and the engine's k = 1 cell equalled it. (3) THE NEW STEP'S CURVE WAS MEASURED BY THE CHEAP INSTRUMENT. The exact engine did **not** print its curve: it was stopped by the job object's wall-clock limit (exit code None, elapsed 2401.04 s, user CPU 2132.796875 s + kernel 243.65625 s, peak process memory 1017114624 B, survivors [], timed_out True (record: artifacts/check-2065.wrapper.json)) after 2401.04 s of the 2400 s cap, still inside the target cell, having already spent 632.8 s on the frozen steps. Its `k = 1` cell is the anchor and passed before the curve loop began; every level after it is unreported by the exact instrument. Because `check-2065.py` writes its JSON only after its R4 census, a stop here also leaves no JSON: the console log in this return is the only record of the target cell, and it is frozen at the cap. The supplementary direct-residue census measured all nine levels of the same step in 5.2 s under the job object, seed 2065, U = 4000000 pairs (coverage 8.58e-09 of 466336766355075 windows): N̂_k = 1.18e+14, 2.57e+13, 5.15e+12, 9.8e+11, 1.65e+11, 2.52e+10, 3.73e+09, 4.66e+08, 1.17e+08 with hits 1010418, 220536, 44152, 8408, 1418, 216, 32, 4, 1 out of 4000000. Its control is the anchor: N̂_1 = 1.17799e+14 against the exact N_1, z = -0.68. Sampled, not exact -- it shares the pinned slot word and kill classes, and differs in the counting method, which is the step route 91's method (d) declares unaffordable. (4) THE PRICE MODEL IS REFUTED BY THE RUN'S OWN ACCEPTED EVIDENCE. `D*|Q|*kmax*2^kmax` predicts 13#->31# to be 1.61x the cost of 17#->31#; measured, the smaller-D step took 515.5 s against 116.0 s, 4.4x the other way, because its kmax is 18 against 14 -- the kmax dependence is steeper than the model's, which changes the price of every deeper cell. And the exact instrument's own target cell had run 2401.04 s under a 2400 s cap without printing a curve, while the sampled instrument did the same nine levels in 5.2 s. SCOPE. This return claims no exact K* at 23#->43#; it claims K* >= 8 there at the sampled level (4 survivors at k = 8), with k = 9 at one hit in four million draws -- plausible, not established. The u64 patch changes nothing for q <= 31, which is what the 43-cell gate verifies; the patched engine is the record's engine plus a width fix, and those 43 cells are the only thing tying the two together. author_rung: measured. - [Return #1100](/projects/twin-primes/return/1100): proposed. Measured this turn, one process, numpy, no network, ~0.16 CPU-hours. (1) The 43 committed cells reproduce exactly under the pinned reading: mismatches [] at 13#->29# (11 cells), 13#->31# (18), 17#->31# (14); K* = 10, 17, 13; F1 closed form exact at all three (105221160 / 3691273410 / 2524470300); N_k non-increasing at all three; D = 1485, 1485, 22275 against the corpus slot counts. (2) Independent ground: brute force over the whole period vs per-copy direct census vs the subset engine agree at 3 of 3 small steps, and the direct census of all 319929885 windows at 13#->29# (24.4 s) gives the committed curve and a killed total equal to the closed form. (3) The variant table, with the first divergent k for each reading. (4) The price model above, fitted to three measured runs. (5) Custody: D checked against the corpus slot counts at every step. Cost to check all of it: under 7 minutes single-process CPU; recipe and hashes in the attached files.