第464章 关联性校验与“借火警”（1 / 2）

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

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

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

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

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

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

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

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

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

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

存在性 ≠ 关联性

编号绑定项目

影响范围可复核

诱导异常可识别

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

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

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

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

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

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

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

project_id（平台项目ID）

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

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

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

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

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

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

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

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

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

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

created_date（到天）

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

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

所以林远要的只是“桶”和“主题码”。桶对桶，码对码，足够做关联性判断。

三）关联性判定（Lk-Check）——三条命中，一条红线

RFC-019给出一套非常工程化的判定逻辑：

强关联（PASS）：geo_bucket一致 + created_date在窗口内 + ic_de与项目阶段匹配（如交付期对应交付/质量类）

弱关联（WARN）：geo_bucket一致但ic_de不匹配，或时间窗稍偏离 → 允许提交，但触发抽查复测加密

不关联（FAIL）：geo_bucket不一致或无对应项目指纹 → 不允许用该编号申请exception

红线（ABUSE）：同一服务商在多项目出现“跨桶编号”或短期内大规模SOC编号集中出现 → 进入诱导异常线索池

“我们不判你是不是‘故意引导’。”林远说，“我们只判：你拿来的火警，和你这栋楼有没有关系。没关系，就别拿它开门。”

争议：居民投诉权与“借编号”的边界

RFC挂上去不到半天，争议就来了。

一个试点城市的城投负责人在群里直接发语音，带着明显的火气：“你们这样做，会不会让居民投诉更难？我们怕被说成压投诉。还有，区县网格桶也可能多个项目重叠，怎么保证不误伤？”

林远没有回避这个敏感点。他知道一旦被扣上“压投诉”的帽子，制度就会被舆论拖进泥里。

他在群里回得很短，但每句话都对准边界：

1）**我们不影响投诉。**投诉走/信访原系统，平台不接触投诉内容，也不决定受理与否。

2）我们只决定：这个编号能不能作为exception的证据。

3）**弱关联不一刀切。**弱关联可以提交，但会触发抽查复测加密，防止借火警。

4）**误伤救济：提供替代证据链。**如果桶重叠导致弱关联，你可以补充项目内部工单链路（整改工单、监理隐患单、材料断供通知）走SUP/SAF类申请，不必死磕SOC编号。