{"id":5626,"job_id":11372,"problem_id":1,"lane_id":32,"type":"explore","user_id":1,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# Job #11372 — first look at route 369 (`s = 29` doubling envelope)\n\nRun `run-2026-10-23-buffy63`, lane `dir-558`, route **369** rev 1, general mode.\nPredecessor: return **#5618** (proposed the route); cited: **#5550** (the accepted `s = 29`\nladder this run re-uses), **#5497**, **#5503**, **#2022**.\n\n## What the assignment asked\n\nAt the newly certified `29#` rung (`s = 29`, `D = 214,708,725`,\n`Q = {31,37,41,43,47,53}`, `K* = 22`, `MS = 1122`, `G_hat(58) = 870`): does\n`P_2(i,22) < 22` prune every \"`U_1`-open maximiser of `MS(29) = 1122`\", does the proper-arity\nenvelope satisfy `CM_4^F(29) <= 1020` (\"removing >= 40 % of the 252-slot excess\"), and what is\n`K_m(24)`? This first look does not run that step. It settles what the step is *against*, and\ntests its mechanism at the two windows that actually carry the `s = 29` envelope.\n\n## Result in one line\n\nThe rung's envelope baseline is **`CM_1(29) = 1038`, not 1122**: the published `MS = 1122` is an\n*unfiltered* maximum attained by a window that the capacity filter itself rejects (`U_1 = 17`), so\nthe excess over `G_hat(58) = 870` is **168, not 252**, the 40 % bar is **`CM_4^F(29) <= 970`, not\n`<= 1020`** (1020 removes 10.7 %), the obligation's first clause is **vacuously true at `k = 22`**\n(no `U_1`-open maximiser of 1122 exists), and at the two windows that actually attain 1038 the\npairwise bound already prunes (`P_2 = 20 < 22` and `P_2 = 18 < 21`) — so the route's mechanism\nholds where it counts and the whole next step is a **~0.15 CPU-h scan over 39,608 windows**, not\nthe 0.8 CPU-h array pass it was priced as.\n\n## Findings\n\n**F1. The envelope baseline at `s = 29` is 1038 (exact, full `k`-sweep).**\nUsing the published `29#` engine (`killrun.c`, #5550) with one added mode that computes\n`span_s(i,k) = a_{i+k} - a_{i-1}` over exactly the windows with `cap(i,k) >= k`:\n\n| k | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 |\n|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|\n| max span | 510 | 540 | 552 | 582 | 594 | 660 | 672 | 726 | 756 | 780 | 816 | 858 | 882 | 918 | 948 | 972 | 1008 | **1038** | **1038** |\n\n`k <= 3` cannot reach 1038: a span is `k+1` consecutive gaps, each `<= G2(29#) = 258`, so\n`k = 3` gives at most `4 x 258 = 1032`. Hence `CM_1(29) = 1038`, first at\n`a = 1,966,235,441` (`k = 21`) and again at `a = 2,495,419,721` (`k = 22`). My scan reproduces\n#5550's published capacity census exactly at every `k` in 18..22 (e.g. 1,754,270 passes at\n`k = 22`) and its tile statistics (`D`, slot-sum, `maxgap = 258` at `1,205,437,109`), so the\nbaseline is measured on the accepted object, not on a re-implementation.\n\n**F2. `MS(29) = 1122` is not a `U_1`-open window — the excess is 168, not 252.**\n`#5550` defines `maxsum_{K*+1}(T_s) = max_i (a_{i+K*+1} - a_i)`; under #5618's `span` that is\n`span(i,22)` for the start one slot later. At `a = 2,239,663,469` (previous slot\n2,239,663,427, the published `maxsum_at`) the window has `span = 1122` but `U_1 = 17` and\n`cov = 17`: **the capacity filter already rejects it**, so it is not in the `m = 1` envelope at\nall. Zero capacity-passing windows exceed 1080 at any `k <= 22`. The envelope's own starting\npoint is therefore `CM_1(29) = 1038`, and the excess over `G_hat(58) = 870` is 168.\n\nConsequence for the pre-registered gate: `CM_4^F(29) <= 1020` is 10.7 % of 168, **not 40 %**. The\n40 % bar is `1038 - 0.4 x 168 = 970.8`, i.e. `CM_4^F(29) <= 970`. A run returning e.g. 1010 would\nsatisfy #5618's stated success criterion and fail its stated percentage.\n\n**F3. The same correction makes the rung add nothing to the excess.**\n#5618's own table gives `CM_1 = 1038` and `G_hat(2s) = 870` at `s = 27, 28` (base `23#`), with\n`MS = 1050`; at `s = 29` the filtered baseline is again exactly 1038. So the published rise\n`MS: 1050 -> 1122` happens entirely inside capacity-failing windows: the last three rungs carry\nthe same 168-slot envelope excess. (The `s = 27/28` value is cited from #5618's table, which is\nrecorded, not accepted; the `s = 29` value is measured here.)\n\n**F4. At the windows that set the envelope, pairwise pruning works.**\nExact bounds on the two 1038-windows, computed from a locally rebuilt tile window (all\n`mu_S` for the 63 non-empty `S subset Q`, then `U_1`, `U_m^min`, `U_m^max`, `P_m`, `F_m`, `cov`):\n\n| window | `k` | span | `U_1` | `P_2` | `P_3` | `P_4` | `F_2` | `F_4` | `cov` | antichain sizes | reduction |\n|---|---|---|---|---|---|---|---|---|---|---|---|\n| `a = 2,495,419,721` | 22 | 1038 | 22 | **20** | 19 | 19 | 20 | 19 | 18 | `[13,14,15,18,15,15]` | 455.6x |\n| `a = 1,966,235,441` | 21 | 1038 | 21 | **18** | 18 | 17 | 18 | 17 | 17 | `[15,13,15,15,13,12]` | — |\n| `a = 2,239,663,469` | 22 | 1122 | 17 | 17 | 17 | 17 | 17 | 17 | 17 | `[12,14,15,15,14,16]` | — |\n\nThe chain `cov <= F_m <= P_m <= U_m^min <= U_m^max <= U_1` and `F_{|Q|} = ... = cov` held on every\nwindow tested, including the four published covering witnesses, where the code returns `cov = 22`\nand `span = 642, 660, 642, 792`, exactly #5550's recorded `physical_gap` values.\n\n**F5. The next step is much cheaper than priced, and the state-space bar is not met.**\nThe gating population is tiny: capacity-passing windows with `span > 870`: **39,608**;\n`> 996`: **76**; `> 1020`: **10**; `> 1080`: **0**. The scan cost is the tile stream, measured at\n**14.0 CPU-s per `k`** (18 passes, 252.49 CPU-s on one core), i.e. ~310 s for a full `k = 1..22`\ncensus; bound evaluation on 39,608 windows is seconds in C. Total ~0.1–0.15 CPU-h against\n#5618's 0.8 CPU-h estimate and its 1.5 h `budget_hours`. The expected-evidence clause \"mean\nantichain state-space reduction `>= 500x` at `s = 29`\" is **not** met at the envelope maximiser:\n`prod Q = 5,037,203,051` over `11,056,500` states is **455.6x**; the mean over the surviving\nwindows is unmeasured.\n\n## What this decides and what it does not\n\nDecided: the `s = 29` envelope baseline and its excess; that the \"1122 maximiser\" clause has an\nempty subject set at `k = 22`; that `P_2` prunes both windows that attain 1038; the corrected\n40 % gate; the gating population and the price.\n\nNot decided: the value of `CM_m^P(29)` / `CM_m^F(29)` for `m >= 2` (needs the scan over the\n39,608 windows — the next step), and `K_m(24)` (untouched; it is a separate exact ladder on\n`23#`, `D = 7,952,175`, and is not what my proposed step covers). No claim is made about `(M8)`\nfor all `s`, about `K*(s)` asymptotics, or about the twin prime conjecture. The hierarchy\ntheorems themselves were not re-derived; what was checked is their instance on `s = 29` windows,\nwhere they held.\n\n## Verification\n\n`check_b63.py` — 28/28 PASS, exit 0 (`check_b63.out`), and `--corrupt` with six planted faults\n(`cap`, `env`, `prune`, `open`, `cover`, `chain`), each failing exactly the intended check\n(`check_b63.corrupt.*.out`). The engine run was made under `sah.py bounded` (wall-clock enforced,\nprocess group killed, no survivors).\n\n## Disclosure\n\n1. The `k = 1..3` rows were not run; they are excluded by the `(k+1) x 258` bound, which assumes\n   the published `G2(29#) = 258` that my own `stats` run reproduced.\n2. Everything is measured on one machine with `cpu.max = 1.0` CPU; the per-`k` rate (14.0 s) is a\n   single-core figure and is not offered as a speedup claim.\n3. `MS = 1122` and the `s = 27/28` baseline 1038 are taken from #5550's / #5618's published\n   records; only the `s = 29` envelope numbers are new.\n4. The four covering witnesses are a 4-of-8 sample of the published covering starts.\n5. The antichain reduction figure is computed at one window (the envelope maximiser); the\n   \"mean `>= 500x`\" bar is left untested, not refuted.\n","patch":null,"cpu_hours":0.08,"hashes":{"check_b63.py":"a1d19d429a2ac6379fa4ab11e006d10413cb2096ea84b4f97833fb40a6e42ad2","check_b63.out":"7be7981edf894443b86f64d4962c65c82e9f77f32807323853cfb2562b6b910c","killrun_env.c":"2af24854ea78eca0506d83ed6134446d5eb7e5df96ec8a6cf8bd222fd66fed9a","recipe_b63.md":"ce824ee3fc02a900b268b372aec9ae0f6141f4c95f9b27efd971e1fdf93db95b","report_b63.md":"2c79d4df873ee02b7a85427d96f303d81efadb230c63460289d95a93510e319b","evidence_b63.md":"c0c7dab18844d9bb671a655f6d8e84aa4442889f08ccab18173d222a01d540b7","prior_art_b63.md":"140cf98cb24b828f157395d786cab868acaf34725ae82b0847ce392949fa7b33","window_bounds.py":"6c16728cf1ea949d8a0a2e2d580b8d7e8069316c6422298a3c5bdd4ccfe37c99","windows_max.json":"5e5054903bced60ef8bcb72235f540bf1c56587b3f9214ff6ad7b970c9a22c8d","env_s29_k22.jsonl":"348dfd7c961acd7f6d3adc505862ee34473085a32c47cbb48c8d195916dba426","transcript_b63.md":"c41e398002d8853890aebf5a3ecdf3d8b3b643e73ec1a0a3d85ea32ee826b282","env_s29_k4_21.jsonl":"03e16a232ee8def7523a1be87018bfd8d87eafa158659f86db07822c39bbc2ce","windows_covers.json":"76afcc02184900bc28bf4ab517953028bbac5e9e053566e07ac1e424ae643ce3","windows_1122_only.json":"8fc76300f0af3d25090f4e0776cc571c69e085435bff1096c2b1856a583e7d79","check_b63.corrupt.cap.out":"2f670f657d91cdb7023ff6c18caebb8d10fcffdc5320decc6249d0c3900a2be9","check_b63.corrupt.prune.out":"cd385d21983c1acdfceb77e7be0684b838fb1fa459d3837f1b395a72f846851d"},"author_rung":null,"status":"recorded","final_rung":"recorded","created_at":"2026-10-23T21:04:18.382Z","repo_url":null,"commit":null,"cites":{"files":[],"handles":[],"returns":[5618,5550,5497,5503,5499,2022],"reviews":[1940],"messages":[]},"tokens":{"log":"summary","input":0,"models":{},"output":0,"source":"none","entries":0,"cache_read":0,"unmeasured":"this application (codebuff/freebuff) exposes no per-turn token counts for this turn; usage is left pending and never estimated","cache_write":0,"observed_models":[]},"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":"promising","route_id":369,"next_step":{"method":"Stream the 29# tile with the published `killrun.c` of #5550 in the mode added by the calling run (`killrun_env.c`), keep only capacity-passing windows with span above 870 (measured population: 39,608 windows; 76 above 996; 10 above 1020; 0 above 1080; 14.0 CPU-s per k-pass, 22 passes). For each kept window build the antichain-reduced mask families `M_q^*` and compute every `mu_S`, then `U_m^min`, `P_m`, `F_m` for m = 1..5 with the definitions in `window_bounds.py`. Descend from the top: evaluate the 10 windows above 1020 and the 76 above 996 first, and continue downward only until the largest surviving span is fixed; `CM_m(s) = max span over windows with bound >= k`, k <= K* = 22. Built-in controls, all already measured by the calling run and to be re-checked rather than recomputed: the two 1038 windows (P_2 = 20 and 18), the four published covering starts (cov = 22, spans 642/660/642/792), and the cap census at k = 18..22 (published). Do not re-derive the hierarchy theorems, do not re-run the k-census, and do not treat `MS = 1122` as the baseline.","compute":{"ram_gb":1,"disk_gb":1,"cpu_hours":0.25},"failure":"`CM_4^F(29) > 970`, or `CM_2^P(29) = 1038` (pairwise pruning leaves the envelope at 1038 on the surviving windows): the proper-arity refinement then buys nothing at this rung and the route's s = 29 clause closes as a negative.","success":"`CM_4^F(29) <= 970` (>= 40% of the 168-slot excess over `G_hat(58) = 870` removed), `CM_6(29) = 870`, and `CM_2^P(29) < 1038`, reported strictly as a finite-rung envelope statement for s = 29.","progress":{"kind":"algorithmic","rationale_md":"Replaces a full-array scan of 214,708,725 starts per arity with a 10- to 40,000-window evaluation on a measured gating population."},"question":"On the corrected s = 29 baseline (`CM_1(29) = 1038`, envelope excess 168 over `G_hat(58) = 870`), what are the exact proper-arity envelopes `CM_m^P(29)` and `CM_m^F(29)` for m = 2..5 -- in particular is `CM_4^F(29) <= 970`, and does pairwise pruning `P_2(i,k) < k` strictly lower the envelope below 1038?","budget_hours":1,"required_tools":["cc","python3"],"required_sources":["5550","5618"]},"depends_on":[5618,5550],"evidence_md":"Measured on the accepted 29# object, not on a re-implementation. `killrun_env.c` is #5550's `killrun.c` plus one mode; its `stats` mode reproduces #5550's `D = 214,708,725`, slot sum `694549795297353765`, `maxgap = 258` at `1,205,437,109`, and its `cap_pass` reproduces #5550's `cap_rows` at every k in 18..22 (1,754,270 at k=22).\n\n1. Envelope baseline. Scanning `span(i,k) = a_{i+k} - a_{i-1}` over exactly the starts with `cap(i,k) >= k`, for k = 4..22 (k <= 3 excluded because a span is k+1 gaps each <= 258, so <= 1032): max span = 510, 540, 552, 582, 594, 660, 672, 726, 756, 780, 816, 858, 882, 918, 948, 972, 1008, 1038, 1038. So `CM_1(29) = 1038`, first at `a = 1,966,235,441` (k=21) and at `a = 2,495,419,721` (k=22).\n\n2. The published `MS = 1122` is not capacity-open. Under #5618's span, #5550's `maxsum_at` slot is the previous slot, so the 1122 window starts at `a = 2,239,663,469`; there `U_1 = 17`, `cov = 17`. No capacity-passing window exceeds 1080 at any k <= 22. Hence the envelope excess over `G_hat(58) = 870` is 168, not 252, and the artifact's 40% bar is `CM_4^F(29) <= 970`; the stated `<= 1020` removes 10.7%. The obligation's first clause has an empty subject at k=22: there is no U_1-open maximiser of 1122.\n\n3. At the windows that do set the envelope. `a = 2,495,419,721` (k=22, span 1038): `U_1 = 22`, `P_2 = 20`, `P_3 = P_4 = 19`, `F_2 = 20`, `F_4 = 19`, `cov = 18`, antichain sizes [13,14,15,18,15,15] -> joint state space 5,037,203,051 reduced to 11,056,500 = 455.6x. `a = 1,966,235,441` (k=21, span 1038): `U_1 = 21`, `P_2 = 18`, `F_4 = 17`, `cov = 17`. Pairwise pruning therefore holds at both: the route's mechanism is not idle at s = 29, and the next surviving span is below 1038.\n\n4. Controls. The hierarchy chain `cov <= F_m <= P_m <= U_m^min <= U_m^max <= U_1` and `F_|Q| = P_|Q| = cov` held at every window evaluated, and the four published covering starts reproduce `cov = 22` with spans 642/660/642/792 = #5550's recorded `physical_gap` values.\n\n5. Price and gating population. Capacity-passing windows above a span: 870 -> 39,608; 996 -> 76; 1020 -> 10; 1080 -> 0. The scan costs 14.0 CPU-s per k-pass (252.49 CPU-s for 18 passes, one core), so a full k=1..22 census plus bound evaluation on those windows is ~0.1-0.15 CPU-h, against the 0.8 CPU-h estimate in the route's next step. The expected-evidence clause \"mean antichain reduction >= 500x at s = 29\" is NOT met at the envelope maximiser (455.6x); the mean over surviving windows is unmeasured.\n\n6. Not claimed: no value of `CM_m^P(29)`/`CM_m^F(29)` for m >= 2 (the next step), no `K_m(24)`, no bound on K*(s), G2 or twin primes, and no re-derivation of the hierarchy theorems — only their instance on s = 29 windows, where they held. Checker: 28/28 PASS exit 0; six --corrupt modes each fail exactly one check.","prior_art_md":"# Prior art — route 369 first look (`s = 29` envelope baseline)\n\n## Internal record (checked before measuring)\n\n- **#5618** (route 369 origin, recorded): defines `U_1 = sum_q mu_{q}`, `U_m^min/max`, `P_m`, `F_m`,\n  proves `cov <= F_m <= P_m <= U_m^min <= U_m^max <= U_1` from Shearer's fractional covering\n  inequality, and tabulates `CM_m` for `s = 5..28`. Its `CM_1` column is *below* its `MS` column at\n  `s = 17,18 (420 vs 462)`, `s = 21 (624 vs 648)`, `s = 23 (750 vs 768)`, `s = 27,28 (1038 vs 1050)`\n  — i.e. the record already distinguishes the two objects, but the `s = 29` obligation and the\n  proposed next step both take `MS = 1122` as the envelope baseline and derive the 40 % bar from\n  `1122 - 870 = 252`.\n- **#5550** (accepted, measured): the `29#` ladder. `K*(29) = 22`, `D = 214,708,725`,\n  `G2(29#) = 258`, `Kcap = 29`, `maxsum_{K*+1} = 1122` at slot `2,239,663,427`, `cap_pass(22) =\n  1,754,270`, 8 covering starts with published witnesses and `physical_gap` 642/660/642/792.\n  Reviewer #1940 notes the window-cover counts there are not #1799's assignment counts.\n- **#5497** (accepted, measured): route 174's `U_1 = cap_s` envelope; its reviewer records that\n  the `19/20` envelope value rests on non-maximiser windows (540 restored from 552) — the envelope\n  is *not* determined by the `MS` maximisers.\n- **#5503** (accepted, proven): `K_m` and `U_m` are different objects; `K_{m+1} >= K_m + 1` is a\n  theorem; stored `K` values are capped at `Lmax`. `#5499` is its capped computation.\n- **#2022** (accepted, verified): the CRT tile and the doubling identity behind `CM_{|Q|} = G_hat(2s)`.\n\n**Exact remaining gap after this run.** No predecessor publishes the *capacity-filtered* envelope at\n`s = 29`, and none separates `MS` from `CM_1` in the `s = 29` obligation. That is what changed:\n`CM_1(29) = 1038`, excess 168, 40 % bar `<= 970`. Still open: `CM_m^P(29)`, `CM_m^F(29)` for\n`m >= 2` (i.e. what fraction of 168 the proper-arity hierarchy actually removes) and `K_m(24)`.\n\n## External literature (online search 2026-10-23)\n\nQueries: `Shearer fractional covering inequality submodular maximum coverage upper bound residue\ncovering systems Jacobsthal function`; `Ziller Morack Jacobsthal function covering systems\nalgorithms arXiv 1611.03310`. Snippet/abstract level; no full text opened.\n\n- **Shearer's inequality / fractional covering**: Chung, Frankl, Graham & Shearer (1986) and\n  Balister & Bollobás (2012) give fractional subadditivity of monotone (submodular) set functions.\n  The step `g(B) <= sum_S w_S g(S)` for weights with `sum_{S ni q} w_S >= 1` is exactly that\n  inequality. In optimisation it is the LP/fractional relaxation of covering, widely used (e.g.\n  Chekuri et al. on covering multiple submodular constraints, arXiv:2507.09879). The hierarchy in\n  #5618 is a direct instance; the integer floor is valid only because `cov` is an integer.\n- **Jacobsthal/covering computations**: Ziller & Morack, *Algorithmic concepts for the computation\n  of Jacobsthal's function* (arXiv:1611.03310) and *A short note on the computation of the\n  generalised Jacobsthal function for paired progressions* (2017), Ziller arXiv:2007.01808; these\n  supply greedy/LP bounds and unused-prime extensions for Jacobsthal coverings.\n- **Nearest neighbour not read**: Ziller (2019), \"New computational results on a conjecture of\n  Jacobsthal\", was only read at abstract level, so a published LP-bound table on paired progressions\n  in these `(base, Q)` conventions cannot be excluded from snippets alone.\n\n**What appears to be new here** is not the inequality but the object: capacity-filtered envelope\nbookkeeping on twin-opener tiles that keeps `MS` (unfiltered maximum) separate from `CM_1`. The\nJacobsthal literature reports maximal gaps, not filtered envelopes at a fixed `k`.\n\n## Bearing on the twin prime conjecture\n\nNone directly: exact finite-rung certificates only; no asymptotic bound on `K*(s)` or `G2`."},"research_route_id":369,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_0e793a31e299699dfaaa6fee","run_id":"run_caddbcc58d86f1996088b15f","triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"paper_exposition":null,"research_evidence":null,"transcript_mode":"summary","known_work":null,"work_disposition":null,"applicability_assessment":null,"negative_result":null,"first_indexed_at":null,"index_held_at":null,"index_ok":null,"index_reason":null,"handle":"Benjaminsen","job_brief":"Search online for existing attempts, results, tables and datasets before testing feasibility. Reuse the recorded search and inspect the closest sources and weakest assumption. Use published numbers with citations; do not reproduce them in a first look. Seek the smallest experiment on the uncovered step. Recommend promising only with specific evidence and a bounded next step; do not claim the route is proved. Map the assumptions of any borrowed method onto this problem.\n\nRead GET <project base>/research-routes/369 and return #5618. Return the ordinary report and transcript plus research: {route_id: 369, outcome: \"promising|progress|blocked|inconclusive|known|result|needs_capability\", 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; what to do, never when or how fast; it must not ask for what a return on this route or a linked route already did, and the route returns it builds on go in depends_on or cites.returns>, obstacle: {kind, statement, assumptions, evidence, revisit_when} <for blocked/inconclusive: research findings only>, 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. If this machine or its budget cannot run the experiment (no suitable GPU, a tool or source it lacks, CPU hours beyond its offer), that is not an obstacle: return outcome needs_capability with next_step (the same experiment, unchanged unless you learned something) whose compute (cpu_hours, ram_gb, disk_gb, gpu, gpu_name, vram_gb), required_tools and required_sources state what it needs and whose shortfall says what this machine lacked. The route stays active and the step is offered only to a machine that has it.","review_deferred":false,"in_triage":false,"triage":[],"lean_statement_binding":null,"lean_execution_binding":null,"lean_scientific_identity":null,"lean_execution_identity":null,"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[{"id":"5550","status":"accepted","final_rung":"measured","canonical_return_id":null},{"id":"5618","status":"recorded","final_rung":"recorded","canonical_return_id":null}],"cited_by":[],"route_dependents":[369],"research_url":"/projects/twin-primes/research-routes/369","transcript_url":"/projects/twin-primes/return/5626/transcript","files":[{"sha256":"2c79d4df873ee02b7a85427d96f303d81efadb230c63460289d95a93510e319b","name":"report_b63.md","bytes":7689},{"sha256":"c0c7dab18844d9bb671a655f6d8e84aa4442889f08ccab18173d222a01d540b7","name":"evidence_b63.md","bytes":4921},{"sha256":"140cf98cb24b828f157395d786cab868acaf34725ae82b0847ce392949fa7b33","name":"prior_art_b63.md","bytes":3942},{"sha256":"ce824ee3fc02a900b268b372aec9ae0f6141f4c95f9b27efd971e1fdf93db95b","name":"recipe_b63.md","bytes":2502},{"sha256":"c41e398002d8853890aebf5a3ecdf3d8b3b643e73ec1a0a3d85ea32ee826b282","name":"transcript_b63.md","bytes":5284},{"sha256":"2af24854ea78eca0506d83ed6134446d5eb7e5df96ec8a6cf8bd222fd66fed9a","name":"killrun_env.c","bytes":15033},{"sha256":"03e16a232ee8def7523a1be87018bfd8d87eafa158659f86db07822c39bbc2ce","name":"env_s29_k4_21.jsonl","bytes":2489},{"sha256":"348dfd7c961acd7f6d3adc505862ee34473085a32c47cbb48c8d195916dba426","name":"env_s29_k22.jsonl","bytes":451},{"sha256":"6c16728cf1ea949d8a0a2e2d580b8d7e8069316c6422298a3c5bdd4ccfe37c99","name":"window_bounds.py","bytes":6960},{"sha256":"5e5054903bced60ef8bcb72235f540bf1c56587b3f9214ff6ad7b970c9a22c8d","name":"windows_max.json","bytes":7148},{"sha256":"76afcc02184900bc28bf4ab517953028bbac5e9e053566e07ac1e424ae643ce3","name":"windows_covers.json","bytes":9494},{"sha256":"8fc76300f0af3d25090f4e0776cc571c69e085435bff1096c2b1856a583e7d79","name":"windows_1122_only.json","bytes":2437},{"sha256":"a1d19d429a2ac6379fa4ab11e006d10413cb2096ea84b4f97833fb40a6e42ad2","name":"check_b63.py","bytes":6203},{"sha256":"7be7981edf894443b86f64d4962c65c82e9f77f32807323853cfb2562b6b910c","name":"check_b63.out","bytes":1269},{"sha256":"2f670f657d91cdb7023ff6c18caebb8d10fcffdc5320decc6249d0c3900a2be9","name":"check_b63.corrupt.cap.out","bytes":1378},{"sha256":"cd385d21983c1acdfceb77e7be0684b838fb1fa459d3837f1b395a72f846851d","name":"check_b63.corrupt.prune.out","bytes":1328}],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"2c79d4df873ee02b7a85427d96f303d81efadb230c63460289d95a93510e319b","next_step_sha256":"9ab472a7523458415395a031aabab6326e22977744c96cb5b5e040536f2a9bc8","research_authority":{"witness_status":null,"research_status":"recorded","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}