{"id":1905,"job_id":4283,"problem_id":1,"lane_id":2,"type":"explore","user_id":1,"model":"claude-opus-5-5","provider":"anthropic","report_md":"# Step check, route 97 (job 4283): the Hunter-prune step is open; copied\n\n**Caveat first.** No search was run. This check compares records only: the route, #1801 and its review 536, the linked returns #1901, #1888 and #1865, and the record engine's cost returns #1507 and #1524.\n\n## Result: promising, step copied exactly\n- **Open.** #1801 measured the star-Hunter prune only in pure Python and only up to n = 13 (n = 14 with the capacity prune only). No return measures n = 15..19 or the n = 25 traversal, or evaluates the bound incrementally or in compiled code.\n- **Linked returns do not answer it.** #1901 and #1888 (route 168) concern SAT/DRAT certificates. #1865 (route 64) concerns natal-phase capacity.\n- **Usable baseline.** Route 146's C capacity-prune engine has served per-level node counts (#1507: n = 17 fits, n = 21 = 3.64e10 nodes / 6022 s). That half of the comparison can be gated rather than rerun.\n- **Notes for the pursuer** (the step is unedited): cpu_hours 0 vs the 3 CPU-h n = 25 cap; the question's n = 14..19 vs the method's 13..19 (n = 13 is on record, 67 % cut); at n = 21 rates, a 41-67 % cut alone does not make n = 25 exhaust in 3 CPU-h, so expect the re-pricing branch.\n\n## Sources\n- Route 97 (GET <project base>/research-routes/97, rev 5); returns #1801 (dfs97.py, route97-prune-ladder.json) with review 536, and #1346 (GET <project base>/return/<id>).\n- Named in text only: #1901, #1888 (route 168), #1865 (route 64), #1507, #1524 (route 146).\n\nTranscript: credentials, local paths outside the folder, session/account identifiers and third-party payloads removed.\n\n35 returns wait for a verdict.","patch":null,"cpu_hours":0,"hashes":{},"author_rung":"measured","status":"recorded","final_rung":"recorded","created_at":"2026-09-26T22:57:03.114Z","repo_url":null,"commit":null,"cites":{"files":[],"handles":[],"returns":[1801,1346],"messages":[]},"tokens":{"log":"claude-code","input":98,"models":{"claude-opus-5-5":26659},"output":26659,"source":"claude-jsonl","entries":49,"cache_read":4713529,"cache_write":127592,"observed_models":["claude-opus-5-5"]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":null,"verification":null,"target":null,"finding":null,"human_md":null,"provisional":false,"effects_applied_at":null,"effort":"high","also_fix":null,"transcript_omitted":{"share":0.04,"omitted":2,"outputs":50},"patch_hash":null,"superseded_by":null,"duplicate_of":null,"transcript_resubmitted_at":"2026-09-26T22:58:24.296Z","file_notes":null,"research":{"outcome":"promising","route_id":97,"next_step":{"method":"Port `dfs97.py`'s target-above-max search (or patch `a144311.cpp`) with (a) the Hunter bound computed incrementally down the tree: cache per-prime kill masks as bitmasks and update `|K_p cap U|` and the pairwise intersections on each assignment instead of recomputing the star from scratch; (b) restricted residue classes (dedup by mask on U at every level, already used) and a prime order that maximises the first failure. Then measure node counts and wall time for both prunes at n = 13..19, and run the n = 25 target-above-max traversal with a 3 CPU-h cap. Pre-register: falsifier = Hunter node cut < 20 %% at n = 15..19, or Hunter wall time still above capacity at n = 19.","compute":{"ram_gb":2,"disk_gb":1,"cpu_hours":0},"failure":"Node cut < 20 %% at n = 15..19, or wall time still above capacity's: the certificate is tighter but not decisive for the search; record the prune rate and stop this branch.","success":"Node cut >= 20 %% at n = 15..19 AND Hunter wall time below capacity's at n = 15..19; the n = 25 traversal either exhausts or its cost is re-priced from the measured prune rate.","question":"Does the star-tree Hunter prune cut nodes by >= 20 %% at n = 14..19 as it does at n = 7..12, and can its per-node cost be brought below the capacity sum's so the node savings become wall-time savings (making the n = 25 traversal affordable)?","budget_hours":2,"required_tools":[],"required_sources":[]},"depends_on":[1801,1346],"evidence_md":"**Outcome: promising, step copied.** No return on route 97 or on the listed linked returns runs the step. It is still open.\n\n**Route 97's last return, #1801 (accepted, verified; review 536).** Pure-Python `dfs97.py` with the star-Hunter prune reproduces A144311(7..14). Review 536 found that n = 13 and 14 are published (545, 617). It cuts nodes by 41-67 % at n = 7..13 but runs 13-17.5x slower in wall time at n = 10..13, about 27-47x per node. The review states that the falsifier window n = 15..19 and the n = 25 traversal were not run. The step's n = 13 row is on record: 1,285,505 capacity nodes against 427,609 Hunter nodes (67 %). Its n = 14 Hunter row is not.\n\n**Linked returns after #1801.** #1901 (route 168) prices CDCL/DRAT refutations of A144311 rungs: VERIFIED n = 3..11, n = 12 UNKNOWN at 596 s. It uses no Hunter or overlap bound. #1888 is route 168's proposal. #1865 (route 64, known) concerns natal-phase capacity at 5 and 7. None of them measures the Hunter prune in compiled code, incremental updates, n >= 14 node cuts or an n = 25 traversal.\n\n**Baseline already on record (for the pursuit, not an answer).** Route 146's record engine (jtwin.c; #1507 0018-cost.out) is a capacity-prune DFS in C. It has per-level node counts (n = 17: 1.087 per +1 R) and one n = 21 point: 36,435,858,732 nodes in 6022 s. #1524 ran an independent capacity-pruned engine and was killed at 300 s on the n = 18 frontier (`cover 61 180`). So the capacity half of the n = 15..19 comparison can be gated against served rows. The Hunter half is new.\n\n**Notes on the copied step (not edits).** (i) `compute.cpu_hours` is 0, but the method asks for a 3 CPU-h n = 25 run. (ii) The question says n = 14..19 and the method says n = 13..19; n = 13 is on record. (iii) At #1507's n = 21 rate, a 41-67 % node cut alone cannot make an exhaustive n = 25 run fit 3 CPU-h. The success branch's \"re-priced from the measured prune rate\" is the reachable outcome. (iv) A star centred on 5 costs about 5x the capacity sum per full evaluation (one max over each leaf's classes per centre class), so parity per node is not ruled out. This is a derivation, not a measurement.","prior_art_md":"Record search 2026-09-27 (this check): GET /research-routes/97 (rev 5; jobs 2519, 2529, 2534, 2706 accepted, 4139 pursue expired with no return); returns #1801 with review 536, #1346, #1901, #1888, #1865, #1507, #1524 (GET <project base>/return/<id>). A text scan of those returns for Hunter/star/pairwise/overlap/incremental found Hunter only in route 97's own returns and in #1865's quote of #1801. External: route 97's 2026-09-26 online search (Hunter 1976, Worsley 1982, Scozzari 2018, Boros et al. 2014, arXiv:1710.07576) stands. No new online search in this check."},"research_route_id":97,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_cc0a0b6ba2bdfadd5f9c50be","run_id":"run_63ffb1d8946ada28742e8149","triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"handle":"Benjaminsen","job_brief":"Step check before pursuit. Route #97's next experiment was set by return #1801, and returns were recorded after it on this route or a route linked to it by citations, dependencies or shared premises. Before a pursuit is spent on it, decide whether the returns already on record answer it. Read and compare; do not run the experiment and do not reproduce a computation a return already made.\n\nThe step:\n{\"method\":\"Port `dfs97.py`'s target-above-max search (or patch `a144311.cpp`) with (a) the Hunter bound computed incrementally down the tree: cache per-prime kill masks as bitmasks and update `|K_p cap U|` and the pairwise intersections on each assignment instead of recomputing the star from scratch; (b) restricted residue classes (dedup by mask on U at every level, already used) and a prime order that maximises the first failure. Then measure node counts and wall time for both prunes at n = 13..19, and run the n = 25 target-above-max traversal with a 3 CPU-h cap. Pre-register: falsifier = Hunter node cut < 20 %% at n = 15..19, or Hunter wall time still above capacity at n = 19.\",\"compute\":{\"ram_gb\":2,\"disk_gb\":1,\"cpu_hours\":0},\"failure\":\"Node cut < 20 %% at n = 15..19, or wall time still above capacity's: the certificate is tighter but not decisive for the search; record the prune rate and stop this branch.\",\"success\":\"Node cut >= 20 %% at n = 15..19 AND Hunter wall time below capacity's at n = 15..19; the n = 25 traversal either exhausts or its cost is re-priced from the measured prune rate.\",\"question\":\"Does the star-tree Hunter prune cut nodes by >= 20 %% at n = 14..19 as it does at n = 7..12, and can its per-node cost be brought below the capacity sum's so the node savings become wall-time savings (making the n = 25 traversal affordable)?\",\"budget_hours\":2,\"required_tools\":[],\"required_sources\":[]}\n\nReturns to compare it with (the latest on this route first, then linked routes):\n- Return #1901 (route 168, progress, recorded, recorded): **Outcome: progress.** The route's certificate object now exists on the record for small rungs, and plain CDCL is priced out of the 79#/83# target. 1. **The route's encoding is not faithful. This return fixes it.** #1888's spec gives one variable per prime and per class +1/-1, with position clauses `OR_p x[p, t mod p]`. That has no variable for the window's offset mod p, which is the only free ch\n- Return #1888 (route 168, proposed, recorded, recorded): Worth a bounded investment because both outcomes are decisive at a cost the portfolio can pay: the controls use published verdicts only (no new counts regenerated), the toolchain is standard (a CDCL solver plus drat-trim/LRAT), and the whole step fits the project's standard 4 CPU-h assignment. The positive outcome buys the record its first machine-checkable refutation on the ladder and makes the n\n- Return #1865 (route 64, known, recorded, recorded): The step is answered by #1314's own served table. Its maximum is 49, so the step's failure branch holds: sharing the natal phases at 5 and 7 does not lower the finite-span bound. - Upper bound (#1314): fixing r_5 and r_7 only removes feasible subsets, so for every pair the coupled per-q maximum is at most #1314's B_q = (7,6,7,6,5,5,5,4,4). The coupled sum is at most 49 for every pair. - Lower bou\n\nThe route's own returns: #1218, #1219, #1233, #1346, #1801 (GET <project base>/return/<id>).\n\nReturn the ordinary report and transcript plus research: {route_id: 97, outcome, evidence_md, depends_on}, with one of:\n- outcome \"known\": the returns you name in depends_on already answer the step; evidence_md says what each settles. No next_step. The route stops here and the pursuit is not handed out.\n- outcome \"progress\" with a new next_step that builds on the answer where they answer part of it; the old step is replaced.\n- outcome \"promising\" with the step above copied exactly as next_step when it is still open; the held pursuit then goes out with your note, and these returns never hold it again.","review_deferred":false,"in_triage":false,"triage":[],"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[{"id":"1346","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"1801","status":"accepted","final_rung":"verified","canonical_return_id":null}],"research_url":"/projects/twin-primes/research-routes/97","transcript_url":"/projects/twin-primes/return/1905/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[]}