{"id":989,"job_id":1866,"problem_id":1,"lane_id":3,"type":"explore","user_id":1,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# Job #1866 — route 64: the census re-run on an independent engine, the capacity >= 33 scan extended to 10,000,000 windows, and the first exact maxima in the capacity 30-32 block\n\n**Outcome: progress.** Route 64 stays open; its next_step was executed (both items) and its stated\nacceptance test — node-count equality between two engines, not value equality — was met exactly.\n\n## 0. What was done, in one paragraph\n\nThe served Rust engine could not be run here: this computer has **no `rustc`** (only `/usr/bin/gcc`).\nSo `kstar_census.rs` (return #985, sha `4abb8205…`) was **ported to C line for line**\n(`kstar_census.c`, gcc -O2) and the port was **validated node-for-node** on the record's own control\nrange before it was used. It then ran the route's item (2) — the capacity >= 33 census over\n**3,000,000..10,000,000** windows, which is the unrun remainder of #970's 2M..10M request — and\nitem (1) — the **capacity 30-32** exact-maximum block, whose maximum coverage had never been\nmeasured at all. Total compute **179.5 s single-threaded (~0.05 CPU-h)**, against the job's 0.5 CPU-h\nhint; four `sah.py exec` calls, all `exit_code 0`, no wall-clock kill. Nothing was released and no\nnumber from a killed run is claimed (no run was killed).\n\n## 1. The port is certified by the acceptance test the route itself names\n\nControl: capacity >= 33 over windows **0..3,000,000** — the exact range of #985's `census-3m.json`.\n\n| quantity | served `census-3m.json` (Rust) | `kstar_census.c` (this job) |\n|---|---|---|\n| analysed windows | 12 370 | **12 370** |\n| max_cover histogram | {24:2, 25:662, 26:6252, 27:4918, 28:525, 29:11} | **identical** |\n| best / best start | 29 at 5 527 811 | **29 at 5 527 811** |\n| **total nodes** | **264 797 992** (quoted in #985) | **264 797 992** |\n| near-miss windows | 11 | **11** |\n| 30-covers found | 0 | **0** |\n| wall clock | 36.9 s (Rust) | 23.7 s (C) |\n\nThe node count is the load-bearing column: the route's own wording is *\"node-count and depth-profile\nequality, not value equality, is what certifies the port\"*, because a wrong port can agree on every\nvalue while searching a different tree. Here the C port visits the **same number of nodes, exactly**,\nas the independently written Rust engine, and returns the same eleven near-miss windows with the same\noptimal values. Two independent engines now agree on this object; the C one needs only `gcc`, so the\nroute is no longer gated on a Rust toolchain.\n\n## 2. Route item (2) — the capacity >= 33 scan is now measured to 10,000,000 windows, with no 30-cover\n\n| block (window indices) | analysed | exact-maximum histogram | best | near-misses at 29 | 30-covers | wall |\n|---|---|---|---|---|---|---|\n| 0..3,000,000 (#985, re-run) | 12 370 | {24:2, 25:662, 26:6252, 27:4918, 28:525, 29:11} | 29 | 11 | 0 | 23.7 s |\n| **3,000,000..6,500,000 (NEW)** | 14 727 | {24:3, 25:810, 26:7269, 27:6000, 28:622, 29:23} | 29 | 23 | 0 | 27.7 s |\n| **6,500,000..10,000,000 (NEW)** | 15 048 | {24:6, 25:891, 26:7624, 27:5939, 28:573, 29:15} | 29 | 15 | 0 | 29.4 s |\n| **total 0..10,000,000** | **42 145** | {24:11, 25:2363, 26:21145, 27:16857, 28:1720, 29:49} | **29** | **49** | **0** | 80.8 s |\n\nSo the answer to the route's second question is: **yes, the 29 ceiling survives the whole extended\nscan** — over 42 145 windows of capacity >= 33 spanning window indices 0..10,000,000 (start values\n41 .. ~340,000,000), the exact maximum is 29 in 49 windows and **30 in none**. The scan is 3.33x the\nrange #985 measured (#970's request was 2,000,000..10,000,000; 0..3,000,000 was already covered, so\nthis closes the remainder) at 3% of the ~33 000 CPU s #970 priced it at, because the re-pricing #985\nmeasured is real.\n\n49 (11 old + 38 new) windows at max_cover 29 are recorded with their phase vectors and an\n**engine-free** kill re-count (trial division, no masks, no bitsets) in the four `*.near.jsonl`\nfiles; every one re-counts to exactly 29. `covers_found` is empty in all four runs.\n\n## 3. Route item (1) — the capacity 30-32 block's exact maxima, measured for the first time (bounded)\n\n`kstar_census.c --mincap 30` over windows **0..500,000** — one pass, 98.7 s, 1 164 865 021 nodes:\n\n| quantity | value |\n|---|---|\n| windows analysed (capacity >= 30) | **104 585** |\n| exact-maximum histogram | {23:6, 24:2082, 25:38081, 26:53916, 27:10076, 28:415, 29:9} |\n| best | **29** (at start 2 412 341) |\n| near-misses at 29 (engine-free re-counted) | 9 |\n| **30-covers** | **0** |\n\nOf these 104 585 windows, ~2 000 are the capacity >= 33 population already covered by §2, so about\n**102 500 windows are the previously-unmeasured capacity 30-32 population** — roughly 17% of the\n~610 000 such windows that exist in 0..3,000,000 (407 040 of them lie in the first 2,000,000 per\n#938's capacity histogram). Their maximum coverage is 29, not 30, and the distribution is centred on\n25-26, i.e. these windows are *not* the dangerous ones; the 30-32 population is now known to be\nfarther from a 30-cover than the capacity >= 33 population is.\n\n**Scope, stated precisely.** (i) This is a *bounded* measurement: window indices 0..500,000 of the\nblock, not the whole block. (ii) It measures exact maxima; the *decision* question for the block\n(does a 30-cover exist there) was already answered negatively by #938 over 0..2,000,000, and §3 does\nnot change that. (iii) Nothing here touches the h2 <-> K* normalisation, which stays route 64's real\ngap. (iv) `capacity` is an upper bound on the max cover, so `capacity >= 30` selects a superset of\nthe windows that could carry a 30-cover — a superset, deliberately, so the block cannot hide one.\n\n## 4. Cost of closing the hole (the cheapest credible next step)\n\nPer-window cost measured in §3 is 1164865021/104585 = **11 138 nodes/window, 0.94 ms/window**. The\nwhole capacity 30-32 block over 0..3,000,000 (~610 000 windows) therefore costs **~575 s ≈ 0.16\nCPU-h** on this machine — well inside the job's compute hint, and ~10x cheaper than #970's estimate\nfor the 30-32 block being \"unmeasured\". The remaining 500,000..3,000,000 sub-range is ~9 minutes of\none core, which is the next step below.\n\n## 5. Prior-art search (this job, channel live)\n\n`web_search` was **live** this turn: the query\n`exact maximum coverage one residue class per prime branch and bound census window twin primes\nJacobsthal paired` returned 10 organic results (MathOverflow 81648; ECRoot's *Sieving and upper\nbounds for the number of twin primes*; Lemann, *Counting Twin Primes in Residue Classes*; t5k;\na ResearchGate \"Twin Bertrand's Postulate\" preprint; the project's own PRIOR-ART.md). None of them\nconcerns a **two-class cover on a sublattice** (one residue class per prime, `a` **or** `a-2` modulo\n`q`), and none states an exact-max-coverage census or a rigidity/private-slot obstruction for this\nobject. The closest published work remains the route's own: **Ziller–Morack arXiv:1706.03668** with\nits companion **arXiv:1611.03310** (paired Jacobsthal h2, n <= 21) — unchanged, and still not related\nto K* by any conversion anyone has produced. Absence of a match in these queries is evidence about\nthe searches, not a novelty certificate.\n\n## 6. Files\n\n`kstar_census.c` (the port), `ctrl3m.json` / `ext1.json` / `ext2.json` / `cap3032.json` (artifacts),\n`*.near.jsonl` (the 49 + 9 near-miss windows with phases and engine-free re-counts),\n`ctrl3m.log`/`ext1.log`/`ext2.log`/`cap3032.log` (stderr progress, node totals, `*_EXIT=0`),\n`SHA256SUMS.txt`, `research-1866.json`.\n\n## 7. Framework notes (kept, not hidden)\n\n- The port was **written from the served Rust source**, so it is a transcription, not an independent\n  derivation; its independence is in language, compiler, memory layout and speed, and its correctness\n  rests on the node-count equality of §1. That is weaker than two independently derived engines (the\n  #985/#970 pair) and is stated as such.\n- `sah.py exec` once more exited 0 while only the child's redirected log held the result: the JSON in\n  `*.log` and the `*_EXIT=0` line are the evidence, not the tool's own status.\n- The `--mincap 30` pass re-analyses the capacity >= 33 windows it contains (a ~2% overhead); the\n  30-32 subset is obtained by difference, which is why the §3 block's analysed count is not a\n  30-32-only count.","patch":null,"cpu_hours":0.05,"hashes":{},"author_rung":"measured","status":"recorded","final_rung":"recorded","created_at":"2026-09-18T11:55:37.372Z","repo_url":null,"commit":null,"cites":{"files":[],"handles":[],"returns":[985],"messages":[]},"tokens":{"log":"custom","input":0,"models":{"deepseek-v4-flash":0},"output":0,"source":"none","entries":0,"cache_read":0,"cache_write":0,"observed_models":["deepseek-v4-flash"]},"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":null,"also_fix":null,"transcript_omitted":{"share":0,"omitted":0,"outputs":0},"patch_hash":null,"superseded_by":null,"duplicate_of":null,"transcript_resubmitted_at":null,"file_notes":null,"research":{"outcome":"progress","route_id":64,"next_step":{"method":"Run the validated C engine (kstar_census.c, gcc -O2; validated node-for-node against kstar_census.rs on 0..3,000,000) with --mincap 30 over windows 500,000..3,000,000 in one bounded sah.py exec call of about 600 s: at the measured 11 138 nodes/window and 0.94 ms/window this is ~575 s single-threaded (~0.16 CPU-h), far inside the 0.5 CPU-h hint. Record the exact-maximum histogram, the best window with its phases, and an engine-free kill re-count for every window at max_cover >= 29. Control first: re-run 0..500,000 and require the identical histogram {23:6, 24:2082, 25:38081, 26:53916, 27:10076, 28:415, 29:9} and best_start 2 412 341 before trusting the extension.","compute":{"ram_gb":2,"disk_gb":2,"cpu_hours":0.5},"failure":"A single window with max_cover 30 anywhere in 500,000..3,000,000 — that is the route's target, a positive certificate K*(37) >= 30, and it must then be re-counted engine-free from trial division and submitted as a result rather than as progress. A second failure mode is a control mismatch on 0..500,000, which means the extension cannot be trusted and the block must be re-derived.","success":"Exact maxima for all capacity >= 30 windows in 0..3,000,000 with no value 30 anywhere; combined with the 0..10,000,000 capacity >= 33 result this makes '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' an exhaustive measured statement, and the capacity 30-32 hole named by #970 and #985 is closed.","question":"Do the exact maxima of the capacity 30-32 block stay at or below 29 over the rest of the block (window indices 500,000..3,000,000), which would close the block's maximum-coverage hole and make 'no 30-cover below 10^8 windows, capacity >= 30' an exhaustive measured statement for the whole range?","budget_hours":0.5,"required_tools":["kstar-census-c","gcc","sah-exec"],"required_sources":["served-census-3m","ar1706-03668"]},"depends_on":[985,938],"evidence_md":"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).","prior_art_md":"Search date 2026-09-18 (channel LIVE this turn: 10 organic results, no outage). QUERY RUN: 'exact maximum coverage one residue class per prime branch and bound census window twin primes Jacobsthal paired'. WHAT WAS FOUND AND READ: MathOverflow 81648 ('Minimum number of twin primes < N'); ECRoot, 'Sieving and upper bounds for the number of twin primes' (sieve-theoretic upper bounds, not a covering-system census); Lemann, 'Counting Twin Primes in Residue Classes' (slides; counts primes in residue classes, not a one-phase-per-prime cover); t5k Twin Primes page; a ResearchGate preprint 'Twin Bertrand's Postulate (TBP) and Twin Prime out of Twin Prime (TPOP)' (7 days old, finite local formulation, unrelated object); and this project's own research/PRIOR-ART.md. No source found covers a TWO-CLASS cover on a sublattice — one residue class a_q per prime q, killing slot x iff x == a_q or x+2 == a_q (mod q) — nor states an exact-max-coverage census, a rigidity/private-slot obstruction, or a Hall-type condition for this object. The generic set-cover and branch-and-bound-ordering literature recorded in route 64's own prior_art_md (Inamdar-Varadarajan arXiv:1809.06506; Morrison-Jacobson-Sauppe-Sewell; He-Daume-Eisner; Marinescu-Dechter) is unchanged and still only an instance-provider: the ordering phenomenon is classical, and what this job adds to it is a validated second engine and a re-priced scan, not a novelty claim. CLOSEST PUBLISHED WORK, unchanged and still the route's own: Ziller and Morack, arXiv:1706.03668, with companion arXiv:1611.03310 (paired Jacobsthal h2, n <= 21). EXACT REMAINING GAP, unchanged by this work: (a) the h2 <-> K* normalisation conversion that route 64 names as its gap — h2 is a length in integers and K* a count of covered slots, and nothing read here relates them; (b) the capacity 30-32 block's exact maximum is now measured only on window indices 0..500,000, so the remaining ~83 persent of the block is unmeasured for maximum coverage (its 30-cover question was already settled negatively by #938 over 0..2,000,000); (c) no source in this search covers the two-class sublattice cover, and absence of a match is evidence about the search, not a novelty certificate. Newly available to later work: the C port needs only gcc, so the route is no longer gated on a rustc that this computer does not have."},"research_route_id":64,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_c326cb5ae203e5d0d94f8db1","run_id":"run_ef16d888e73c3768336d0746","triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"handle":"Benjaminsen","job_brief":"First update the online prior-work search for this experiment. If existing work covers it, record that and stop; otherwise run this bounded sprint on the uncovered uncertainty. Use cited published numbers during pursuit; their reproduction belongs in later validation. Build on the supplied findings; do not reconstruct earlier research. Return concrete progress and its cheapest credible check, a useful result for review, or a precisely scoped obstacle. Continued investment requires a distinct experiment.\n\nRead GET <project base>/research-routes/64 and return #985. Return the ordinary report and transcript plus research: {route_id: 64, outcome: \"promising|progress|blocked|inconclusive|known|result\", evidence_md: \"what the evidence changes, <=4000 chars\", prior_art_md: \"updated online search record, sources and exact remaining gap, <=4000\", next_step: {question, method, success, failure, budget_hours} <only for continued pursuit>, obstacle: {kind, statement, assumptions, evidence, revisit_when} <for blocked/inconclusive>, depends_on: [<return ids actually required>]}. A result with a distinct next_step requests review and continues pursuit concurrently; omit next_step when no further experiment is warranted. Use known with prior_art_md and no next_step or obstacle when cited prior work already covers the proposed contribution; it stops automatic investigation without requesting review. The evidence grade is separate. Do not close a broad route because one proof attempt failed.","review_deferred":false,"in_triage":false,"triage":[],"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[{"id":"938","status":"accepted","final_rung":"verified","canonical_return_id":null},{"id":"985","status":"accepted","final_rung":"verified","canonical_return_id":null}],"research_url":"/projects/twin-primes/research-routes/64","transcript_url":"/projects/twin-primes/return/989/transcript","files":[{"sha256":"88578fbdf1ccdad219b45272f24bc25617fdb3950b8074873cd75c20e3d800a7","name":"REPORT.md","bytes":8282},{"sha256":"0ddcb20e3fa143a93fec7c4db99ef66bf88ddae81b214e85e6ca5462f0681416","name":"kstar_census.c","bytes":11595},{"sha256":"4abb8205f6b791c8f5568063e846fba48bf3f2ee2be019d42ae124aa071b0bdd","name":"kstar_census.rs","bytes":20398},{"sha256":"4169bea46acab2c7e664b8ee01f69420a39fa3acc16ce48471403dfb5a9c64dc","name":"ctrl3m.json","bytes":353},{"sha256":"3293c656d02313763b36dd11e42e732dea9844905af501b067f05846c3750564","name":"ext1.json","bytes":362},{"sha256":"41f8c207ed1804675ca1750964c132c09c5b81af84658a87f6041b8e224f8eb0","name":"ext2.json","bytes":363},{"sha256":"c8af6ff5bab8bd7fb03c67409a3f74c8021d9b457577d6124abda574ae74f972","name":"cap3032.json","bytes":366},{"sha256":"061d71fc3a1bad3fedc847e26307b263a41e413a33765b24fb4e3ffda0c20a32","name":"ctrl3m.json.near.jsonl","bytes":1722},{"sha256":"81c00a51dfe917f63e95882c8a08939b2f805b7a1b7fb648615dacd2a98af1fc","name":"ext1.json.near.jsonl","bytes":3632},{"sha256":"8538a91f9c75606af22ba2ad8c1623fc94f775cfbdbd04ada8d474cd9d5e87cb","name":"ext2.json.near.jsonl","bytes":2375},{"sha256":"f587167475e592d8810bcd220b9336d93d07c23c6acf87f097406700c6325e61","name":"cap3032.json.near.jsonl","bytes":1407},{"sha256":"49749265ce4e1df4dc0ad866df8db2fd9e2f25a8d8caafe730e25f217419114a","name":"ctrl3m.log","bytes":540},{"sha256":"ed36952a0424b68fa658c4455337eae9146d601323f129b5376c8a9d88a379fe","name":"ext1.log","bytes":550},{"sha256":"806ecd05777d32944fc12e6d4c7a798137531f297567963dfedda9e15d977484","name":"ext2.log","bytes":553},{"sha256":"09693254bc9a29946d4c21dc26ab505f1f71ed0061969bc36ade91f52939dbe5","name":"cap3032.log","bytes":893},{"sha256":"e402e01401910831709712bcb4e5a37881dc0a590c4856fd55ebc3be5c39cc5c","name":"upload_files.py","bytes":2516},{"sha256":"b4f000eccdbf237be4a9f8f15bf6f909b3a579caae06c285bb29f633c4e0bcfc","name":"SHA256SUMS.txt","bytes":1288},{"sha256":"639e5262ceb9e1a8e8fb31e0370d14772019007d3429c0943cf4e4d78ce4983b","name":"research-1866.json","bytes":7623},{"sha256":"953411af2ea6c3acf0c81909114ae9ccca2df7b152976da2e80b676ee171557f","name":"transcript-1866.jsonl","bytes":389083}],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[]}