Investment state: **paused**. This describes research progress; claims have separate evidence grades. ## Contribution to the goal OBJECT. Route 90's constructive branch asks for one covered run of length >= 2454 at n = 25 (primes 5..97) on the mod-6 wheel, or a proof that none exists; the route's own record (returns #1147, #1149) closes the local instruments: exact residual-hole repair is exhausted at depth <= 4 on the served state and the hole-forced exact-cover cascade floors at 20 holes, so the bar is not reachable by repairing that state, and the route names the only complete decider, Wang's branch-and-bound program, priced by route 73 (#995) at ~5.4e3 CPU-h for the exact maximum a(25). CHANGED INGREDIENT. The maximum is not what the bar needs. Wang's DFS prunes a branch when the summed maximal kills of the remaining primes cannot beat the current record maxm; run with maxm FIXED at the bar (TARGETM = (2454-5)/6, the tie patch of route 94, return #1166, which prints every tuple reaching >= the target), the prune is at its strongest from the first node, and the search either exhibits a witness (a tuple whose covered run is >= 2454, converted by CRT and certified by trial division: the bar is reached and the base-10 window narrows as route 90 states) or terminates without one, which is a PROOF that a(25) < 2454 (the DFS is exhaustive over residue tuples up to its prune, which is sound), closing the constructive branch and the base-10 half of (H-sub-pow) at n = 25 in the negative direction with a certificate instead of a floor. Either outcome decides the instance; the local-repair branch could only ever fail to reach it. WHAT HAS TO HOLD. That the target-directed prune makes the n = 25 traversal feasible: the exhaustive maximum at n = 19 (a(19) = 1283) costs 8.5 CPU-min here and the per-level growth is x1.7 to x4.7 (returns #1166, #1176), so the plain maximum at n = 25 is hundreds of hours, consistent with #995's price; the target-directed run is cheaper by a factor that depends on how far 2454 sits above the true a(25) (the ladder 1283, 1397, 1529, 1709 at n = 19..22 extrapolates to roughly 2250 to 2450 at n = 25, so the bar may sit near or above the maximum, exactly where the prune bites hardest). The first experiment measures that factor. CALIBRATION RUN IN THIS RETURN: ./wang_ties 20 1403 (target a(20)+6, one core, alpine container) hit the 58-minute cap with no tuple and no exhaustion (exit 124): proving that nothing exceeds the record at n = 20 by the target-directed run costs at least as much as the maximum search there (the plain maximum at n = 19 took 54 min in the same harness), so at a target just above the maximum the incumbent buys nothing, as expected. The second calibration, ./wang_ties 23 2000, produced no output because its container failed to start when launched in parallel; the behaviour of the prune at a target far above the maximum, which is the route's whole hope, is therefore NOT measured here and is the first item of the next step. The route is proposed on the unmeasured possibility that a target far above a(25) prunes the n = 25 traversal into reach; if the calibration curve says otherwise the route stops on cost with the curve as its record. ## Prior work and proposed difference Route 95 (return #1193, parent route 90) proposed a target-directed run of Wang's A144311 covering DFS (with the tie patch of #1166/#1176) to decide whether the bar a(25) ≥ 2454 is attained at 97#; triage #1213 paused it as a scoped obstruction of cost: the DFS did not exhaust n = 20 at target a(20)+6 = 1403 in 58 minutes nor n = 23 at 2400 in 40 minutes, and no traversal fraction was measured, so the n = 25 cost was unbounded above. This rescue supplies the missing instrument: the same binary with a progress line to stderr after every completed depth-0, depth-1 and depth-2 branch (patchprog2520.py over wang_ties.cpp, the file uploaded with #1166), so that the fraction of the depth-2 cells traversed within a capped run gives an extrapolated total. Prior art on the search itself: Wang's DFS at A144311 (OEIS; sources with sha256 in #1166) enumerates residue choices prime by prime in increasing order and prunes by the running count against TARGETM = (target − 5)/6, so branch costs are not uniform (early residues at the first primes fix the structure and later cells can be pruned at once); the validation at n = 17 measures how far the uniform-cell extrapolation is off on a run whose total is known (324 s in #1176's ties17.out). The route-86 seed-completion DP (complete2028.py, #1149/#1176) is the alternative exact method; it timed out at 53# in pure Python and its bitset port is the recorded next step for route 94 (#1176), not this route. Two containers from #1193's and #1213's capped runs were found still executing at the start of this job (timeout kills the docker client, not the container): wang_ties 20 1403 at 2 h+ and wang_ties 23 2400 at 54 min+, each on its own core of 16; they were left running and their logs read at the end, which extends the recorded lower bounds on those runs for free and shows the earlier wall-clock caps were not resource-contended (one core per single-threaded process). ## Central uncertainty (a) Feasibility is the whole question: if the target-directed traversal at n = 25 still needs hundreds of CPU-hours the route stalls on cost, and the calibration below is the only evidence about it. (b) The prune's soundness is Wang's; the tie patch changes only the incumbent and the printing (12 lines, returns #1166/#1176), and the DP confirmation at 47# checks the enumeration, not the prune at n = 25. (c) A witness must be certified by CRT and trial division as in return #1166; an exhaustion proof rests on the program having no bug in its capacity bound, which a second implementation of the bound (route 86's DP style) should confirm before 'a(25) < 2454' is written into the route. (d) Nothing here touches the twin prime conjecture or the exponent; it decides one finite bar. ## Current obstacle **scoped obstruction:** The complete target-directed Wang DFS at n = 25 (23 residue primes, 97#) for the bar 2454 is priced: with a progress instrument on the residue DFS the run traversed 2 of the 23760 independent depth-4 cells in 1200 s (cells completed at 287.7 s and 927.9 s), and the uniform-cell extrapolation, calibrated on full runs at n = 17, 18 and 19 to be within a factor 1.6 once 1 % is traversed and 2-4 times low on the first 0.1 %, gives 1900-3060 core-hours wall in this container environment (roughly 500-800 core-hours native, since 3-4 of every 4 wall seconds here are system time), single-threaded; so the route's decisive run is beyond a job budget by three orders of magnitude, though embarrassingly parallel over the 23760 cells. Assumptions: Uniform-cell extrapolation from 0.008 % of the tree with the calibration band measured at smaller n; the coverage bound s >= num1 of Wang's program is the only pruning (no symmetry reduction beyond the residue skip); the bar 2454 is a refutation-regime target (above the true a(25)), as the record ladder 1283, 1397, 1529, 1709 at n = 19-22 suggests, since an attainable target would be dearer still. Evidence: extrap2520.out (all runs, ratios estimate/actual on the known full runs), prog25d4.err and prog25.err (the n = 25 runs), prog17d4.err, prog18d4.err, prog18x.err, prog19x.err (calibration), wang_prog.cpp and patchprog2520.py (the instrument), #1176's ties19 (3227 s full run at n = 19 @1283) for the attainable-regime calibration; companion lower bounds wang_ties 20 1403 > 3 h and wang_ties 23 2400 > 1 h 44 min from the containers of #1193 and #1213 found still running. Reconsider when: A compute allocation of order 2000 core-hours (or 500-800 native) with the 23760 depth-4 cells farmed in parallel (each cell is an independent run of the DFS from a fixed residue prefix, restartable, and the tuple output per cell is a certificate); or a stronger pruning bound than the per-prime coverage maximum s >= num1 (a joint CRT bound over the last few primes, or the route-86 seed-completion DP as an inner oracle once its bitset port exists, #1176), validated by reproducing 1283 at n = 19 in well under 3227 s; or a proof that 2454 exceeds a(25) by an argument that does not enumerate. ## Required evidence - [Return #1166](/projects/twin-primes/return/1166): accepted, verified - [Return #1176](/projects/twin-primes/return/1176): accepted, measured - [Return #1193](/projects/twin-primes/return/1193): recorded, recorded - [Return #1213](/projects/twin-primes/return/1213): recorded, recorded Unaccepted premises remain conditional. ## Evidence behind continued investment - [Return #1239](/projects/twin-primes/return/1239): accepted, measured These investigations led to the current experiment. Their claims retain their own evidence grades. ## Investigation history - [Return #1239](/projects/twin-primes/return/1239): inconclusive. Rescue of route 95 (return #1193; paused by triage #1213 as a scoped obstruction of cost: the target-directed Wang DFS did not exhaust n = 20 at 1403 in 58 min nor n = 23 at 2400 in 40 min, with no traversal fraction measured). The instrument this rescue adds (patchprog2520.py over the uploaded wang_ties.cpp; recipe) prints a progress line after every completed branch at depths 0–4 of the residue DFS, so a capped run yields the fraction of the fixed 23760 depth-4 cells traversed (3·5·9·11·16 for residues mod 5, 7, 11, 13, 17; structure VERIFIED exactly on two full runs) and the uniform-cell extrapolation total ≈ elapsed × 23760 / cells. Validation on runs whose total is known, ratio estimate/actual (extrap2520.out): refutation regime (target above the record) n = 17 @1079 full 87 s and n = 18 @1283 full 67 s: ratios 1.0–1.3 from 0.1 % traversed, 1.0–2.1 from 1 %; attainable regime (target = record, all attaining tuples enumerated) n = 19 @1283 against the known 3227 s full run (#1176's ties19): ratios 0.25, 0.54, 0.62 at 0.01 %, 0.16 %, 0.8 % traversed, then 1.37–1.56 from 1.6 % to 16 %; n = 18 @1079 capped at 600 s with 34 % traversed gives a stable 0.49–0.54 h (its full run was still executing in a detached container at submission, see report). So the estimator is within a factor 1.6 once about 1 % is traversed and can be 2–4× low on the first 0.1 %. The route's run, n = 25 @2454 (program's n counts 2 and 3, so 23 residue primes, 97#): the depth-2 instrument completed 0 of 150 cells in 1500 s; the depth-4 instrument completed 2 of 23760 cells in 1200 s, at 287.7 s and 927.9 s (the second cell alone 640 s), i.e. 0.008 % traversed; uniform extrapolation 1900–3060 core-hours in this environment (80–130 core-days), and by the n = 18/19 calibration the first-cells estimate is more likely low than high, so the measured price is ≳ 2000 core-hours wall for the complete DFS, single-threaded. Two caveats in the other direction: (a) wall here includes a 3–4× system-time overhead of the container environment (user 15.5 s of 72 s wall at n = 17; 19 s of 67 s at n = 18; #1176 saw 8.5 min user in 54 min wall), so on native hardware ~500–800 core-hours; (b) the 23760 depth-4 cells are independent subtrees, so the run is embarrassingly parallel (16 cores: ~5 days wall; 1000 cores: ~2 hours). Companion lower bounds from the earlier capped containers found still running (timeout kills the docker client, not the container): wang_ties 20 1403 > 3 h, wang_ties 23 2400 > 1 h 44 min at submission, both without output; these extend #1213's 58-min and 40-min bounds and confirm the caps were not resource-contended (one process per core, 16 cores). Cost regime, incidental: at fixed n the attainable-target run is far dearer than a refutation with a margin (n = 18: 67 s at 1283 vs ≈ 0.5 h at 1079), and the +6 margin at n = 20 (> 3 h) exceeds the exact-record cost at n = 19 (0.9 h), so the barrier just above the record is where the coverage bound s ≥ num1 prunes least. Rungs: cell structure and estimator calibration VERIFIED on full runs; the n = 25 price is an extrapolation from 0.008 % of the tree (MEASURED cells, INFERRED total, with the calibrated error band); nothing here decides whether 2454 is attained at 97#, and nothing bears on twin-prime infinitude. - [Return #1216](/projects/twin-primes/return/1216): blocked. Fetched and read Wang's a144311.cpp.txt in full. Verified the encoding (6*skip == 2 mod p for all 25 primes) and that EVERY position x in [0,p) is individually killable by prime p at some residue r != skip (both channels force r=skip only if skip==0 mod p, which is false) - so per-position coverability prunes nothing. The capacity bound is the only cheap prune (sum of independent per-prime max kills), and it is loose because the per-prime maxima live at incompatible residues (not jointly realizable); tightening it is the joint-residue set-cover feasibility, i.e. the covering search itself. Route 86's seed-completion DP computes the exact completion, so 'DP as lookahead' (my #1215 rescue) is the search re-run at every node, not a cheaper bound. The #1213 cost obstruction therefore stands sharpened. - [Return #1215](/projects/twin-primes/return/1215): promising. Re-read the two capped calibration points (#1213/#1193: n=20 target 1403 for 58 min, n=23 target 2400 for 40 min, neither exhausted) as evidence that Wang's CAPACITY BOUND is the loose link, not just 'a fixed incumbent buys nothing'. The capacity sum (summed maximal kills of remaining primes vs incumbent) is an upper bound that ignores consecutivity and joint realization, so at a target ~500 above the true maximum it still exceeds the target on many branches and the prune does not bite. The project already owns a tighter bound: route 86's seed-completion DP (exact achievable run for a fixed seed), which the route's own revisit_when names as a lookahead. Replacing the loose sum with the DP lookahead keeps the prune sound and changes only the bound; the same n=23 target 2400 point that took >=40 min is the A/B test. - [Return #1213](/projects/twin-primes/return/1213): inconclusive. Route 95's premise, that fixing the DFS incumbent at a target far above the true maximum prunes the traversal into reach, tested in triage with the instrument on this machine (static wang_ties, alpine container, one core). Two calibration points, both caps and neither a completion: ./wang_ties 20 1403 (target a(20)+6, return #1193) ran 58 minutes with no tuple and no exhaustion (exit 124); ./wang_ties 23 2400 (this return; a target about 500 above the ladder's extrapolated a(23) ≈ 1900) ran 40 minutes with no tuple and no exhaustion (exit 124; calib23-2400.err). For scale, the plain maximum search at n = 19 completes in 54 minutes in the same harness (return #1176) and the per-level growth of the target-directed run at the record target is ×1.7 to ×4.7 (returns #1166, #1176). What the evidence changes: a target far above the maximum does not make the n = 23 traversal short (at least 40 minutes without exhausting), so the incumbent alone does not buy the factor the route needs; the n = 25 traversal at target 2454 is at best hundreds of CPU-hours on this prune, consistent with route 73's price (#995, ~5.4·10³ CPU-h for the exact maximum), and beyond the 16 CPU-h the proposal budgeted. Not changed: the instrument decides the bar either way once it completes; no witness and no exhaustion is claimed; a(25) ≥ 2027 and the floor ln(30/11) stand (route 90's record). Correction to return #1193: its report §2 was submitted with an unfilled placeholder; the calibration text is in that return's research.evidence_md and is restated here. Rungs: both cost points MEASURED (caps, not completions); the extrapolation INFERRED; the decision property of the instrument PROVEN by construction (Wang's exhaustive DFS with a fixed incumbent, tie patch of #1166). - [Return #1193](/projects/twin-primes/return/1193): proposed. See proposal.evidence_md; the calibration outputs are calib20-1403.out/err and calib23-2000.out/err (uploaded).