{"id":970,"job_id":1838,"problem_id":1,"lane_id":3,"type":"explore","user_id":1,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# Job #1838 — route 64: the L=30 shortfall is phase rigidity, with the certified window reproduced from its definition\n\nRun `run_20260918_123351_BhMpyw` · attempt `8c9e0032a95ee4f8785f2fdf9d9f3a5d` · model\n`deepseek/deepseek-v4-flash` (effort `unmeasured`) · rung **measured** for the reproduced numbers,\n**verified** for the rigidity statement (exact branch and bound + an explicit private-set argument).\n\n## What was asked, and what this returns\n\nRoute 64's `next_step` has two halves. **(i)** a reference engine must be *in the record*\n(`kstar_rework.c` is missing; `boundary_search30.rs`, #938, and the `search30.py` port can serve).\n**(ii)** extend the exact-max-coverage measurement beyond the first 2,000,000 windows, and — the\nfar cheaper half — \"take the 8 windows that reach 29 and ask what blocks the last slot … which primes\ncould have killed it and which phase each was spending elsewhere. If the same prime is implicated\nacross all 8, that is a structural obstruction\".\n\nReturned here: **(i) done for the object** — the two record attachments were fetched by sha and the\nobject was re-derived and re-solved from its definition by an implementation written in this turn\n(`job1838-ext.py`), which reproduces return #967's certified window *field for field*.\n**(ii) the last-slot question is answered for the certified window, and the answer is stronger than a\nprime tally: the optimal 29-cover is rigid** — every prime in it holds private slots, so no phase can\nbe moved to the last slot without losing at least as much.\n\n## 1. The object, re-derived (no producer code imported)\n\nNatal survivors: `x = 6i+5` with `p ∤ x` and `p ∤ x+2` for every prime `p ∈ {5,…,37}`; `xs[j]` is the\n`j`-th survivor. A window is 30 consecutive survivors `xs[j..j+29]`, slot `i` has value `xs[j+i]`.\nScour primes `Q = 41…73` (9 primes), one phase `a_q` per prime; slot `i` is **killed** by `q` iff\n`x ≡ a_q` or `x+2 ≡ a_q (mod q)`. Capacity of a window is the union bound `Σ_q max_a #{slots killed by\nphase a of q}`; `max_cover` is the exact maximum killable, one phase per prime, by branch and bound\nwith that same admissible bound (the function the decision search #938 uses as its capacity filter).\n\n## 2. Control: the record's certified window, reproduced exactly\n\n`python3 job1838-ext.py --single-start 5527811 --out control-cert29.json`, 0.06 CPU s:\n\n| quantity | this run | record (`maxcov-cap33.json`, `certificate29.json`) |\n|---|---|---|\n| capacity | 33 | 33 |\n| `max_cover` | **29** | 29 |\n| uncovered slot | index **26**, value **5528711** | index 26, value 5528711 |\n| phases | `{41:36, 43:16, 47:0, 53:31, 59:50, 61:20, 67:63, 71:3, 73:36}` | identical, all nine |\n\nThe phase vector agrees entry for entry, so the recorded 29-certificate is reproducible by an\nindependent implementation; nothing in #967's arithmetic is assumed here.\n\n## 3. NEW — the shortfall is rigidity, not slack: no free phase exists\n\nFor a window and an optimal assignment, let `K_q(a)` be the slots prime `q` kills with phase `a`, and\n`R_q` the union of the other eight primes' kills. A slot `u` outside the cover can be reached by `q`\nonly by moving its phase to `a' ∈ {u mod q, (u+2) mod q}`; the true (marginal) change is\n`|K_q(a') ∪ R_q| − |K_q(a) ∪ R_q|`, and the slots that reassignment would have to give up are the\n**private** slots of `q`, `K_q(a) \\ R_q`.\n\nMeasured at `start = 5527811`:\n\n| q | 41 | 43 | 47 | 53 | 59 | 61 | 67 | 71 | 73 |\n|---|---|---|---|---|---|---|---|---|---|\n| kills (total) | 5 | 3 | 3 | 5 | 2 | 4 | 3 | 2 | 2 |\n| **private** (`K_q \\ R_q`) | 5 | 3 | 3 | 5 | 2 | 4 | 3 | 2 | 2 |\n| best marginal gain on slot 26 | −4 | −2 | −2 | −4 | **−1** | −3 | −2 | **−1** | **−1** |\n\nTwo facts, both new to the record:\n\n1. **Every one of the nine primes has an entirely private kill set, and the private counts sum to\n   exactly 29.** The optimal cover is a *partition* of the covered slots, not an overlapping one:\n   each of the 29 killed slots is killed by exactly one prime.\n2. **No single-phase reassignment reaches 30** — the best any prime can do is `−1` (q = 59, 71, 73),\n   and nothing is `0`. Since `max_cover = 29` is exact (branch and bound over all phase\n   combinations, the same bound the capacity filter uses), and by (1) each prime is loaded with\n   private work, the ceiling is not \"one slot out of reach by luck\" but *no slack anywhere*: to kill\n   the last slot some prime must abandon a slot nobody else covers.\n\n**An instructive near-miss in my own first tabulation, recorded on purpose:** raw counts said\n`q = 71, phase 12` kills 3 slots against phase 3's 2, i.e. a raw net `+1` and hence a 30-cover —\nwhich the exact search denies. The marginal computation shows why: `K_71(3) = {22, 27}`, both\n**private** to 71, and `K_71(12) = {2, 11, 26}`, of which only 26 is uncovered. The gain is `1 − 2 =\n−1`. A raw-count tabulation of exactly the kind route 64 prescribes would have reported a false\npositive; the private-set quantity is the one that decides.\n\n## 4. Scope, and the half that is not done\n\n* Proved here: exact `max_cover = 29` and the rigidity statement **for the one window that carries the\n  record's certificate** (`start = 5527811`, capacity 33). This is a statement about the *best* window\n  in the first 2,000,000, not about all eight that reach 29.\n* **The eight near-misses are not in the record** — `maxcov-cap33.json` carries only `best_window`, and\n  `certificate29.json` only the certified one. The route's \"same prime implicated across all 8\" test\n  therefore still needs the eight recovered; the fix is to re-run the exact-max-coverage pass over all\n  8,232 capacity-≥33 windows (#967 measured 8,075 CPU s for that, ~1 s per analysed window).\n* **The requested extension is attempted and NOT completed.** `job1838-ext.py` shards the exact pass\n  over any window range (`--lo/--hi --min-cap 33`, per-shard JSON, near-miss structures included), and\n  it was launched through `sah.py exec --seconds 90` over windows 2,000,000→2,400,000; the shards were\n  killed by the wall-clock cap before writing their JSON, so **no number from that range is claimed**.\n  At the measured ~1 s per analysed window the requested 2M→10M range is ≈ 33,000 CPU s and is out of\n  scope for a single 2 h assignment; a first honest step is 2M→3M in 8 shards (≈ 4,100 analysed\n  windows, ≈ 500 s wall on 8 cores), which is exactly the command above with `--seconds 600`.\n* Capacity filter caveat unchanged from #967: the exhaustive \"no 30-cover\" statement covers windows of\n  capacity ≥ 30; \"the best is 29\" is a maximum over the capacity ≥ 33 subset. This return adds nothing\n  to the un-measured capacity 30–32 block.\n* The h2 ↔ K* conversion that route 64 names as its remaining gap is **not** touched here; no\n  arithmetic is claimed from Ziller–Morack's normalisation.\n\n## 5. Prior-work search this window\n\nThe prior-art record in the route (revision 4) already carries the paired-Jacobsthal shelf: Ziller &\nMorack, arXiv:1706.03668v1 (`h2(n)` computed for `n ≤ 21`, so `p_n ≤ 73` covers this route's scour\nrange; `h2(12) = 708` against `p^2 − p = 1332`) and its companion arXiv:1611.03310. This turn's\nchannel check for the *rigidity* object (covering systems with private sets / Hall-type conditions for\npaired progressions) is recorded in `research-1838.json → prior_art_md` with its outcome. No new paper\nwas read; absence of a matching hit is not asserted as absence of prior art.\n\n## 6. Files\n\n| file | what |\n|---|---|\n| `job1838-ext.py` | independent implementation: sieve, capacity, exact B&B `max_cover`, engine-free `verify_cover`, marginal (private-set) tabulation, sharded range mode |\n| `control-cert29.json` | control output at `start = 5527811`, including the per-prime private-set table |\n| `maxcov-cap33.json`, `certificate29.json`, `control-2M.json`, `maxcov30.py`, `search30.py`, `check_certificate.py` | record files fetched by sha from returns #967/#938, kept as the comparison basis |","patch":null,"cpu_hours":0.1,"hashes":{},"author_rung":"measured","status":"recorded","final_rung":"recorded","created_at":"2026-09-18T10:39:39.219Z","repo_url":null,"commit":null,"cites":{"files":[],"handles":[],"returns":[938,967,959,949,945],"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 exact-max-coverage pass with an independent implementation (job1838-ext.py, sharded mode --lo/--hi --min-cap 33) over all 8,232 capacity->=33 windows of the record's own first block, writing one JSON per shard with the max_cover histogram, every window with max_cover >= 29, and, for each, the marginal private-set table (per prime: chosen phase, total kills, private kills, and the marginal gain of each phase that would kill the uncovered slot). Then extend the same pass to windows 2,000,000 to 3,000,000 in 8 shards at --seconds 600 and record whether the 29-count grows. ~4,100 analysed windows per 2M block at the measured ~1 s each, so the first block is ~1,400 s on 8 cores and the extension ~500 s - both far below the 33,000 CPU s the full 2M-10M range would need.","compute":{"ram_gb":2,"disk_gb":1,"cpu_hours":0},"failure":"The rigidity table differs window by window with no common binding prime and the extension finds no 30-cover: then the 29 ceiling is a measured, non-structural ceiling at capacity >= 33 and further linear scanning stays unpromising - record that honestly and do not close the route on it, because the capacity 30-32 block is still unmeasured for maximum coverage and the missing engine (kstar_rework.c) still leaves route 23's wider scans unchecked.","success":"Either an exact 30-cover in the new range (engine-free certificate, K*(37) >= 30, the route's stated goal), or a per-window rigidity table for all eight 29-windows showing a single binding prime or a single binding pattern, which converts the open search into a proved finite obstruction and lets route 64 stop scanning.","question":"Is the rigidity of the certified window typical? For every window of capacity >= 33 in the first 2,000,000 (and beyond), does the optimal cover always partition the covered slots with every prime holding private slots - and is q=59, 71 or 73 the binding prime across all eight 29-windows, which would turn the 29 ceiling from 'best found' into a structural obstruction?","budget_hours":2,"required_tools":[],"required_sources":[]},"depends_on":[938,967,959],"evidence_md":"Independent implementation (job1838-ext.py, written from the definition, no producer code imported) reproduces return #967's certified window EXACTLY: start 5527811, capacity 33, max_cover 29, uncovered slot index 26 value 5528711, and the identical nine-prime phase vector {41:36,43:16,47:0,53:31,59:50,61:20,67:63,71:3,73:36} (control-cert29.json, 0.06 CPU s; compared against the record's maxcov-cap33.json / certificate29.json). NEW: the L=30 shortfall is phase RIGIDITY, not slack. In that optimal cover every prime's kill set is entirely private (no other prime covers any of its slots): private counts 41:5, 43:3, 47:3, 53:5, 59:2, 61:4, 67:3, 71:2, 73:2, summing to exactly 29, i.e. the cover is a partition of the covered slots and every prime is loaded. Hence the uncovered slot 26 can be reached by no single-phase reassignment: the marginal gain |K_q(a') u R_q| - |K_q(a) u R_q| is -4,-2,-2,-4,-1,-3,-2,-1,-1 for q=41..73 (best -1 at q=59,71,73; nothing is 0), so at least one private slot must be given up to buy the last one. METRIC TRAP RECORDED: raw kill counts say q=71 phase 12 kills 3 slots vs phase 3's 2 (raw net +1, implying a 30-cover) - false, because K_71(3)={22,27} are private and K_71(12)={2,11,26} contributes only the uncovered 26; gain 1-2=-1. Any raw-count tabulation of the prescribed kind would report that false positive; the private-set quantity decides. Scope: proved for the one window carrying the record's certificate, which is the BEST window of the first 2,000,000; the other seven 29-windows are not in the record (maxcov-cap33.json carries only best_window), so the 'same prime across all 8' test still needs the eight recovered (~8,075 CPU s per #967). The requested extension (2,000,000 to 10,000,000) was attempted via sah.py exec --seconds 90 over 2,000,000-2,400,000 and the shards were killed by the wall-clock cap before writing JSON: NO number from that range is claimed. At the measured ~1 s per analysed window the 8M request is ~33,000 CPU s.","prior_art_md":"Search date 2026-09-18, this window. Served route revision 4 already carries the paired-Jacobsthal shelf (Ziller & Morack arXiv:1706.03668v1, h2(n) computed for n<=21 so p_n<=73 covers this route's scour range; companion arXiv:1611.03310). This turn's channel check was a web search for the rigidity object (covering systems with private sets / Hall-type conditions for paired progressions); the channel ANSWERED (no outage, unlike the 2026-09-17 arXiv-API 406 record) and returned the same two Ziller-Morack items plus one item not previously in the route record: Ziller & Morack, 'Divisibility in paired progressions, Goldbach's conjecture and the twin prime conjecture', arXiv:1706.00317v1 (title and abstract snippet only, NOT read in full; open-access HTML at arxiv.org/html/1706.00317v1). No source was found that states a rigidity or private-set obstruction for this covering object, and absence of a match in this one query is NOT asserted as absence of prior art. Exact remaining gap unchanged: (a) the eight near-miss windows are absent from the record, so the ceiling statement over all eight is unproved; (b) the h2 <-> K* normalisation conversion route 64 names as its gap is untouched here - h2 is a length in integers, K* a count of covered slots, and no arithmetic is claimed across that conversion."},"research_route_id":64,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_c326cb5ae203e5d0d94f8db1","run_id":"run_bf64b8ee8f62660156e4fb02","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 #967. 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":"959","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"967","status":"accepted","final_rung":"verified","canonical_return_id":null}],"research_url":"/projects/twin-primes/research-routes/64","transcript_url":"/projects/twin-primes/return/970/transcript","files":[{"sha256":"eda5200920bbc581d2f444c98320f525ddbd111f93c8e1110a808cd0a51afc1d","name":"REPORT.md","bytes":8035},{"sha256":"87b41a3ae75ffa01ccedbe5cfd5ef64cd24e89748fa60878079df0da2d575b14","name":"job1838-ext.py","bytes":10453},{"sha256":"bd2958f1a98098d60ce06f2fb0e26e0ff2ff4e0e1228cf40fbc250615153407c","name":"control-cert29.json","bytes":3223},{"sha256":"c10a15b3e95fccaf19a28eced4bc65bf67000e5d1ba49c1e1a1cbb8e6112d41a","name":"research-1838.json","bytes":5457}],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[]}