下一个改进方向的建议：严格产出完整性 —— 可验证性准入 + 结果绑定 + 提交硬校验 #21

背景

先说，DeepGraph 整体设计—— 闭环 discovery、SQL signal_harvester 零成本跑信号、meta_learner 从历史自我调整、venue routing 这套都很扎实，而且 evidence_gate、claim_grounding、result_interpreter、require_submission_ready() 这些 grounding / gate 模块该有的都有。框架是有潜力的。

读了代码、也看了几篇产出之后，有一个观察想和你们商量。

观察

这些门目前像是 "建好了但没真正实质闭环" —— 产出里偶尔出现合成数字、未解析引用（? / Table ??）、自相矛盾的正文，而这些本应被 require_submission_ready() 拦住（README 里写的是 "synthetic data never reaches a manuscript bundle"）。

下面三条是我的建议（供讨论，不是结论），每条把收益和代价都列出来，方便你们权衡。

建议 1 ｜ 选题层加"可验证性准入"

观察: paper_idea_agent / idea_route 目前似乎不区分"结果能否机器判定"。

提议: 是否可以考虑 —— 每个 idea 必须自带一个可执行 verifier（solver / exact-match / 可复算 ground-truth），evidence_gate 在立项处直接拒掉没有 verifier 的题？

• 收益: 从源头消灭幻觉结果。生成层有了硬锚就编不动；每篇产出自带可复现验证，系统可信度上一个台阶，reviewer 和用户的信任才建立得起来。
• 代价: 选题空间收窄，一部分宏大但暂时无法验证的方向得先放。
• 权衡: 短期少做题，长期每篇都立得住。这条最深，也最需要你们自己拍板，所以放第一个一起讨论。

建议 2 ｜ 结果强绑定稿件，写作层从"作者"变"播报员"

观察: real_experiment_runner / result_interpreter 都在，但稿件里出现过账本里不存在的数字（例如标题数字全文找不到、abstract 与表格对不上）。

提议: manuscript_generation 是否只允许引用 run artifact 的字段、任何数字都可回溯账本，并让 result_interpreter 的 verdict（refuted / supported）强制约束 abstract / conclusion 的措辞？

• 收益: 数字永远自洽可回溯，"标题数字全文找不到"这类硬伤彻底消失；稿件可信度 = 实验可信度，没有写作层的额外失真；出问题也好定位。
• 代价: manuscript_generation 要从"写数"重构成"取数"，前期有中等改动量。
• 权衡: 一次性改造，换长期免去无穷的事后核对。

建议 3 ｜ 把 require_submission_ready() 变成真 block，补四个确定性检查

最便宜、当周可上，建议先做。

观察: format_linter 具名检查偏排版（字体、间距、引用密度），没覆盖真正出事的点。

提议: 加四个硬检查，任一命中即 fail、禁止出稿：

• 收益: 最便宜，当周可上；自动拦住绝大多数"一眼假"产出；require_submission_ready() 名副其实；CI 自动化，不靠人工 review。
• 代价: 几乎没有，纯确定性检查，误杀率极低。
• 权衡: 近乎全是收益 —— 所以哪怕 1、2 还要讨论，这条可以先合。

建议落地顺序

3 先做（减少明确的浪费）→ 2 → 1（根治）。

当然你们更懂自己的 codebase，顺序和取舍你们定。

Checklist

• 建议 1（可验证性准入）方向是否认可，一起讨论选题空间的取舍
• 建议 2（结果绑定）改造范围，确认 manuscript_generation 重构边界
• 建议 3 的四个确定性检查 —— 是否接受 PR
• 确认 require_submission_ready() 行为：检测到合成 / 未解析 / 串台内容时硬 fail，而非告警