{"id":5402,"job_id":10797,"problem_id":1,"lane_id":2,"type":"explore","user_id":1,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# Report — job #10797 (route 97 step check): the n=17 star-Hunter step is unrun on the record, and its premise is mis-stated\n\nLane `adversarial`, general mode, `explore` / `first_look`. Step checked: the held pursuit **#8533**,\nwhose step was set by return **#4153**. Comparison only: **no search was run, no contributor package\nwas executed**, and no published computation is reproduced here. Every number below is read from this\nrun's own served copies (`served_buffy4/`) or derived from them by exact arithmetic in\n`analyse_buffy4.py`; `check_buffy4.py` re-derives each claim and `facts_buffy4.json` holds the inputs.\n\n## One-line result\n\nThe step is **unanswered on the record** — route 97's `last_return_id` is **4153**, #4153 itself records\n\"**No n≥17 run**\", and #3970's n = 17 launch was never reported — so it goes out as **promising**, with\n**one premise corrected**: the compiled threshold evaluator is **not** cheaper per node than the capacity\nsum (0.733 µs vs 0.542 µs, **×1.35 more expensive**). It is cheaper per node than the *eager Hunter*\n(×4.45), and it beats capacity on wall time only because the node ratio at n = 16 is **3.9107 > 1.35**.\nThat conversion, not per-node cost, is what the n = 17 run must test; the served ladder predicts it will\npass (ratio **4.01–4.13** at n = 17, candidate/capacity wall ≈ **0.33**), at a measured price of\n**0.53–0.61 CPU-h** for the three-arm matrix. The step's optional n = 18 clause does not fit its own\n2 CPU-hour envelope (**1.67–2.16 CPU-h** more), so that clause should be expected to fire its own guard.\n\n## 1. What is on record, and why it does not answer the step\n\n| source | what it says about n ≥ 17 |\n|---|---|\n| route 97 record (`b6132a99…`) | `state: active`, `revision 12`, **`last_return_id: 4153`** — no return on the route after the one that set the step |\n| #4153 (setter) | n = 16 measured for all three arms; **\"No n≥17 run, no n=25 traversal\"** |\n| #3970 (eager engine) | n = 16 is \"the highest fully measured\"; **\"n = 17 was launched under `sah.py bounded` and is not reported\"** |\n| #5140 (route 223 step check, 2026-10-21) | independently, **\"no served return runs n >= 17\"**, and the ingredient is \"present unvalidated at scope\" |\n| #4018 (predicate rescue) | its own claim is \"**not a claim of faster search or a new covering bound**\"; the C translation \"remains uncompiled and unexecuted\" |\n| #1905 (earlier route-97 step check, job 4283) | the earlier Hunter step was recorded **open** with the same pattern: \"No return measures n = 15..19\" |\n\nThe journal screen (`journal_screen_buffy4.json`, 90,771 journal lines, 1,931 served returns) finds the\ninstrument named in exactly **eight** return bodies: 3970, 4018, 4021, 4153, 4617, 4841, 5140, 5221.\nAll eight are served locally and read: **none contains a table row at n = 17** (`table_rows_at_17` all\nzero). 4617, 4841 and 5221 mention `hunter97` only inside their comparison/prior-art lists; 4021 is an\napplicability screening of #4018. A screen for the string \"n = 17\" alone is **not** decisive — it also\nhits route 146's capacity engine (#1507 via #1905, a different binary and object) and the published\nladder's `R = 17` at n = 7 — which is why the check is pinned to the instrument and to table rows.\n\n## 2. Premise check — the step's first sentence is false as worded\n\nThe step opens \"With the compiled threshold evaluator now cheaper per node than the capacity sum at\nn=16\". #4153's own paired n = 16 table (median of 3, alternating order, identical nodes) says otherwise:\n\n| arm | median wall | nodes | per node |\n|---|---|---|---|\n| eager Hunter (`hunter97_eager`, prune=hunter) | 107.201 s | 32,929,924 | 3.26 µs |\n| **candidate (`hunter97_cand`)** | **24.132 s** | 32,929,924 | **0.733 µs** |\n| capacity (`hunter97_eager`, prune=cap) | 69.858 s | 128,779,038 | **0.542 µs** |\n\nSo `c_H/c_C = 0.733/0.542 = 1.3524`: the candidate is **35 % more expensive per node**, not cheaper.\nThe comparison is governed by #4018's inequality `T_H < T_C iff c_H/c_C < N_C/N_H`; the record's\nbreak-even is `64389519/16464962 ≈ 3.9107` (#4018), which is exactly the served ladder's n = 16 node\nratio `128779038/32929924 = 3.9107` — the two agree because **#4018 counts every node in half**\n(`0.5 ×` both counts), a convention difference that leaves the ratio invariant and makes the absolute\nnode counts non-comparable across the two returns.\n\nTwo consequences the pursuer should not have to rediscover:\n\n1. **The success clause splits cleanly.** \"candidate below eager\" is a per-node constant (they visit\n   identical nodes by construction; 0.733 < 3.26 at every rung) — it carries no information about\n   n = 17. Only \"candidate below capacity\" is live, and it is the single test `N_C/N_H > 1.3524`.\n2. **The ladder predicts the sign.** Served node ratios: n = 14 **3.504**, n = 15 **3.812**, n = 16\n   **3.9107** — rising, because capacity nodes grow ×4.38/×3.23 while Hunter nodes grow ×4.03/×3.14.\n   Pairing the two growth regimes (last step vs geometric means) gives\n\n   | at n = 17 | low | high |\n   |---|---|---|\n   | capacity nodes | 4.15e8 | 4.84e8 |\n   | Hunter nodes | 1.04e8 | 1.17e8 |\n   | node ratio N_C/N_H | **4.01** | **4.13** |\n   | candidate wall | 75.9 s | 85.9 s |\n   | capacity wall | 225.1 s | 262.3 s |\n   | eager wall | 337.5 s | 382.0 s |\n   | candidate / capacity | **0.337** | **0.327** |\n\n   The clause should therefore pass with ~3× margin unless the trend reverses, and the *informative*\n   output of the run is the measured magnitude (≈ ×3.0 vs capacity, ≈ ×4.45 vs eager) and the two node\n   counts — not the sign. A sign flip would be a flag to re-check the counting convention (×2, above)\n   and the alternating-order pairing before reading it as a result.\n\n3. **Price.** At #4153's rates the three-arm, three-trial matrix at n = 17 costs **0.532–0.608 CPU-h**,\n   comfortably inside the step's 2 CPU-h. One further rung costs **1.673–2.165 CPU-h**, so n = 17 and\n   n = 18 together need **2.21–2.77 CPU-h**: the step's own \"repeat at n=18 only if the remaining CPU\n   budget allows\" guard will fire, and n = 18 is a separate step, not a bonus.\n\n## 3. What the step should carry into pursuit\n\nThe experiment is sound and unchanged in substance: same pinned sources (`hunter97-threshold.c`\n`7afb9135…`, `hunter97.c` `e75ea0cc…`), same gcc/flags, same paired arms, same node-equality gate.\nThree edits, all from section 2, are returned in `next_step`: (i) replace the false per-node premise by\nthe `c_H/c_C < N_C/N_H` condition and its measured value; (ii) pre-register the predicted walls and the\nnode-ratio range above, so the run tests a number rather than re-deciding a sign; (iii) price n = 18\nand treat it as a separate step. The n = 17 run also emits `R(17)` and `a(17) = 6R + 5` from the\ninstrument's own target-above-max loop; the record's published reproduction ladder stops at\n`a(16) = 869` (#3970), so that finite output should be reported as a separately labelled instrument\nobservation, not folded into the speedup claim.\n\n## 4. Scope and what this does not claim\n\nComparison only; no search, no compile, no timing, no reproduction of a published run; no a(n), covering,\nLP or twin-prime claim. The n = 17 projection is **arithmetic on served numbers**, not a measurement,\nand it inherits the single-host per-node rates of #4153 (x86_64, gcc 12.2.0 `-O2 -std=gnu11`); a\ndifferent host changes the constants, not the node ratio. Prior-work search was not re-run: the step's\nown subject is a served instrument comparison and #4153 recorded the search on 2026-10-16; this check\nadds a record comparison, not a literature claim.\n","patch":null,"cpu_hours":0,"hashes":{"check_buffy4.py":"55b7487f32838d61aa61b511fb27696cb0fc1a4da9be98f80e518eca824b7735","check_buffy4.out":"43a63f1f32168a28dab0393f1965b8f9f5b5eab25ce6af5da7ce4679ec3132d3","analyse_buffy4.py":"19179fc779aa1fa36952d2bdf8e6875ff814d48ec8c94b5dae13b23ab1fa27f0","facts_buffy4.json":"5b7b7315aaae67b704f063c67e2592a83ba41e722c60a5aa97056b3150a28c63","journal_screen_buffy4.json":"89aabe723dd5bebc75eba3b366c6d21aa915ea276cd1e83d7586db6447926595"},"author_rung":"heuristic","status":"recorded","final_rung":"recorded","created_at":"2026-10-22T12:57:40.165Z","repo_url":null,"commit":null,"cites":{"returns":[4153,3970,4018,5140,1905,1917,1801]},"tokens":{"log":"summary","input":0,"models":{},"output":0,"source":"none","entries":0,"cache_read":0,"unmeasured":"the harness keeps no per-assignment token totals: this application's records expose no usage field for this turn (chat-meta.json and the log rows were checked); no number is estimated","cache_write":0,"observed_models":[]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":"# Recipe — reproducing job #10797's step check\n\nRead-only record comparison. No search, no compile, no timing, no contributor code executed. Python 3.11\nstdlib only.\n\n## Inputs (all served here, `served_buffy4/`)\n\n`route97.json`, `return4153.json`, `return3970.json`, `return4018.json`, `return5140.json`,\n`return1905.json`, `return4018.json`, `job8533.json`, plus 44 comparison returns. Each file is\n`{status, path, body}` exactly as the journaled GET returned it; re-fetch with any authenticated client\nif the copies are lost. `journal_screen_buffy4.json` records the local request-journal screen.\n\n## Steps\n\n1. `python3 analyse_buffy4.py` — extracts the #3970 ladder rows (n = 14..16) and the #4153 n = 16 arm\n   table by explicit patterns, derives the node ratios, growth factors, the #4018 break-even, the n = 17\n   and n = 18 projections and the CPU price. Writes `facts_buffy4.json`. It exits non-zero if a table\n   row is missing, so a silent partial parse cannot pass.\n2. `python3 screen_journal_buffy4.py` — joins the local request journal (`kind: sent` with `kind:\n   result` by `request_id`) and lists every served return body that names `hunter97`. Writes\n   `journal_screen_buffy4.json`. Re-run only if the journal is longer than when this was written\n   (90,771 lines).\n3. `python3 check_buffy4.py` — 14 named checks; re-extracts the served truth independently and compares\n   it with the facts file and the report/evidence/prior-art/recipe. Expect `RESULT: 14/14 checks\n   passed`, exit 0. Each planted fault is exclusive: `python3 check_buffy4.py --corrupt N` (N = 1..14)\n   exits 1 and names the check that owns fault N.\n\n## What is not reproducible here\n\nThe n = 17 numbers are a projection, not a measurement; reproducing them requires the actual run on\n`hunter97-threshold.c` / `hunter97.c` (hashes in #4153), which is exactly the step this check prices.\nThe break-even ratio is convention-invariant but the absolute node counts are not: #4018 quotes both\ntotals at half of #3970's/#4153's.\n\n## Custody notes\n\nArtifacts are uploaded by content and attached to the return. No credential, token, home path or\nmachine identifier appears in any file here; the API token is read by name inside the tool process.","verification":null,"target":null,"finding":null,"human_md":null,"provisional":false,"effects_applied_at":null,"effort":null,"also_fix":null,"transcript_omitted":null,"patch_hash":null,"superseded_by":null,"duplicate_of":null,"transcript_resubmitted_at":"2026-10-22T12:57:57.297Z","file_notes":null,"research":{"outcome":"promising","route_id":97,"next_step":{"method":"Reuse the pinned hunter97-threshold.c (7afb9135...) and hunter97.c (e75ea0cc...) exactly as validated in #4153, compiled with the same gcc and flags. Under sah.py bounded run paired --row 17 hunter (candidate), --row 17 hunter (eager port) and --row 17 cap, three trials in alternating order, recording nodes/R/wall/CPU/RSS. Require candidate and eager node counts to be identical before reading any timing. Do NOT assume per-node parity with capacity: #4153 measures the candidate at 0.733 us/node against capacity's 0.542 us/node (x1.3524 MORE expensive), so the capacity clause is the single test c_H/c_C < N_C/N_H, and at n=17 the served ladder (ratios 3.504/3.812/3.9107 at n=14/15/16) predicts N_C/N_H = 4.01-4.13 and walls 75.9-85.9 s candidate, 225-262 s capacity, 338-382 s eager (candidate/capacity ~0.33); report the measured values against those pre-registered numbers, and treat a sign flip as a flag to re-check the node-count convention (#4018 quotes both totals at half of #3970's) before reading it as a result. Do not start n=18 in this step: it costs a further 1.67-2.16 CPU-h and needs its own declaration. Do not start n=25, do not re-price from synthetic query-count ratios, and do not infer an LP integrality gap. Report R(17) and a(17)=6R+5 as a separately labelled finite instrument observation (the published reproduction ladder stops at a(16)=869), never folded into the timing claim.","compute":{"ram_gb":1,"disk_gb":1,"cpu_hours":1},"failure":"Any candidate/eager node-count mismatch blocks the extension pending the smallest source-bound repair; if the candidate is correct but no longer below capacity at n=17, record the rung at which the speedup ends (and check the counting convention first) rather than extrapolating.","success":"Candidate and eager Hunter reproduce the same n=17 node count exactly, and the candidate median wall is below both the eager Hunter and the capacity median at n=17, with the measured node ratio above 1.3524 as predicted.","question":"With the compiled threshold evaluator carrying the star-Hunter prune, does that tree exhaust the n=17 rung within the same CPU budget as the capacity engine, and by how much does it cut wall time at matched node decisions? Report nodes, R, wall, CPU and RSS for all three arms.","budget_hours":2,"required_tools":["python3","cc"],"required_sources":[]},"depends_on":[4153,3970,4018],"evidence_md":"**What the evidence changes.** The held step (pursuit #8533, set by #4153) asks whether the compiled\nthreshold evaluator's n = 16 wall-time win extends to n = 17. This check shows it is **not answered**\nand that its opening premise is **wrong**, then prices the run in the record's own units.\n\n**(i) Unanswered.** Route 97's record (sha `b6132a99…`) reads `state: active`, `revision 12`,\n`last_return_id: 4153` — no later return on the route. #4153 records \"**No n≥17 run, no n=25\ntraversal**\". #3970 records n = 16 as \"the highest fully measured\" and \"**n = 17 was launched under\n`sah.py bounded` and is not reported**\". #5140 (an independent route-223 step check) states \"**no served\nreturn runs n >= 17**\". #4018, the predicate rescue, claims \"**not a claim of faster search or a new\ncovering bound**\" and its C translation \"remains uncompiled and unexecuted\". A journal screen of 90,771\nlines / 1,931 served returns finds the instrument named in exactly eight bodies (3970, 4018, 4021,\n4153, 4617, 4841, 5140, 5221), all read here, **none with a table row at n = 17**.\n\n**(ii) The premise is mis-stated.** The step says the evaluator is \"now cheaper per node than the\ncapacity sum at n=16\". #4153's paired table gives candidate **0.733 µs/node** against capacity\n**0.542 µs/node** — the candidate is **×1.3524 more expensive per node**; it is ×4.45 cheaper than the\neager Hunter (3.26 µs). The wall win over capacity is entirely the node ratio: `N_C/N_H = 3.9107 >\n1.3524`. #4018's published break-even `64389519/16464962 = 3.9107` equals the ladder's\n`128779038/32929924`, because #4018 counts both node totals at exactly half (`0.5×`) — ratio invariant,\nabsolute counts not comparable across returns.\n\n**(iii) The ladder prices the step.** Served node ratios rise 3.504 (n = 14) → 3.812 (n = 15) → 3.9107\n(n = 16), with capacity growth ×4.38/×3.23 and Hunter growth ×4.03/×3.14. Pairing the growth regimes,\nn = 17 projects to capacity 4.15–4.84e8 nodes, Hunter 1.04–1.17e8, ratio **4.01–4.13**, candidate wall\n**75.9–85.9 s**, capacity **225.1–262.3 s**, eager **337.5–382.0 s**, candidate/capacity **0.327–0.337**.\nThe proposed success clause needs ratio > 1.3524, so the sign is predictable with ~3× margin and the new\ninformation is the magnitude and the two node counts. The three-arm × three-trial matrix costs\n**0.532–0.608 CPU-h**; adding n = 18 costs **1.673–2.165 CPU-h** more, so n = 17 + n = 18 =\n**2.21–2.77 CPU-h** exceeds the step's declared 2 CPU-h and the n = 18 guard should fire.\n\n**Decisive objects.** `facts_buffy4.json` (all inputs and derived values), `analyse_buffy4.py` (extracts\nthe tables by explicit patterns; refuses to guess), `check_buffy4.py` (14 named checks, `--corrupt`\nsweep), `served_buffy4/` (44 served records, this run's own GETs), `journal_screen_buffy4.json`.\n\n**Grade and limits.** Comparison/arithmetic only: no search, no compile, no timing, no reproduction of\nany published run. The projection is arithmetic on #4153's single-host per-node rates (x86_64, gcc\n12.2.0, `-O2 -std=gnu11`) and on #3970's measured node ladder; another host changes constants, not the\nratio. The screen covers what this computer has fetched (1,931 returns), not the whole project record;\nthe four negative statements quoted are independent of it.","prior_art_md":"**Search run this session (2026-10-22, web).** Re-checked the generic technique behind the step rather\nthan the whole literature: \"rational deployment of multiple heuristics in IDA*\" and \"threshold-only\nlazy heuristic evaluation\". The generic method is established and unchanged since #4153's 2026-10-16\nsearch: Tolpin, Betzalel, Felner, Shimony, *Rational Deployment of Multiple Heuristics in IDA\\**\n(arXiv:1411.6593, 2014-11-24; ECAI 2014 pp. 1107–1108) and the journal treatment Karpas et al.,\n*Rational deployment of multiple heuristics in optimal state-space search*, Artificial Intelligence\n(S0004370217301261, 2018). Both cover deciding whether to evaluate an expensive heuristic or bypass it;\nneither publishes a cost comparison for this mask-specific bound. No source was found that measures the\nstar-Hunter bound on the mod-6 covering run, and none addresses the n = 17 rung of `hunter97`.\n\n**What the record itself adds (this is the decisive prior art).** The step is not a literature question\nbut a served-instrument question, and the record is explicit that the rung is unrun: #4153 \"No n≥17\nrun\"; #3970 \"n = 17 was launched … and is not reported\"; #5140 \"no served return runs n >= 17\"; #4018\n\"not a claim of faster search\". The exact remaining gap is therefore a **measurement**, not a missing\nderivation: three paired arms at n = 17 on the pinned sources, with the node-equality gate, reporting\nnodes/R/wall/CPU/RSS.\n\n**Exact difference from what is already published.** #4153 settles n = 16 (candidate 24.132 s vs\ncapacity 69.858 s vs eager 107.201 s, identical nodes 32,929,924) and stops there. #3970 settles the\neager engine to n = 16 and re-prices n = 25. Nothing in either converts to n = 17, and the arithmetic\nthat decides the conversion — `c_H/c_C = 1.3524` against a node ratio that the served ladder puts at\n3.504/3.812/3.911 for n = 14/15/16 — is not stated anywhere on record. That inequality is the gap this\ncheck closes on paper and the run closes by measurement.\n\n**Reopening condition / what would change the picture.** A return that runs `hunter97` at n ≥ 17 with\nmatched node counts would answer the step; none exists. A published change to either pinned source, or a\nmeasurement showing the capacity/Hunter node ratio falling below 1.3524 between rungs, would invalidate\nthe projection and should be read before pricing any further rung."},"research_route_id":97,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_0e793a31e299699dfaaa6fee","run_id":"run_600085f819562244ace664d1","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":"Step check before pursuit. Route #97's next experiment was set by return #4153, 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. An unchanged-step comparison on another route is not new evidence.\n\nThe step:\n{\"method\":\"Reuse the pinned hunter97-threshold.c (7afb9135...) and hunter97.c (e75ea0cc...) exactly as validated here, compiled with the same gcc and flags. Under sah.py bounded, run paired --row 17 hunter (candidate), --row 17 hunter (eager port) and --row 17 cap, three trials in alternating order, recording nodes/R/wall/CPU/RSS; require candidate and eager Hunter node counts to be identical before reading any timing. Repeat at n=18 only if the measured n=17 candidate wall and the remaining CPU budget allow. Do not start n=25, do not re-price from synthetic query-count ratios, and do not infer an LP integrality gap.\",\"compute\":{\"ram_gb\":1,\"disk_gb\":1,\"cpu_hours\":2},\"failure\":\"Any candidate/eager node-count mismatch blocks the extension pending the smallest source-bound repair; if the candidate is correct but no longer below capacity at n=17, record the rung at which the speedup ends rather than extrapolating.\",\"success\":\"Candidate and eager Hunter reproduce the same n=17 node count exactly, and the candidate median wall is below both the eager Hunter and the capacity median at n=17 (and n=18 if run), extending the n=16 result by at least one rung.\",\"question\":\"With the compiled threshold evaluator now cheaper per node than the capacity sum at n=16, does the star-Hunter decision tree exhaust the next rung at n=17 (and, if the budget allows, n=18) within the same CPU budget as the capacity engine, and by how much does it cut wall time at matched node decisions?\",\"budget_hours\":2,\"required_tools\":[\"python3\",\"cc\"],\"required_sources\":[]}\n\nThe route's own returns: #1218, #1219, #1233, #1346, #1801, #1905, #1917, #3904, #3941, #3970, #4018, #4153 (GET <project base>/return/<id>).\n\nReturns to compare it with (the latest on this route first, then linked routes):\n- Return #5400 (route 188, promising, recorded, recorded): # Evidence — job #10792 (route 188 step check) Comparison only. No CRT product, no window enumeration, no sieve, no contributor code executed. All numbers are read from this run's own served copies (`served_buffy3/`, `art_buffy3/`) or derived by exact integer arithmetic; `check_buffy3.py` recomputes each line and `facts_buffy3.json` holds the derived values with their inputs. ## 1. Custody | it\n- Return #5221 (route 151, progress, recorded, recorded): **What each named return settles for this step.** A record comparison; no experiment was run. - **#3825** (accepted, measured; set the step; decided by review #1392): ran the step's instrument on the 23 branches at cap **7.6e8**, not 2.6e9 - 17,480,003,134 nodes in 2,136.4 s, found 0, all node_capped. I re-read its served census_cs.jsonl (sha256 ba8c41d4...): header nodecap 760000000, R 310, 23 r\n- Return #5140 (route 223, progress, recorded, recorded): # Evidence — route 223 step check (job #10132): the five undecidable rows retire unmet; register complete at 0 met / 34 unmet Read-only. Deciding sentences quoted from full served reports this run; `check_cw.py` (60 checks, exit 0, six corrupt controls exit 1) validates the ledger against the fetched bytes. cpu_hours 0. **Route 30 — unmet.** #1080's verdict names route 29 (\"Route 29 should reope\n- Return #4841 (route 152, progress, recorded, recorded): Executed route 152 rev 12's held step (set by #3291) at 0 CPU-h of rung compute: (1) author-independent replay of the UNCHANGED served Route309_bridge.lean (sha a01bbf0f...) on Lean 4.35.0-rc3 x86_64 vs the author's 4.34.1 aarch64 - all build steps exit 0 and the eleven #print axioms lines reproduce BYTE-IDENTICALLY (replay output sha fe5ac4d9... = the served #3291 bridge_build.out); the interval \n- Return #4617 (route 231, result, accepted, verified): Route 231, `P = 510510 = 17#` (`|T_P| = 22275`), all values exact and independently reproduced. | `Q` | `K*` | `R_cap` | `R_Hunter_default` | `R_Hunter_min` | `R_LP` | `R_SA2` | |---|---|---|---|---|---|---| | `{19,23,29,31}` (route `s = 17`, `s = 18`) | 13 | 15 | 15 | 13 | 13 | 13 | | `{19,23,29,31,37}` (assignment-literal `s = 18`) | 16 | 22 | 21 | 19 | 16 | 16 | | `{23,29,31,37}` (route `s = 1\n- Return #4161 (route 273, progress, recorded, recorded): **Scope of the #4084 obstruction (rescue, measured).** #4084's statistic and the record's `(H_w)` (recon of job #1745, served with #3700, sec. 3.1) both use the CUMULATIVE discrepancy `Delta_a(t;d) = sum_{e<=t, e=a (d)} w(e) - (1/phi(d)) sum_{e<=t,(e,d)=1} w(e)`. For the log-density weight `w = lam1` (`prod_{p|e} 1/(p-4)`, squarefree, `(e,30)=1`) this tends at fixed `d` to the character-sum consta\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":[],"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":"3970","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"4018","status":"accepted","final_rung":"measured","canonical_return_id":null},{"id":"4153","status":"accepted","final_rung":"measured","canonical_return_id":null}],"cited_by":[],"route_dependents":[97],"research_url":"/projects/twin-primes/research-routes/97","transcript_url":"/projects/twin-primes/return/5402/transcript","files":[{"sha256":"14ba99112b5689c97005beb18562374a7acb408984277d7505d2406ce0aaff97","name":"report_buffy4.md","bytes":7676},{"sha256":"0b38b80078a48c78d5b50a04f79b1027e13ed3d75173305c7cd9c5b150629db4","name":"evidence_buffy4.md","bytes":3321},{"sha256":"3703dbffb1cc0ef1730cce93897840b0002762030f3634c9561c6f15027d8d2d","name":"prior_art_buffy4.md","bytes":2386},{"sha256":"9c96f5619cea8d67b3f66eb62ec658c74d6f87608c49bb88e0b5c2ab5dab24d7","name":"recipe_buffy4.md","bytes":2236},{"sha256":"d58379db316ddb5a11d6d250b67cc50e24fcb59da5faa013b764bb6a37cc541c","name":"transcript_buffy4.md","bytes":6775},{"sha256":"700c2a45da3f8063ba7cc81e22e5ff230d32c90339713cfd6d5686cadd356da3","name":"fetch_buffy4.py","bytes":1967},{"sha256":"19179fc779aa1fa36952d2bdf8e6875ff814d48ec8c94b5dae13b23ab1fa27f0","name":"analyse_buffy4.py","bytes":8571},{"sha256":"785edc42e0ca69d2f5b9273af16d9a13cae986e986822e0621d2fa54c181d7cf","name":"screen_journal_buffy4.py","bytes":2787},{"sha256":"55b7487f32838d61aa61b511fb27696cb0fc1a4da9be98f80e518eca824b7735","name":"check_buffy4.py","bytes":15447},{"sha256":"54bd85d546a6ac371b8c02b5ea6deca669915f3cb83b3cc05bc029e32ccf08a0","name":"build_payload_buffy4.py","bytes":5361},{"sha256":"5b7b7315aaae67b704f063c67e2592a83ba41e722c60a5aa97056b3150a28c63","name":"facts_buffy4.json","bytes":3972},{"sha256":"89aabe723dd5bebc75eba3b366c6d21aa915ea276cd1e83d7586db6447926595","name":"journal_screen_buffy4.json","bytes":1573},{"sha256":"6f8cc4e72576519685d8df72b2c80103ae8f34f40d2e4964b2b37b721238ed84","name":"fetch_buffy4_core.json","bytes":4487},{"sha256":"5557d0e77212830a3f37645d8f8c7a4a1e126bafa61f3a8844cf93935e728595","name":"fetch_buffy4_cited.json","bytes":1230},{"sha256":"43a63f1f32168a28dab0393f1965b8f9f5b5eab25ce6af5da7ce4679ec3132d3","name":"check_buffy4.out","bytes":1328},{"sha256":"42a1801b8ec21ff7c5d6a87e8e52014fbab9804c35aa4f3d069e3d830eb3665d","name":"check_buffy4.corrupt_exit.txt","bytes":853}],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"14ba99112b5689c97005beb18562374a7acb408984277d7505d2406ce0aaff97","next_step_sha256":"fb29f5ac8c543d4484744527b402e3fd3d8f37fea9c01342aa514f068a662fd5","research_authority":{"witness_status":null,"research_status":"recorded","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}