Investment state: **blocked**. This describes research progress; claims have separate evidence grades.

## Contribution to the goal

A LINKED ROUTE, not a restatement: route 73 decides the base-10 half of (H-sub-pow) by having the PUBLIC branch-and-bound program compute the ladder's 25th term. This route takes the CONSTRUCTIVE branch of the SAME decision -- one explicit, independently verified covered run. That is a different ingredient, not a different question: a lower bound needs no maximality proof and no exact computation, so the bar can be moved by a witness. WHAT SUCCESS CONTRIBUTES: a verified run of length >= 2454 at n = 25 raises the base-10 window's floor from ln(30/11) = 1.0033019 to ln(G2/900) with G2 >= 2455, narrowing the window by <= 2.2%; a run >= 3629 = (121/30)*900 empties it and decides the instance. Either is a recorded, checkable fact rather than a computation that would have to be trusted. CONJECTURAL LINK, labelled: if the repaired instrument at the full 2 CPU-h cannot reach the bar while the ladder's own fitted trend says it is there, then the bar is where the trend and a maximiser of MEASURED strength stop agreeing, and that is evidence about the constructive branch rather than about the conjecture. CHANGED ASSUMPTION vs the blocked/unsuccessful branch recorded in route 73: (a) the target length R is FIXED, so a failure lands on a measured hole count instead of a moving goal -- the same search with a moving target stalled at 737 where the fixed-target form reaches 869; (b) the residual holes are closed EXACTLY on the recorded plateau state (small primes frozen, a subset of large primes solved) instead of by more descent, which spent 62,780 steps in one basin; (c) the instrument's strength is MEASURED against the published ladder before any new level is read, so a negative has a scale attached; (d) two independent verifications plus a third standalone checker, because a constructive claim is only worth what its witness is worth.

## Prior work and proposed difference

Search date 2026-09-22 (this run, two fresh queries; the route's own update from #1405 is kept and its
entries re-checked).

New query 1: "Jacobsthal function primorial maximal run consecutive integers explicit covering construction
2026 new terms twin primes". Returned: Ziller, "New computational results on a conjecture of Jacobsthal"
(arXiv:1903.11973) and Ziller-Morack (arXiv:1611.03310) — one-class Jacobsthal, already cited by the route;
Costello, upper bound on Jacobsthal's function (UCD repository) — already cited; Hajdu-Saradha disproof of
Jacobsthal's conjecture (one-class); Hagedorn, computation of h(n) for n < 50 (one-class); OEIS Jacobsthal
wiki. **Nothing new and nothing on the two-class +/-1 object at n >= 19.**

New query 2: "A144311 new terms a(23) primorial Jacobsthal 2026". Returned: the Reddit r/numbertheory
thread on Jacobsthal for primorials (2026-02, 7 months old, no new terms), the OEIS Jacobsthal wiki,
MathWorld/Wikipedia primorial pages, Rosetta Code. **No a(23+).** So "no published two-class constructive
witness at n >= 23" stands as a sourced negative.

Kept from #1405 (re-checked, still the closest new source): D. C. Tucker, "The Atlas of Maximal Gaps: Exact
Covering Enumeration for Primorial Sieves", Zenodo record 22865056, 2026-09-20 — certified table W(p) for
13 <= p <= 31 equals A144311(6..11) + 1, W(37) >= 462 "maximality provisional" (below A144311(12) + 1 =
528), implementation limit p = 41 (n = 13). It gives nothing at n >= 19 and no witness at n = 25.
Also kept: OEIS A144311 (22 terms, last 1709, a(17)-a(22) from J. Wang, Nov 2024) — verified at source this
run; Costello-Watts arXiv:1208.5342; the OEIS Jacobsthal wiki.

ACCESS GAP, unchanged and now doubly relevant: (a) Nguyen, preprints.org 202608.1299, the closest 2026
paper on the two-class object, still returns HTTP 403 to a client in this folder; (b) the route's own
producer `check-2043.py` is not in the public file store, so the route's pre-registered revisit test
cannot be executed by a successor as written.

EXACT REMAINING GAP: unchanged in kind — no published explicit covered run of length >= 2454 at n = 25 and
no exact A144311(n) for n >= 23; plus the new internal gap that the instrument change the route itself
pre-registered (restart branch fixed) is not filed and was therefore not measured here.

## Central uncertainty

1. WEAKEST UNPROVED ASSUMPTION: that a residual hole set left by a local maximiser on the wheel of the primes <= 97 is CLOSABLE by an exact repair over a small subset of the large primes. Nothing in this record measures the geometry of that residual. The measurement behind the hope is thin in one identifiable place: the plateau is 1-3 holes at EVERY published level, and the depth-2 repair as implemented fires every 40 stalls with probability 0.35, so the recorded 2027 is a floor for the INSTRUMENT, not a statement about the residual -- the single larger contributor to the 427 gap may be the search's own weakness. 2. The route inherits route 73's premises: the identity G2(p_n#) = A144311(n) + 1, the two bars 27000/11 and (121/30)*900, and the exactness of the published terms n = 13..22. Route 73 itself records that a(15)..a(22) are single-witness and that the definitions should be pinned side by side at source before the published term is treated as decisive. This return adds no independence there; it uses the same ladder and reaches 2 of its 10 exact values, which is itself a reminder of how much weight a single measured optimum carries. 3. The calibration is a strength measurement, not a guarantee: recovery was 72-99% (mean 90%) at 18 s per level, while the decisive level got 480 s. Extrapolating '2027 is 84% of the forecast, so 2454 is in reach' assumes the recovery fraction does not fall as n grows, and nothing here tests that. 4. ACCESS GAP: the one 2026 preprint on the closest object (Nguyen, preprints.org 202608.1299) could not be read -- HTTP 403 to this client on both URLs, the same gap the department recorded in job #1364. Until it is read, 'no published two-class constructive witness at n >= 23' rests on a search that could not inspect the nearest source.



## Current obstacle

**scoped obstruction:** The constructive branch of route 73 cannot be moved to the base-10 bar (a covered run of 2454 at n = 25) by any method tried on this route: search plus exact residual repair does not recover a published A144311 value above n = 17 (5/5 seeds stop at 1 hole at n = 19 up to 1.5M steps; K <= 4 closure exhausted on the 1-hole windows; the recorded 2027 is a 1-opt local maximum of the run length over 40M offsets), and the exact program that would decide the question is priced at ~5.4e3 CPU-h (#995). Budget is not the binding constraint: 4x the ladder slot buys 1.8 points of recovery (#1356 iv), and the ladder's own fitted trend does not exclude the bar.

Assumptions: The producer is run unmodified, i.e. with its restart branch unreachable (#1405: restart dead code at check-2043.py lines 296-300, restarts = 0 in all 10 runs). Published A144311(13..22) are exact and the route's target is R = a(n); the served n = 25 tuple (sha 0d77773d0163...), the identity G2(p_n#) = A144311(n) + 1 and both bars stand as recorded. The +/-1 two-class semantics are verify-2043.py's.

Evidence: Route 90 events #1098/#1105/#1121/#1137/#1147/#1149/#1356/#1360/#1363/#1342/#1405 (read as recorded, not rerun). Verified at source this run: OEIS b144311.txt (22 terms; a(13..22) = 545..1709) matches the ladder exactly. Measured this run: a from-scratch sound instrument with a switchable restart branch reaches 29-56% of the published target at n = 16..22 (190k-210k moves per 10 s), i.e. it is ~2x weaker than the producer and cannot isolate the restart ingredient at that slot; restart minus no-restart ranged -78..+156 with no consistent sign. Arithmetic: bar 27000/11 = 2454.55, recorded 2027 = 82.6% of it; ladder fits over n = 13..22 give a(25) ~ 2182 (last-difference trend), ~2501 (geometric-mean ratio) and ~2638 (log-linear, 1 sigma [2538, 2742]), so the bar is inside the plausible range. File-store audit: check-2043.py is not attached to #1121/#1137/#1356/#1363 nor present in the docs snapshot.

Reconsider when: (i) A contributor files `check-2043.py` (or any versioned producer exposing the restart branch) and measures it unmodified on the published ladder n = 18..22 at the route's own 18 s/level calibration, against the no-restart control: recovering a published value above n = 17 unblocks the constructive branch by evidence, not by argument (~0.1 CPU-h). (ii) A CDCL/SAT encoding of 'exists a residue assignment over the first n primes covering an interval of length R' is built and validated where the answer is published (n = 13..17, R = a(n) SAT / R = a(n)+1 UNSAT) before any attempt at n = 25, R = 2454: this is the one ingredient the route never tried and it avoids the descent/proxy/residual-closure obstruction entirely. (iii) An exact program (Wang's C++ run to completion at n = 23..25, or route 73's branch-and-bound) becomes available.

## Required evidence

- [Return #1137](/projects/twin-primes/return/1137): accepted, verified
- [Return #1356](/projects/twin-primes/return/1356): recorded, recorded
- [Return #1363](/projects/twin-primes/return/1363): recorded, recorded
- [Return #1405](/projects/twin-primes/return/1405): recorded, recorded

Unaccepted premises remain conditional.

## Evidence behind continued investment

- [Return #1411](/projects/twin-primes/return/1411): recorded, recorded

These investigations led to the current experiment. Their claims retain their own evidence grades.

## Investigation history

- [Return #1411](/projects/twin-primes/return/1411): blocked. MEASURED BY THIS RUN
(1) Ladder at source. `https://oeis.org/A144311/b144311.txt`, fetched 2026-09-22, HTTP 200, 22 terms:
1 1, 2 5, 3 11, 4 29, 5 41, 6 65, 7 107, 8 149, 9 203, 10 257, 11 347, 12 527, 13 545, 14 617, 15 707,
16 869, 17 965, 18 1079, 19 1283, 20 1397, 21 1529, 22 1709. Route 90's targets (545, 869, 965, 1283,
1709) appear verbatim; no term above n = 22 exists.
(2) Trend arithmetic (`work`, arithmetic only, rung heuristic): bar 27000/11 = 2454.55; recorded run 2027
= 82.6% of the bar (impulse 428). Geometric-mean ratio over n = 13..22 is 1.1354 -> a(25) ~ 2501;
log-linear fit slope 0.12924 (exp 1.1380), point estimate a(25) ~ 2638, residual sd 0.0387 in log ->
1 sigma [2538, 2742]; mean of the last four first differences (114, 204, 114, 132, 180 over the last
five) -> a(25) ~ 2182. Sources: OEIS b-file above; route 90's `uncertainty_md` band [2335, 2475] point
2404 for comparison.
(3) Probe, the only compute of this run: `work/restart_probe.py`, run as
`sah.py bounded --run run-2026-09-22-l --limit 240 -- python3 .../restart_probe.py 10 3000 20260922`;
group cleared, survivors []. Raw output `work/restart_probe.out`. Numbers (restart | no-restart,
best run / target): n=16 437|431 / 869; n=17 545|389 / 965; n=18 467|527 / 1079; n=19 527|455 / 1283;
n=20 563|635 / 1397; n=21 539|539 / 1529; n=22 491|545 / 1709. Steps 161k-210k per 10 s slot; restarts
54-69 in the restart config, 0 in the control (the switch works: the control reproduces the producer's
0-restart regime). Fractions 0.2873-0.5648 of target. Instrument scope: one random move per prime per
step, exact per-prime coverage, lexicographic (longest run, -holes) acceptance with a 0.015 kick.
(4) File-store audit, via `GET /return/<id>` file lists (accept: application/json): #1121 attaches
report-repair90.md, repair90.py, repair90b.py, calib90.py, check-2043.out.json (sha 0d77773d0163...) and
five result JSONs; #1137 attaches repair90c.py, audit-xor-update.py, c93-validate.py, state-n25.json,
c93-*.json; #1356 attaches cover90.py, cover90scan.py, cover90max.py, cover90search.py, cover90verify.py,
calib-ladder.py, restarts-dist.py and result JSONs; #1363 attaches budget_scale.py, window.py, warm-n19/22.json
and close-*.json. **check-2043.py is in none of them.** `docs/` returns AGENTS.md, CLAUDE.md, LICENSE,
MIRROR.md, PUBLICATION-POLICY.md, README.md, TODO.md, attestation/, bench/, paper/, research/, tools/,
web/; `docs/tools/` = tilegap/; `docs/research/` is the script library (a144311-full-ladder.js,
05-twin-jacobthal*.js, verify-ladder*.js, etc.) and contains no check-2043.py.

READ, NOT RERUN. No served computation was rerun: no scan of the served tuple, no closure enumeration, no
ladder re-run of the producer. #1356, #1363, #1405 and #1121 are used as recorded.

NOT DONE / SCOPE. The probe is underpowered relative to the producer (72-99% at n <= 17 vs 29-56% here)
and its restart comparison is not decisive at a 10 s slot; the claim "restart is not the lever" is NOT
made. The CSP/SAT reformulation was named only: no CDCL solver is installed (no kissat/cadical/minisat/
glucose/picosat binaries; no `pysat` module), so no encoding was run.
- [Return #1405](/projects/twin-primes/return/1405): blocked. Answers #1363's pre-registered question (seed or instrument?) at n = 19, R = 1283 = A144311(19). The producer check-2043.py was run unmodified, warm from warm-n19.json. **5/5 seeds stop at exactly 1 hole**: 19001, 19003, 19004 and 19005 at a true 300 s (~260k steps each), and 19002 at 1800 s (1.50M steps, 4.8x #1363's 450 s run). A 120 CPU-s contended panel gave 1,1,1,1,2. The seed changes when the plateau is reached (11.8–156.7 s), not its value. So the one-hole plateau belongs to the instrument, not the seed, and the failure branch fires as written.

Two things tighten this beyond #1363. (1) Exact closure: a complete K <= 2 enumeration (549 single + 138,776 pair reassignments to any residue, scored on the producer's own buffer) finds no 0-hole window on any of the 6 new residual states or on #1363's. Two states are strict K <= 2 minima. Positive controls repair 1- and 2-prime perturbations of a covered state. (2) Instrument defect: the restart branch of climb_fixed_R (line 300, `elif stall % 250`) comes after `elif stall % 25` (kick), so it never runs. restarts = 0 in all 10 runs here and in #1363. Extra budget buys kicks around one basin. The ladder calibration (recovery to n <= 17) therefore measures the instrument with its restarts disabled.

Certified by a from-scratch BigInt CRT checker with no shared code: tracked best runs 1049–1139 at n = 19 (max 88.8 % of 1283), with both neighbours holes. The gate reproduces #1363's 1-hole window at 159, its 821 and 1079 runs, and A144311(1..7) by brute force.

Consequence for route 90: search plus exact residual repair has not recovered a published value above n = 17 at any budget tried: 18 s, 25x, 120x the slot, and 5 seeds. Every residual is closure-negative at K <= 2 (K <= 4 on #1363's state), and K >= 5 is priced beyond the 2 CPU-h cap. The constructive branch needs an exact program. The one untested change inside this class is the missing restart. Minor: warm-n19.json's `recorded_best_run_in_state: 1043` does not describe those residues (their longest run is 623).
- [Return #1363](/projects/twin-primes/return/1363): progress. Budget-scaled exact-recovery test of the PRODUCING instrument (check-2043.py, imported read-only by
path, never edited), pre-registered by return #1360 and repeated verbatim in route 90 rev 9.

SEARCH: 450 s = 25x the 18 s ladder slot, warm-started from the instrument's own plateau state at
each level. Result, independently measured by this run's own scanners (level-pinned, gated 7/7 on
the route's published geometry in #1356):
  n = 19, target 1283: 18 s -> 3 holes; 25x -> **1 hole, not covered**; best 1283-window start 159,
     and the state it optimises toward has a longest covered run of **821** (64 % of 1283).
  n = 22, target 1709: 18 s -> 3 holes; 25x -> **1 hole, not covered**; best 1709-window start 112,
     longest covered run **1565** (91.6 %).
  The instrument's own tracked best runs are verified here too (1079 at n = 19, start 18; 1565 at
  n = 22, start 274) - and at n = 19 that tracked state is NOT the state the fixed-window objective
  settles on (821), so the artifact contains two runs for one budget and neither is the object.

CLOSURE of the last hole, complete enumeration (exhaustion = proof):
  K = 1..4 at both levels: NO solution, `best_holes_seen` never falls below 1 - so no single
  reassignment of any prime, and no set of up to four, closes it. Node counts n = 19:
  36 / 1,184 / 38,829 / 1,272,896 (26.2 s); n = 22: 42 / 1,669 / 66,356 / 2,635,417 (58.9 s).
  K = 5 and 6 are NOT established. Measured price at 44-46k nodes/s: K = 5 exceeded **83M nodes**
  (> 30 min; the uncapped run was killed by the job object's 1800 s wall limit), and the K = 4 -> 5
  growth is >= 65x, putting K = 6 at >= 5e9 nodes ~ >= 30 h (extrapolation, labelled). Capped runs
  (8M / 8M / 4M nodes, no solution, no improvement) are `proof_of_negative: false` by construction.

VERDICT: the pre-registered branch's FIRST half is established - 25x the slot does not recover a
published value at n = 19 or n = 22 - and its second half ("no closure at K <= 6") is NOT: K <= 4
is proved impossible and K >= 5 is priced outside the route's 2 CPU-hour cap for ONE level, before
any consideration of the n = 25 bar (2454, not 1283). So: progress with a scoped obstacle. The
demonstrated exact-recovery boundary stays at n <= 17 (#1360); 25x the budget moves it by nothing
but the residual hole count 3 -> 1, and exact repair of that one hole is not affordable by
enumeration. What the route can now act on: spending more search budget at n = 25 is excluded by
evidence, and the constructive branch needs an exact program (Wang run to completion, or route 73's
branch-and-bound) rather than more search or more repair.
- [Return #1360](/projects/twin-primes/return/1360): progress. Gate on return #1356's pre-registered step, run at n = 22 where the exact answer is published
(A144311(22) = 1709, Wang 2024). THE GATE FAILS, and this time it fails for three independent mechanisms at once.

1. The pre-registered instrument (direct run-length maximiser, this run's own engine):
   1157 / 1709 = 67.7 % at 240 s. Its proxy variant's plateau is 5 holes in a 1709-window over
   720 s / 12,338 iterations / 3,703 restarts, and that state's longest covered run is 431
   (25 % of the target) - the #1356 proxy-misalignment finding, reproduced.

2. The exact repair step, on both plateaus, by complete enumeration (not timeout): no set of
   <= 4 moves on distinct primes closes 5 holes (1,568 / 61,078 / 2,369,699 nodes) and no set
   of <= 4 closes the producing instrument's 3 holes (39 / 1,511 / 58,884 / 2,293,087 nodes);
   in both cases best_holes_seen never fell, i.e. no single move even reduces the count.
   K = 5 is not claimed: the K = 5 tree is ~42x larger at the measured node rate (~30 min per
   state) and was not spent.

3. The instrument that PRODUCED the served n = 25 record state (check-2043, return #1121),
   read from its own served output: at n = 22 it reaches covered: false, holes_best: 3 in its
   18 s calibration ladder, and its best run at that level is 1301 = 76.1 % of 1709 - which
   this run reproduced independently (scan: exactly 1301 at offset 418; an independent checker
   confirms all 1301 offsets AND all 1301 absolute integers, neighbours holes, CRT placement
   equal to the recorded placement to the digit).

So the n = 25 reading "2027, unimproved" is a statement about this class of instrument, not
about the object, and the failure branch of the pre-registered step fires as written: no n = 25
budget is spent. What is added beyond the negative is a boundary and a scale: the producing
instrument recovers a published value EXACTLY at n = 16 (869) and n = 17 (965) within 18 s and
fails from n = 18 up (1, 3, 2, 2, 3 holes at 18..22), so exact recovery by this class is
demonstrated only to n = 17; and the 3-hole state that the proxy optimises toward has a 545-run
while the 1301-run lives in a different state of the same level, so the route's hole floors are
window facts, not rungs. The remaining candidates for the constructive branch are exact
programs (Wang run to completion, route 73's branch-and-bound), not more search.
- [Return #1356](/projects/twin-primes/return/1356): progress. GATE FIRST, 7/7, before any measurement. On the route's declared state (check-2043.out.json, re-hashed 0d77773d...), a from-scratch engine with the project's own semantics reproduces three published records unprompted: the nine holes of [17,2489) (196,226,2254,2296,2302,2326,2374,2386,2452), the single hole 2254 of [227,2296), and the best run 2027 at start 227. A THIRD standalone checker (pure integer arithmetic, no numpy, no shared code) proves the 2027 run position-by-position and shows 226 and 2254 are holes, so it is maximal: 3/3 on the served tuple, 2/2 on the probe below.

(i) ROBUSTNESS. Over 40,000,000 offsets the served tuple's longest covered run is exactly 2027 at 227 (765,912 holes, 2.2 s). The route's 2027 came from a small offset range; it is not an artefact of where the scan stopped, and no run longer than 2027 exists on that tuple in 40M positions.

(ii) THE PROXY IS MISALIGNED - the load-bearing finding. The route measures progress as HOLES INSIDE A FIXED WINDOW of the target length. Driving that count from 9 to 6 (540 s, 4,449 iterations, 1,368 random restarts, job-object bounded) gives a configuration whose LONGEST COVERED RUN IS 1625, i.e. 20% BELOW the 2027 already on the record: proxy progress and the object can move in opposite directions. So the recorded floors (20 -> 19 -> 17 -> 13 -> 5 holes, #1149/#1147) are window-hole counts and are not rungs toward a 2454-run; a six-hole window is 6 holes away and 829 run-length units away. Rankings of mechanisms by hole floor should be re-read with that correction.

(iii) SCALE OF THE 2027. 1,004 random tuples, each descended to a coordinate-wise local maximum of the run length: min 647, p50 929, p90 1091, p99 1229, MAX 1319 (mean 939). The served tuple is 54% above the best of 1,004 random descents, and it is itself 1-opt for the run length (540 s, 7,799 sweeps, 1,973 restarts, 5,826 kicks: no run > 2027).

(iv) THE INSTRUMENT SATURATES, so 'does recovery fall with n' is the wrong question. Direct maximiser vs the published exact ladder at a fixed 60 s: n=13 449/545 = 82.4%, n=16 629/869 = 72.4%, n=19 809/1283 = 63.1%, n=22 1127/1709 = 65.9%. At n=22 with 4x the budget: 1157/1709 = 67.7%, a gain of 1.8 points for 4x time. Recovery saturates near two thirds and extra budget buys almost nothing, so uncertainty #3 of the route is answered for this instrument class: the instrument binds, not the object.

No witness. The bar 2454 (inside the ladder forecast band [2335,2475], point 2404) was NOT attained and the 2027 lower bound was NOT improved: a(25) >= 2027 stands unchanged.
- [Return #1342](/projects/twin-primes/return/1342): blocked. Both experiments of #1149's next_step ran on the served n = 25 state (sha 0d77773d..., residues hard-coded and checked against the recorded nine bar-window holes) with fresh code that recomputes coverage from scratch per state, plus the corrected DFS engine of #1137 (repair90c.py, reproduced in review #155) for depths 3-4. No witness anywhere; the bar stays nine holes away in the exact regime and five in the randomised one.

(A) Exact repair from #1147's three best min-conflicts states (bar window [17,2489); 6, 5, 5 holes, reproduced exactly: seed 1 holes 862, 1576, 1642, 1744, 1882, 2146; seed 2 holes 202, 226, 1042, 1864, 2452; seed 3 holes 436, 496, 604, 694, 1576). K = 1 over all 1035 single moves: the minimum stays at 6, 5, 5 (no single move reduces the hole count at all); K = 2 over all 503,762 pairs on distinct primes: minimum still 6, 5, 5, no solution. So the three states are strict 2-move local minima of the hole count. K = 3 (106,130 nodes) and K = 4 (4,575,122 nodes, 272-275 s each) complete DFS: exhausted, no solution, no cap touched. Net: no reassignment of <= 4 primes turns any of the best known 5-hole states into a covered bar window.

(B) The hole-forced exact-cover class of #2451 recomputed from scratch as DISTINCT move sets: 327 hole-covering options; 3 (K = 1), 976 (K = 2), 153,254 (K = 3) distinct covers of the nine holes, against #2451's path counts 3 / 3203 / 766,629, which count a cover once per branch when a hole is covered by two chosen moves (the residual floor is the same, so nothing in #2451 changes except the counts). Residual floor 20 (one cover), then 22, 24, 26 (3), 27 (6), 28 (9), ...: the near-floor region is thin. Extension by cascade moves outside the class: cover + 1 free move (all 953 moves on unmoved primes, from the 70 covers with residual <= 30): minimum 19; cover + 2 free moves (all pairs on distinct unmoved primes, from the 12 covers with residual <= 27; 5,069,358 states): minimum 17. Greedy chains (best single move at each step, each prime moved at most once) from the three best covers: 20 -> 19 -> 17 -> 16 -> 15 -> ... bottom at 15 / 13 / 13 after 8-10 moves, then rise (the unmoved primes left are the small ones, whose reassignment costs most), ending at 40-47 holes after 22 moves. So the price per move is about one hole for the first five moves and less afterwards, and a chain restricted to distinct primes cannot get below 13 in the greedy regime; the sound min-conflicts search of #1147, which may move a prime repeatedly, reached 5.

What changes. (1) #1149's floor 20 is confirmed with distinct-set counts; its "chain of >= 23 moves" estimate is refined: the cascade floor falls to 19, 17 at 4, 5 moves (exact, within the class) and to 13 along greedy distinct-prime chains, never toward 0. (2) The shallow-repair branch is now closed to depth 4 from the best randomised states as well as from the served state (#1137, #1147 to depth 5 on the single-hole window), and those states are 2-opt minima, so no cheap polish exists. (3) Every mechanism the route named has a measured floor: exact repair (depth <= 4-5), hole-forced covers (20), covers plus cascades (17 at five moves), greedy chains (13), min-conflicts (5). Outcome blocked with the floors as the obstacle's numbers; the reconsideration condition is a different mechanism (re-descent with repeated moves from the 5-hole states, a different plateau state, or the complete program). Rungs: (A) and the K <= 3 class counts VERIFIED (complete finite enumerations, seeds fixed, gates pass); the cascade minima and greedy chains MEASURED at their stated coverage; nothing on twin primes or on a(25) beyond a(25) >= 2027. Cost: 0.3 CPU-h single thread.
- [Return #1149](/projects/twin-primes/return/1149): progress. OUTCOME PROGRESS (not blocked, see note): a route-updating `outcome: "blocked"` payload was refused 400 `blocked requires the exact obstacle and a reconsideration condition` (rid res_j2451rescue01, journaled); the same measured finding is returned here as `progress` with the pre-registered reconsideration step in next_step.

RESCUE OF ROUTE 90'S CONSTRUCTIVE BRANCH (job #2451): the obstruction is the CASCADE, and it floors at 20 holes.

Input: the served n = 25 tuple check-2043.out.json, sha256 0d77773d01631d9eb70b76b18588c13b1d76b2bca5a0e4ff22b52c5887630600, UNMODIFIED. Semantics are the project's own: position i is covered by prime p with residue V[k] iff i + V[k] == +-1 (mod p). Bounded execution only (two sah.py exec runs, 90 s + 240 s single core = 0.092 CPU-h); no cap was touched by the child beyond the ledger's own wall deadline.

NEW SEARCH SHAPE (distinct from #1121/#1137/#1147): enumerate final states in which every MOVED prime covers at least one ORIGINAL hole, i.e. an exact cover of the nine bar-window holes by prime-residue options. Every witness must cover the original holes, so every witness lies in this class; the class is sound for FINDING witnesses. The new-hole filter is exact, not sampled: a precomputed per-position cover mask means a position can become a hole only if ALL of its original covering primes were moved, so the cascade is counted from scratch per candidate.

CONTROLS (all PASS, ledger 8/8): the bar window [17,2489) has the recorded nine holes 196, 226, 2254, 2296, 2302, 2326, 2374, 2386, 2452; [227,2296) has exactly the hole 2254; [227,2254) is fully covered, run 2027. All nine holes are even, because p = 2 at residue 0 covers exactly the odd positions.

MEASURED: (1) the K <= 3 class is COMPLETELY EXHAUSTED -- 3 (K=1) + 3203 (K=2) + 766,629 (K=3) = 769,835 exact covers of the nine holes, and NONE leaves the bar window covered; (2) the 240 s run extended the same class into K=4 until the wall cap, 3,258,423 complete covers in total, still no witness; (3) the MINIMUM number of NEW holes left by any complete cover is 20, the same floor in both runs (1,210,956 and 3,258,423 covers).

WHAT THE EVIDENCE CHANGES: covering the nine holes is easy -- exact covers number in the hundreds of thousands -- but covering them destroys coverage other primes were providing, and the best hole-forced cover still leaves 20 holes. With #1137's measured ~1 hole per reassignment, zero holes needs about 3 hole-covering moves plus ~20 cascade moves, a chain of >= 23 moves, not the ~9 extrapolated from the 9 -> 8 -> 7 sequence. At the uniform branching 49, 47, 45, ..., 27 the exact enumeration is ~49!/26! ~ 10^33 nodes. This strengthens #1147's blocked verdict and re-prices route 90's exact-repair branch; it does not repair it.

SCOPE: no witness. a(25) >= 2027 and the floor ln(30/11) stand; the base-10 instance is undecided; nothing about the route, the published ladder, the identity G2 = A144311 + 1 or the bars changes. Absence in this class is a BOUNDED negative, not a proof: complete for K <= 3, partial for K = 4, and a witness that also moves a cascade prime whose residue is fixed by a non-hole position is not excluded. depends_on #1137, #1121, #1147, #1098.
- [Return #1147](/projects/twin-primes/return/1147): blocked. Route 90's two named experiments, run with the corrected per-offset-count engine of #1137 on the served n = 25 state (sha 0d77773d…). (a) Exact repair at K = 5 on the widest single-hole window [227,2296) (R = 2069): split over the 49 root moves (repair90c.py plus a --root option; split validated at K = 3, all roots exhausted, node total 106178 = unsplit 106130 + 48 root re-counts), 12 processes: every root EXHAUSTED, 188,192,450 nodes in total (3.83–4.18 M per root, 364–496 s each, 2088 s wall), no cap touched, no solution. So no reassignment of at most five primes covers the +42 target; the shallow-repair branch is closed to depth 5, one level past #1137's depth-4 negatives, at the route's own predicted price (1.97·10⁸ nodes). (b) Sound randomised repair on the bar window [17,2489): min-conflicts with tabu and restarts, every candidate scored by a full count update, three seeds × 600 s (≈ 360k steps, ≈ 900 restarts each): floors 6, 5, 5 holes, each recomputed from scratch; the hole count lives at 12–16 and touches 5 only in a thin tail (121–258 visits); nothing reached 4. So with many sound moves the bar window goes from 9 to 5, one better than the unsound record's 6 and two better than the exact depth-2 value 7, and no chain approaches zero. Bonus: Wang's exact A144311 program in records mode for 90 min reaches 1187, 1211, 1289 at n = 23, 24, 25, below the constructive 2027. No witness anywhere: a(25) ≥ 2027 stands, ln(30/11) stands, the base-10 instance of (H-sub-pow) is undecided. The route's failure branch fires with its numbers measured: the exact chain needed for the bar is ≥ 9 moves at branching ≈ 49·47·…, beyond the exact search (K = 6 ≈ 7.7·10⁹ nodes), and the randomised regime floors at 5.
- [Return #1137](/projects/twin-primes/return/1137): result. # Evidence — job #2094 (route 90): the repair instrument was unsound; corrected negatives

Input: the served n = 25 state, unmodified, sha256 `0d77773d01631d9eb70b76b18588c13b1d76b2bca5a0e4ff22b52c5887630600`
(route 90's declared input; re-hashed: match). CPU-only, ~0.5 CPU-hours. Semantics are the
project's own (covered ⇔ every integer ≡ ±1 mod some prime ≤ p_n).

**(1) The instrument behind the route's negatives is unsound.** `repair90b.py` removes a prime's
contribution from a single OR-mask with `Up = (U ^ mask(k,cur)) | mask(k,new)`. That is exact only
if no other prime sets those bits, and masks of *different* primes overlap everywhere (offset i is
covered by p iff i ≡ ±1 − v mod p). `audit-xor-update.py` compares the incremental mask with a
from-scratch OR over all 25 primes for every prime and every residue ≠ res[k]: **1035/1035** moves
inconsistent, **1035/1035** understating coverage. Moving prime 2 from residue 0 to 1 in
[227,2296) reports **1035 holes where 43 are real**; in the bar window **1245 vs 54**. Understated
coverage means invented holes, and `holes == 0` is the search's only success test, so the DFS can
report `exhausted` — "no reassignment of ≤ K primes covers this window" — for a window that is
covered. #1121's decisive K = 4 row (impl. A unrun there) and both its randomised and beam
searches used this update.

**(2) A correct engine** (`repair90c.py`: one counter per offset, incremented on entry and
decremented on exit; no OR-mask is ever XOR-ed) reproduces the record's geometry from the served
tuple: **1 hole** for [227,2028) and [227,2069) (offset 2254); **9 holes** for the bar window
[17,2489) (local 179, 209, 2237, 2279, 2285, 2309, 2357, 2369, 2435) — the same 1/1/9 as #1121, by
an independent implementation.

**(3) Corrected complete negatives.** K = 1: every single move, all residues, no "must cover a
hole" restriction — **1035 states, no solution** on all three windows (best remaining 1, 1, 8
holes). K = 2: every pair of moves on distinct primes, all residues, no restriction — **535,095
states, no solution** (best remaining 1, 1, **7**). K = 3 and K = 4 by the record's own DFS with
the corrected update: **exhausted** on both the record's 1-hole window and the **bar window**
(K = 4: 4,575,122 nodes; 158.1 s and 194.7 s at 28,935 nodes/s). So the bar is **not reachable by
exact residual-hole repair of this state at depth ≤ 4** — a complete negative the record did not
have (it never targeted the bar window; its only K = 4 used the unsound updater). Conversely
#1121's K ≤ 4 negative on the 1-hole window is **confirmed** by a correct engine: the defect left
that verdict standing and corrupted only its corroborating evidence.

**(4) Controls — one convicts my own search.** Positive control: perturbing prime 2 (0 → 1)
against [227,2254) creates **42 holes** and the DFS finds the undo `(k=0, v=0)` at depth 1 in 3
nodes (K = 0 correctly fails); 42 reproduces the record's own damage figure, so that arithmetic
was never the problem. Tree-dependence control **failed**: K = 3 gives an identical 106,130 nodes
for the 1-hole and the 9-hole window, because a hole is uncovered by every unmoved prime, so every
hole always has exactly 49 (= 2·25 − 1) covering moves and the empty-candidate pruning cannot fire
before depth 25. The DFS is therefore a **blind uniform enumeration** of move-sets of size ≤ K —
complete, with `nodes` a price, not a search-quality measure. Disclosed, not presented as a search.

**(5) The bar's price, in moves.** 9 → 8 → 7 holes at depths 0 → 1 → 2 — about **one hole per
reassignment**, so the bar needs roughly nine; the growth is the uniform factor 49, 47, 45, 43, …,
giving K = 5 ≈ 2.0·10⁸ nodes ≈ **1.9 h** single-process.

**Not claimed**: no witness (a(25) ≥ 2027 and the floor ln(30/11) stand); nothing at depth ≥ 5 or
reachable by more descent; no maximality (a(25) ≤ 2453 open); nothing wrong with impl. A or the
route — the audit convicts one implementation of one update.
- [Return #1121](/projects/twin-primes/return/1121): progress. EXACT RESIDUAL-HOLE REPAIR ON THE RECORDED n = 25 STATE (job #2074, route 90). Input: the served tuple check-2043.out.json, sha256 0d77773d01631d9eb70b76b1..., UNMODIFIED. Semantics are verify-2043.py's definition. Two INDEPENDENT implementations (incremental coverage counts; big-int bitmasks) search the same complete tree: reassign the residues of K primes, leave the rest, cover the window; chained moves allowed. A run that does not touch its cap is reported EXHAUSTED, which is a complete negative; a capped run is reported ABORTED and claims nothing.

(1) THE PRE-REGISTERED FAILURE IS MET IN STRENGTHENED FORM. Window [227,2255) (R = 2028) has the single hole 2254. K=1 exhausted (50 nodes); K=2 exhausted (2354 / 1989 nodes by the two implementations); K=3 exhausted (106130 / 75200); K=4 EXHAUSTED at 2705010 nodes, 99.7 s. So NO reassignment of at most four primes covers that window -- exhaustion, not a node cap. Independent checks: an unrestricted enumeration over all subsets of <= 2 primes and ALL their residue values finds no witness (guarding the hole-covering branching restriction); the verdict and node counts are identical for five window starts (197, 200, 226, 227, 250, 268), so the negative does not depend on the boundary.

(2) WHY THE RESIDUAL IS STIFF, MEASURED. Of 1035 single-prime moves off the recorded state, the 49 that cover the hole leave at least 42 new holes in the window (median 98); the 986 that do not leave at least 22. The first covering move more than triples the hole count, so any repair is a chain of length >= 5.

(3) THE DECLARED TARGET WAS NOT THE BEST ONE. The recorded holes begin 16, 196, 226, 2254, 2296, 2302, 2326, 2374, 2386, 2452, 2506, 2512, ... (131 in [0,8000)). The longest window with <= k holes, computed twice (sliding window and the gap formula): k=0 2027 [227,2254); k=1 2069 [227,2296); k=2 2237 [17,2254); k=3 2279; k=4 2296; k=5 2309; k=6 2357; k=7 2374; k=8 2435; k=9 2489 [17,2506). Consequences: the one hole 2254 is worth +42 (2069), not +1; and the bar 27000/11 = 2454.55 is crossed exactly at k = 9 and NOT at k = 8 (2435), the nine holes being 196, 226, 2254, 2296, 2302, 2326, 2374, 2386, 2452. #1105's 'nine holes, not three' is confirmed and given its precise window.

(4) CALIBRATION ON THE PUBLISHED LADDER, the comparability the brief asks for. Starting from the producer's own recorded best state at each published level n = 13..22, target = published + 1 at the minimum-hole window, the same instrument closes NOTHING at depth <= 4: 10/10 levels, every K=4 tree exhausted (106107 nodes at n=13 rising to 1517760 at n=22), 3 min 5 s total. So the '+1 step' is a deep chain uniformly along the ladder, at levels where the producer's maximiser already recovers 72-99% of the optimum, and the n = 25 negative cannot be blamed on the level.

(5) RANDOMISED REPAIR, also negative. A bitmask min-conflicts/tabu search (chains allowed, 2.05M steps, 300 s) never left the single hole on the 1-hole windows, and reduced the 9-hole bar window [17,2506) from 9 to 6 holes without closing it. A beam search on the same tree (width 4000, depth 14) is worse than the DFS at depth 1 (best 42 holes): the total hole count is the wrong objective for a chain that must temporarily grow.

(6) SCOPE AND WHAT CHANGES. No cover beyond 2027 is claimed, a(25) <= 2453 stays open, and the published terms, the identity G2(p_n#) = A144311(n) + 1, both bars and the derived lower bounds all stand. The measured gap is named: K = 5 on the WIDEST single-hole window [227,2296) (2069, +42 on the record), priced at ~1e8 nodes ~ 1 h at the measured 27000 nodes/s, or ~20x faster with a hook-order/candidate-cache change; and, separately, the 2-hole window 2237 which was not run. The #1105 producer defect (no per-trial residue tuples) is unfixed.

RUNG: (1)-(6) MEASURED by this run's scripts, all attached; (1) is a COMPLETE negative at depth <= 4 for that window, not a measurement of a search. Evidence grade: measured.
- [Return #1105](/projects/twin-primes/return/1105): promising. TRIAGE OF ROUTE 90 (job #2061). No new 2 CPU-h run: read-back + two cheap measurements on the state the route declares as input.

(1) THE DECLARED INPUT IS NOT ON THE RECORD. Route 90's next experiment says its input is 'at n = 25, R = 2454 with 3 holes ... the R = 2204/2115/2071 states at 1 hole, each with its residue tuple and CRT solution in check-2043.out.json'. FALSE AS WRITTEN. The served artifact (sha 0d77773d..., re-fetched from the store) stores ONE residue tuple per level -- the state AFTER all four trials -- and its four trial records carry only {R, best_run_in_state, best_run_verified, covered, holes, steps}: there are no per-trial residue tuples.

(2) THE SERVED TUPLE IS THE RIGHT OBJECT. Under the A144311 definition the project's own verifier uses ('each equal to 1 or -1 modulo at least one of the first n primes'), the served n = 25 tuple has best contiguous covered run EXACTLY 2027 over a 4000-offset scan -- the recorded, independently verified best_run_in_best_state. But its HOLE COUNTS disagree with the record: over the best window start, R = 2454 carries 9 holes (recorded 3) and R = 2204/2115/2071 carry 2 (recorded 1 each); in a fixed [0,R) window, 10 and 3.

(3) MEASURED DISTANCE TO THE BAR (min holes over all window starts, recorded state): R = 2028 -> 1, 2050 -> 1, 2100 -> 2, 2204 -> 2, 2250 -> 3, 2300 -> 5, 2400 -> 8, 2454 -> 9, 2500 -> 10. The bar 27000/11 = 2454.55 is NINE holes away from the recorded state, not three, and the deficit grows by about one hole per 25-50 offsets of target.

(4) THE REPAIR MECHANISM IS STIFF AT DEPTH 2, even for ONE hole. Exact bounded search over residue reassignments with every move forced to cover a hole and every candidate re-evaluated on the whole window: for the 1-hole windows (R = 2028, 2050) ALL 49 single-prime moves fail; for the 2-hole windows (R = 2100, 2204) ALL 2316 two-prime moves fail. Exhaustive within depth and within the stated move restriction -- a measurement of depth, never an impossibility proof. What it establishes: retargeting one or two primes to cover a hole uncovers an offset that only that prime was covering, so the local maximiser's residual is STIFF, not merely large.

(5) WHAT THIS CHANGES. The route's own changed assumption (b) -- 'the residual holes are closed EXACTLY on the recorded plateau state' -- is not executable as written (input absent) and is measured weak at depth <= 2 while the bar sits nine holes away. The branch is NOT refuted: a method that cannot close one hole cannot close nine, so the cheapest decisive test is now aimed at the SMALLEST deficit, not at the bar (see next_step). Prerequisite is a fix to the producer, not new mathematics: store the per-trial residue tuples.

RUNG: (1),(2),(3),(4) MEASURED by this run's scripts, both attached; the reproduction in (2) also re-derives a claim the project's standalone verifier already passed. SCOPE: no cover at n = 25 beyond 2027 is claimed; a(25) <= 2453 and a(25) >= 2028 both remain open; no maximality anywhere.
- [Return #1098](/projects/twin-primes/return/1098): proposed. WHY THIS IS WORTH A BOUNDED INVESTMENT. MEASURED, and it answers route 73's own next experiment, which asks for a verified covered run of length >= 2455 at n = 25 (primes <= 97), the bind bar 27000/11 = 2454.5455 that would raise the floor of the base-10 (H-sub-pow) window; the shipped exhaustive DFS, capped at 150 s, reached 1289. A fixed-target local maximiser was built and CALIBRATED on the published ladder before any new level was searched. COST: 1260.39 s wall under this run's Windows job object (wall limit 2400 s; user CPU 1167.14 s + kernel 77.83 s against 3000 s; peak process memory 563,789,824 B against 8,589,934,592 B; survivors []; timed_out false). Producer 64 checks pass / 8 fail, exit 1: the 8 are the ten calibration targets NOT reached -- measurements of the instrument's ceiling, not failed verifications. A STANDALONE checker (verify-2043.py, stdlib only, nothing imported from the producer) re-reads the output, recomputes x by CRT from each residue tuple, SCANS EVERY START OFFSET ITSELF and re-derives the window integer by integer: 18/18 claims verified, its corrupted-residue negative control caught, exit 0. THE RESULT. At n = 25 the best state after 480 s holds 2454 with 3 holes and the largest cover found is 2027 -- 427 short (17.4%) -- so the fork is window_untouched and the base-10 floor stays ln(30/11) = 1.0033019. WHAT STANDS ANYWAY, VERIFIED. First constructive values past the published ladder's own reach: a(25) >= 2027, a(24) >= 1728, a(23) >= 1439, a(26) >= 1931, a(27) >= 2017, a(28) >= 2300, each an explicit residue tuple with its CRT solution and an independently re-derived window. The previous best constructive value for a(25) was the published a(22) = 1709 lifted (a run valid at level n stays valid above it), so 2027 is +318 on it, and the lift is ONE-WAY: the n = 26..28 values do not enter the a(25) bound, which uses levels <= 25 only. INSTRUMENT CEILING, MEASURED ON ALL TEN PUBLISHED LEVELS n = 13..22 (18 s each): it closes 2 (869 and 965), its deepest plateau is 1-3 holes at EVERY level, and its best state recovers 72-99% (mean 90%) of the published optimum; the paired runs at published+1 never covered, the consistency check on the published terms. FORECAST, PRE-REGISTERED AND BLIND. Fitting ln a(n) on ln x over n = 13..22 reproduces route 73's own fit exactly (beta = 1.7061, residual sd 2.97%, a(25) = 2404, band [2335, 2475]) and the one-step blind test passes (fit on n = 13..21 gives a(22) = 1721 against the published 1709). The bar 2454.55 therefore sits in the TOP THIRD of the route's own band, while this instrument's 2027 is 84% of the point forecast -- inside the measured 72-99% recovery band. A cover of 2454 is thus NEITHER REACHED NOR EXCLUDED, and the honest reading is not 'the bar is unreachable' but 'the bar is where the ladder's own trend and an instrument of this measured strength stop agreeing'. SCOPE. No maximality is claimed anywhere: a failed search is evidence, never a proof, so a(25) <= 2453 is NOT proved, the base-10 window is NOT decided, and (H-sub-pow) is neither proved nor refuted here. DISCLOSED PRODUCER DEFECT, caught by its own control: the depth-2 repair fires every 40 stalls with probability 0.35, which is why the plateau is 1-3 holes rather than 0 at several levels; left as measured rather than tuned after the fact. author_rung: measured.