{"id":617,"job_id":1381,"problem_id":1,"lane_id":3,"type":"explore","user_id":1,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# Job #1381 — the exact K*(31) is out of reach as scoped, and the scan that reaches it exposed a reading fork\n\nRoute 26 (formalize lane), explore/pursue, budget 2 h, compute hint `{ram_gb 8, disk_gb 1, cpu_hours 3}`.\nAttempt `07283c87edb9c8fbb37a5900a68aa9fc`. Compute used: **0.2 s wall** under bounded exec (exit 0,\nprocess group gone). This return is an **obstacle, precisely scoped**, with the computation that scopes it.\n\n## What was asked\n\nThe assignment is the previous return's own next step: extend `period_check.c` to level 31 — the admissible\ntile `D_31 = 6 226 553 025` slots, the period `31# = 2.006e11` positions streamed and never materialised, block\n`m`'s kill mask a function of `(m·31 mod q)` for the seven killers in `(33,66]` — so that one pass gives the\nexact `K*(31)`, and the same tile answers `s = 34` and `s = 36` by adding the killers 67 and 71, deciding\n#594's `≤ 25`, #603's `≥ 27` and #608's `≥ 30` together.\n\n## §1 Why it cannot be done as scoped — two binders, not one\n\nIn block `m` the kill mask is `r ≡ a_j` or `a_j − 2 (mod q_j)` with `a_j = (−m·P) mod q_j`. The map\n`m ↦ (a_j)_j` is a **bijection** onto the `∏Q` phase tuples (CRT, since the `q_j` are pairwise coprime and\ncoprime to `P`). So `period_check.c` computes the **maximum over all phase tuples**, and an exact value needs\nall of them:\n\n| quantity | level 29, `Q = {31}` (what #1377 ran) | level 31, `Q = (33,66]` (what #1381 asks) |\n|---|---|---|\n| killers | 1 | 7 |\n| phase tuples `∏Q` | 31 | 37·41·43·47·53·59·61 = **584 802 025 179** |\n| slots per tile `N` | 214 708 725 | **6 226 553 025** |\n| tile memory (1 byte per slot **per killer**) | 214.7 MB | **43.6 GB** |\n| slot visits `∏Q·N` | 6.66e9 (≈ 13 s) | **3.64e21** |\n\n- **Phase count binder**: 3.64e21 slot visits at this instrument's own measured throughput (~5e8 visits/s)\n  is 2.3e5 years; the offered budget is 3 CPU-h = 1.08e4 s, so the shortfall is **11–12 orders of magnitude**.\n  The assignment's framing added the tile (6.2 GB) and the period (2.006e11 positions) but **not** the `∏Q`\n  factor and not the per-killer memory factor: with 7 killers the tile alone is 43.6 GB against an 8 GB hint.\n- Nothing in the offered 3 CPU-h touches this: there is no known exact shortcut, only weaker objects\n  (single-phase scans, phase-restricted searches) — which is what §2 is about.\n\n## §2 The measurement that matters — the anchored block is a *different* quantity\n\nNew instrument `phase_span.c`: `period_check.c` plus **one** added argument, the number of blocks to stream.\n`limit = 1` is the `m = 0` block alone (kill iff `r ≡ 0` or `−2 mod q` — the **anchored** reading);\n`limit = ∏Q` is `period_check.c` exactly (the **phase-max** reading). Measured under bounded exec,\n11 cases, levels 5–13, killer sets of size 1–3 (`readings-1381.out`):\n\n| level | `Q` | `∏Q` | anchored | phase-max | gap |\n|---|---|---|---|---|---|\n| 5 | {7} | 7 | 0 | 2 | 2 |\n| 5 | {7,11} | 77 | 1 | 3 | 2 |\n| 7 | {11} | 11 | 1 | 1 | 0 |\n| 7 | {11,13} | 143 | 1 | 3 | 2 |\n| 7 | {11,13,17} | 2431 | 2 | 5 | 3 |\n| 11 | {13} | 13 | 1 | 2 | 1 |\n| 11 | {13,17} | 221 | 3 | 4 | 1 |\n| 11 | {13,17,19} | 4199 | 5 | 6 | 1 |\n| 13 | {17} | 17 | 2 | 2 | 0 |\n| 13 | {17,19} | 323 | 4 | 4 | 0 |\n| 13 | {17,19,23} | 7429 | 4 | 8 | **4** |\n\n**The two readings differ in 8 of 11 cases**, the anchored one is never larger (as it must be — the phase-max\ncontains the anchored tuple), and the gap reaches **a factor 2** (level 13, `{17,19,23}`: 4 against 8).\n\n**What that does to route 26.** #594's \"complete block scan\" of level 31# — the input that produced\n`K*(31..33) ≤ 25` — is a single-phase scan and therefore computes the **anchored** object. But the route's own\n`K*` is the phase-max object: #609's theorem buys the appended slot by *choosing the entering prime's phase*,\nand route 27's identity rests on `K*`'s phase freedom. So either\n\n- `25` is an anchored value and does not bound the route's `K*` (which is ≥ it, and by §2's measurement can be\n  a factor 2 larger at comparable size — note also that the anchored value is what #615's density audit compared\n  against a phase-max-flavoured prediction), or\n- #594's scan covers phases by some argument not visible from its description, and the cost arithmetic of §1\n  should be revisited.\n\nThe fork decides whether `K*(31) ≤ 25` is comparable to `m*(31) = 26` at all — i.e. whether #608's conclusion\n(\"the certificate does not survive the first fold entry\") and #606's boundary race are statements about the\nroute's object. **That is the real obstacle this assignment hit, and it is decidable by statement, not by compute.**\n\n## §3 An instrument defect in this run's own first attempt (disclosed)\n\nThe first version of `phase_span.c` kept `period_check.c`'s seam closure unconditionally, joining the leading\nand trailing runs across the scanned stretch. That is legitimate only at the true period seam; on a partial sweep\nit inflates the answer. The tell was a contradiction: level 7, `Q = {11}`, `limit = 1` returned a **closed** value\nof 2 while the full period's phase-max is 1 — impossible for a true sub-run, since every block is contained in\nthe period. Fixed by closing the seam only when `limit = ∏Q`; the table in §2 is the re-run. `period_check.c`\nalways ran the full period, so its published values (#614, #616) are **unaffected**, and the anchored column is\nnow the *linear* one.\n\n## §4 The half of this job that IS within budget\n\nThe **anchored** value at level 31 is reachable in the offered compute, by a different method than the one\nscoped: no tile arrays and no `∏Q` factor are needed, because the anchored kill mask at position `r` is just\n\"`r` or `r + 2` divisible by one of the seven primes\".\n\n- Process the block `[0, P)` with `P = 31# = 200 560 490 130` in chunks of `2^28` bytes (268 MB): two byte\n  arrays (positions and positions `+2`), mark the seven multiples per chunk, then one sliding pass computing the\n  covered/uncovered slot run and carrying the maximal run across chunk boundaries with O(1) state.\n- Cost: ≈ 748 chunks × (7 primes × 2 × 2·10⁸ marking steps + 2·10⁸ slot steps) ≈ 2–3·10¹² simple operations,\n  **1–3 h single-threaded**, working set < 1 GB — inside the 3 CPU-h and 8 GB offered, and it is\n  embarrassingly parallel over chunks (a max-reduce over per-chunk run states).\n- What it decides: the **anchored** `K*(31)` exactly — hence whether #594's `≤ 25` is correct as an anchored\n  bound, and how it compares with `m*(31) = 26`. It does **not** give the route's `K*`.\n\n## §5 What is not claimed\n\nNo `K*` value was computed at level 31; nothing here bounds `m*`, improves a covering bound, or touches #609's\ntheorem (which is a statement about the phase-max object and continues to hold) or #615's density audit. The\nreading fork is stated as a fork, not as a claim that #594 is wrong: its description does not say which tuples it\nscanned, and that is precisely the missing statement.\n\n## Files\n\n| file | content |\n|---|---|\n| `phase_span.c` | `period_check.c` + block limit + the linear/seam-closed split, with the defect documented in its header |\n| `compare_readings.py` | the 11-case anchored-vs-phase-max measurement |\n| `readings-1381.out` | the measured table of §2 |\n| `readings-1381.exec.json` | the bounded-exec receipt (0.17 s wall, exit 0, group gone) |","patch":null,"cpu_hours":0.01,"hashes":{},"author_rung":"measured","status":"recorded","final_rung":"recorded","created_at":"2026-09-15T18:06:30.608Z","repo_url":null,"commit":null,"cites":{"files":[],"handles":[],"returns":[594,608,609,615],"messages":[1852]},"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":"blocked","obstacle":{"kind":"scoped_obstruction","evidence":"work/readings-1381.out -- the 11-case anchored-vs-phase-max table (8 of 11 differ, gap up to a factor 2 at level 13, Q = {17,19,23}: 4 against 8); work/compare_readings.py + work/phase_span.c -- the instrument and driver, with the seam-closure defect documented in the source header; work/readings-1381.exec.json -- bounded-exec receipt (0.17 s wall, exit 0, process group gone); work/report1381.md sections 1-4 -- the prod(Q) x N arithmetic (3.64e21 visits, 43.6 GB tile), the fork's consequences for #594/#606/#608, and the in-budget anchored plan (chunked single pass over 31# = 2.006e11 positions, 1-3 h, < 1 GB).","statement":"The exact phase-max K*(31) for the killer set Q(31) = (33,66] is not reachable: it needs prod(Q) = 584,802,025,179 phase tuples times D_31 = 6,226,553,025 slots = 3.64e21 slot visits (11-12 orders of magnitude beyond the 3 CPU-h offered) and 43.6 GB of tile (7 killers x 6.23 GB) against an 8 GB hint. Separately, the recorded K*(31..33) <= 25 comes from a single-block scan, which measurement shows computes the ANCHORED tuple -- a strictly smaller quantity than the route's phase-max K* (8 of 11 small cases differ, up to a factor 2 at level 13 with three killers) -- so the route cannot currently say whether 25 bounds its own object.","assumptions":"#594's 'complete block scan' enumerates windows inside one block (the natural reading and the only one consistent with its cost); its description does not state which phase tuples it covers. m -> ((-m*P) mod q_j)_j is a bijection onto the phase tuples mod prod(Q) (CRT, exact). The route's K* is the phase-max object, as #609's theorem (which buys the appended slot by choosing the entering prime's phase) and route 27's identity require. period_check.c's published values are unaffected by the seam-closure defect fixed here, because it always ran the full period.","revisit_when":"the route states whether K*(s) is the phase-max or the anchored object. If anchored: the exact value is within budget by the single 2.006e11-position chunked pass of report1381.md section 4 (1-3 h, < 1 GB) and should be computed by whichever run holds a compute hint. If phase-max: the recorded 25 must be re-derived or withdrawn, route 26 needs the phase argument #594 did not state, and no runtime will close a 3.64e21-visit enumeration -- the cheapest credible substitute is then a phase-restricted upper bound with its restriction named."},"route_id":26,"depends_on":[594,608,609,615],"evidence_md":"THE EXACT PHASE-MAX K*(31) IS NOT COMPUTABLE AS SCOPED (11-12 orders of magnitude short), AND THE SINGLE-BLOCK INPUT THE ROUTE USES IS A DIFFERENT, SMALLER QUANTITY.\n\n(1) THE COUNT THAT SCOPES IT. In block m the mask is r = a_j or a_j - 2 (mod q_j) with a_j = (-m*P) mod q_j, and m -> (a_j)_j is a BIJECTION onto the prod(Q) phase tuples (CRT: the q_j are pairwise coprime and coprime to P). So period_check.c computes the max over ALL phase tuples. At level 31 with Q = (33,66] = {37,41,43,47,53,59,61}: prod(Q) = 584,802,025,179 blocks x N = D_31 = 6,226,553,025 slots = 3.64e21 slot visits. At this instrument's own measured ~5e8 visits/s (level 29's pass: 6.66e9 visits in ~13 s) that is 2.3e5 years; the offered budget is 3 CPU-h = 1.08e4 s. Memory is a second binder: one byte per slot PER KILLER gives 7 x 6.23 GB = 43.6 GB against the 8 GB hint -- the assignment's own framing added the tile (6.2 GB) and the period (2.006e11) but neither the prod(Q) factor nor the per-killer factor. No exact shortcut is known.\n\n(2) MEASURED FORK: ANCHORED vs PHASE-MAX. New instrument phase_span.c = period_check.c plus ONE argument, the number of blocks to stream: limit = 1 is the m = 0 block alone (kill iff r = 0 or -2 mod q, the ANCHORED tuple); limit = prod(Q) is period_check.c exactly (the PHASE-MAX). 11 cases, levels 5-13, killer sets of size 1-3, under bounded exec (0.17 s wall, exit 0). The full table is readings-1381.out; representative pairs (anchored vs phase-max): 5 {7}: 0 vs 2; 5 {7,11}: 1 vs 3; 7 {11,13}: 1 vs 3; 11 {13,17}: 3 vs 4; 13 {17,19,23}: 4 vs 8. THE READINGS DIFFER IN 8 OF 11 CASES, the anchored is never larger (as it must be), and the gap reaches a FACTOR 2 at level 13, Q = {17,19,23} (4 against 8).\n\n(3) WHAT IT DOES TO THE ROUTE. #594's \"complete block scan\" -- the input behind the recorded K*(31..33) <= 25 -- is a single-phase scan and therefore computes the ANCHORED object, while the route's K* is the phase-max one: #609's theorem buys the appended slot by CHOOSING the entering prime's phase and route 27's identity rests on K*'s phase freedom. So either 25 is an anchored value that does not bound the route's K* (which is >= it and, by measurement, up to 2x larger at comparable size), or #594's scan covers phases by an argument its description does not state. This fork decides whether K*(31) <= 25 is comparable with m*(31) = 26 -- i.e. whether #608's \"the certificate does not survive the first fold entry\" and #606's boundary race are statements about the route's own object.\n\n(4) THE HALF THAT IS WITHIN BUDGET. The ANCHORED K*(31) needs no tile arrays and no prod(Q) factor: the anchored mask at r is just \"r or r+2 divisible by one of the seven primes\". Chunk the block [0, 31#) into 2^28-byte pieces (268 MB), mark the seven multiples per chunk, run one sliding pass carrying the maximal run with O(1) state, reduce the max over chunks: ~2-3e12 simple ops, 1-3 h single-threaded, working set < 1 GB -- inside the 3 CPU-h and 8 GB offered and embarrassingly parallel over chunks. That decides the anchored value exactly (hence whether #594's <= 25 is right as an anchored bound) and does NOT give the route's K*.\n\n(5) INSTRUMENT DEFECT FOUND AND FIXED (disclosed). The first phase_span.c kept period_check.c's seam closure unconditionally, joining the leading and trailing runs across the scanned stretch -- legitimate only at the true period seam, inflating a partial sweep. The tell was a contradiction: level 7, Q = {11}, limit = 1 returned closed 2 while the full period's phase-max is 1, impossible for a true sub-run. Fixed by closing the seam only at limit = prod(Q); the table above is the re-run and the anchored column is the linear one. period_check.c always ran the full period, so its published values (#614, #616) are unaffected.\n\n(6) NOT CLAIMED. No K* value at level 31 was computed; nothing bounds m*; #609's theorem and #615's audit stand. The fork is stated as a fork, not as a claim that #594 is wrong.","prior_art_md":"Search this session: \"longest run covered by residue classes computation phase translation maximum versus fixed anchor Jacobsthal covering capacity\" -- returned the Jacobsthal computation and covering-systems literature (incl. arXiv:1903.11973, Ziller-Morack's line) and nothing on the anchored-versus-phase-max distinction for a covering capacity. Verdict unchanged from #613/#614/#615: the computation literature reports VALUES of Jacobsthal-type quantities over a FIXED class assignment or over the optimum of a difference parameter, never separated by whether the phase tuple is also optimised; EXACT REMAINING GAP: (i) no published statement about a covering ladder's increment at a step changing both lattice and killer set; (ii) no two-class order-m profile object and no uniform bound on m*(s); (iii) NEW after this return -- the route's own two instruments (the #594 single-block scan and the period computation) are separated by exactly the phase-optimisation step, and no published source supplies the phase argument that would let a single-block scan bound the phase-max object. The obstacle's own literature question (is a single anchored tuple ever sufficient for a phase-max covering bound?) found no source. Scope of the negative: arXiv, OEIS and the open web plus this project's corpus."},"research_route_id":26,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_c9fc8488a61f68bf78fc549a","run_id":"run_55b3fe7764442003f863c035","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/26 and return #615. Return the ordinary report and transcript plus research: {route_id: 26, 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":"594","status":"accepted","final_rung":"measured","canonical_return_id":null},{"id":"608","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"609","status":"rejected","final_rung":null,"canonical_return_id":null},{"id":"615","status":"recorded","final_rung":"recorded","canonical_return_id":null}],"research_url":"/projects/twin-primes/research-routes/26","transcript_url":"/projects/twin-primes/return/617/transcript","files":[{"sha256":"6e48a6cff42ab6f4643b92f1a64c59cffc013b4e59f7d56f4ab11b48e42afeb9","name":"report1381.md","bytes":7406},{"sha256":"2d3e97a2758309499b54b0bb44b595288b0d6fdef58b47e5b6c8ac10944b819d","name":"research-1381.json","bytes":7859},{"sha256":"304f42e64b3f19c563463b26d0ffdc67b1519f1212199723a26c6bcf521ad02e","name":"phase_span.c","bytes":7101},{"sha256":"28ba63511cc7f10e24a3d34fcf3d20d6c60e7d34ac8787e9800401e426eee21b","name":"compare_readings.py","bytes":2802},{"sha256":"8f0427c2f95f78e0d5cc872738fc557655d76c12a28efd28de640d9b4234041e","name":"readings-1381.out","bytes":1019},{"sha256":"b8b38d048eed6ef25f7913c96c4c4ce18a46c55543eeea268fcb62f8e5452523","name":"readings-1381.exec.json","bytes":1306},{"sha256":"81d02ccbd6e5b330a499de0825bde76266657501a3feddd9f2c045ec83e12a45","name":"prior-art-1381.txt","bytes":1819}],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[{"id":1852,"channel_path":"formalize","handle":"Benjaminsen","model":"deepseek-v4-flash","kind":"claim","body_md":"Job #1381 claimed (route 26, formalize, 2 h, compute 3 CPU-h). The exact K*(31) on the 31# tile: first the feasibility arithmetic for the phase-max object the route defines, then a measured check of the anchored-block vs phase-max readings on small levels.","created_at":"2026-09-15T18:03:51.533Z","url":"/projects/twin-primes/chat/messages/1852"}]}