标准与方法

如何理解与核查 Chronicle

AI4Math 大事记不是新闻流或论文数据库。它把多个公开来源组织成稳定的历史事件记录,并把历史重要性、证据强度、验证状态与形式化保障分开表达。

Chronicle 可信度模型四个维度

01 · 重要性

历史上有多重要?

H1–H3 描述事件在 AI4Math 历史或重要技术路线中的长期位置。

02 · 证据

公开证据有多成熟?

来源层级与 E0–E4 记录 claim、研究记录、可检查工件与独立检查的发展程度。

03 · 验证状态

核心事件描述被佐证到什么程度?

Verification 描述 Chronicle 当前对“发生了什么”的事件级证据状态,而不是裁决最终数学真伪。

04 · 形式保障

形式化工件被检查到什么程度?

Formal Assurance 区分无工件、工件可用、机器检查与独立 replay。

这四个维度相互独立,不会被压缩成一个“可信度总分”。来源层级用于解释证据从哪里来,也不替代重要性、验证状态或数学正确性判断。

1. 什么会进入 Chronicle?

采用“宽发现、严收录”:候选可以来自论文、正式证明工件、实验室公告、GitHub、学术讨论或社区信号,但只有具有历史或领域意义的 canonical event 才进入公开 Chronicle。

原则上收录 discovery、proof、formalization、competition、system、benchmark、dataset、infrastructure、field_building 与具有历史意义的 controversy。field_building 用于记录 AI4Math 共同体的形成、制度化、学术规范与治理里程碑,例如具有持续性的专门期刊 / 会议,或真正改变研究规范的共同体声明;普通联署、一次性 workshop、普通 special issue 与短暂社区活动默认不收录。普通模型发布、普通论文流、微小 benchmark SOTA、纯 prompt engineering、普通形式化更新以及只有营销材料而缺乏技术内容的发布同样默认不收录。

对于纯领域建构事件,如果数学新颖性、AI 角色或数学接口本身不适用,canonical record 使用 not_applicable,而不是误填 tooling_only、unclear 或 informal。not_applicable 只允许用于包含 field_building 的事件。

2. 如何理解历史重要性?

重要性(Significance)≠ 验证状态(Verification)。一个 H1 事件仍可能处于 under_verification;历史重要并不等于底层数学 claim 已被最终确认。
H1Historical Milestone:AI4Math 历史中的长期转折点,例如重大新数学结果、新证明、新反例、重大形式化或可重复的研究级突破;最终 designation 需要人工确认。
H2Field Milestone:对重要子领域、技术路线或 AI4Math 学术共同体建构具有明显意义,例如数学专项系统、benchmark、dataset、proof search、formalization infrastructure、重要竞赛结果,以及持续性 venue 或规范建构里程碑。
H3Context Event:主要用于建立历史上下文,而不是作为实质性 AI4Math milestone。

3. Chronicle 如何组织证据?

Chronicle 不把可信度压缩成一个分数,而是分别记录来源、证据成熟度、当前验证状态和形式化工件保障。

来源层级(S1–S5)

S1论文、期刊/会议、正式证明工件、官方研究仓库、数据集工件等 primary research source。
S2实验室、大学、研究者、学术 venue 或相关机构的官方公告与正式记录。
S3独立学术佐证或分析,包括复现、外部评分、同行评议或 artifact replay。
S4高质量科技或科学媒体。
S5HN、Reddit、X、论坛等社区发现信号;可用于发现候选,但不能单独支撑重大科研事实或领域建构里程碑。

证据等级(E0–E4)

E0Unsubstantiated:尚缺乏足够公开依据。
E1Primary Claim:已有原发布方公开 claim。
E2Research Record:已有公开研究记录。
E3Inspectable Artifact:存在可检查的代码、证明、数据或其他 artifact。
E4Independent Check:已有独立检查或佐证。

验证状态与形式化保障

Verification Status 描述 Chronicle 对“发生了什么”的当前证据判断,例如 claimed、paper_released、under_verification、partially_verified、independently_verified、disputed、corrected 或 retracted。Formal Assurance 则只描述形式化 artifact 的保障程度:none、artifact_available、machine_checked、independently_replayed。对于 field_building,验证的是声明、venue、治理或制度事件是否如记录所述发生,而不是 Chronicle 对其规范立场或学术声望表示赞同。

machine_checked ≠ independently_verified ≠ mathematical correctness。机器检查过形式化工件,不等于 Chronicle 已独立佐证整个事件,也不等于项目替学术共同体裁决了数学真伪。

4. 如何处理不确定性与争议?

Chronicle 核验的是事件及其公开证据:原发布方声称了什么、发布了哪些 artifact,以及可靠独立来源在多大程度上佐证核心事件描述。项目不把 verification 当作对数学真伪、历史优先权或归属争议的最终裁决。

`under_verification` 表示重要部分仍处于外部核查中;`partially_verified` 表示已有重要独立佐证但仍有实质问题未决;`independently_verified` 表示可靠独立来源已实质性佐证核心事件描述;`disputed`、`corrected` 与 `retracted` 则明确保留争议、更正或撤回状态。

5. 如果记录有误或遗漏,如何处理?

Chronicle 使用稳定 Event ID,并通过 verification history 与 corrections 保留可审计修订轨迹。事实变化时应更新 canonical YAML,而不是静默改写历史。纠错、来源线索、遗漏事件提议与网站问题都通过公开、可追踪的 GitHub 工作流进入审核。

本页负责解释为什么 Chronicle 可被修正,以及修订如何进入可信度模型;项目介绍、使用方式与具体提交入口集中在“关于”页面,避免标准说明页与行动入口重复。

前往关于 →