真号滥用这件事，最恶心的地方不在“真”。

而在“真得让你没法反驳”。

“投诉工单是真的，验真能过。”

“信访编号是真的，系统也能查到。”

“群众情绪也是真的，媒体报道也能引。”

可这些“真”未必属于你这个项目，未必对应你这次exception申请，甚至——未必是自然发生的。

林远把那条“引导投诉拿编号”的线索看了两遍，没往下翻更多。他不需要看更多话术，因为他太清楚这条路的结构：当消防门需要编号时，编号就会被当成钥匙；当编号能被验真时，钥匙就会被“借用”；当借用还能奏效时，就会有人把“借火警”当成一门生意。

他对陈毅说：“验真只证明存在。下一步必须证明——这火是不是你这栋楼着的。”

陈毅点头：“也就是关联性校验。”

“对。”林远把白板擦干净，写下四个词，像把一条新规则钉上去：

存在性 ≠ 关联性

编号绑定项目

影响范围可复核

诱导异常可识别

RFC-019：把“关联性”写成可落地的接口

第二天上午，RFC提案按流程挂到公共接口里，编号很短：RFC-019｜事件编号关联性校验。

林远坚持把它做成“填空题”，而不是“道德题”。

RFC-019的核心不是讨论“引导投诉对不对”，而是讨论：系统如何判断一个事件编号与某个项目的关系是否可信。

陈毅把草案拆成三段，每段都有明确输出：

一）项目指纹（Project Fingerprint）——先把项目定义清楚

每个纳入平台的项目都必须有一份“项目指纹”，不含个人隐私，只含可核验的结构信息：

project_id（平台项目ID）

geo_bucket（地理网格桶：区县级或更粗，哈希化）

contractor_hash / supervisor_hash（承建/监理主体哈希）

phase（施工/交付/维保阶段）

onsite_contact_role（仅角色，不含号码/姓名）

timeline_window（当前关键节点时间窗）

“项目指纹不是身份证，是坐标。”林远说，“它让系统知道：你是谁、你在哪、你现在处于什么阶段。”

二）事件指纹（Event Attestation）——不看内容，只看归属

/信访等独立系统的验真返回，在原来“存在性”基础上，再多给两项极粗粒度的归属信息（仍然脱敏）：

geo_bucket（同样区县级网格桶，哈希化）

topic_code（主题码：质量/安全/交付/噪音/停水电等）

created_date（到天）

exist（true/false）+ attestation_hash（签章摘要）

热线中心的主任在电话里明确说过：不能给内容、不能给个人。