真号滥用这件事，最恶心的地方不在“真”。
而在“真得让你没法反驳”。
“投诉工单是真的，验真能过。”
“信访编号是真的，系统也能查到。”
“群众情绪也是真的，媒体报道也能引。”
可这些“真”未必属于你这个项目，未必对应你这次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（签章摘要）
热线中心的主任在电话里明确说过：不能给内容、不能给个人。
所以林远要的只是“桶”和“主题码”。桶对桶，码对码，足够做关联性判断。
三）关联性判定（Link-Check）——三条命中，一条红线
RFC-019给出一套非常工程化的判定逻辑：
强关联（PASS）：geo_bucket一致 + created_date在窗口内 + topic_code与项目阶段匹配（如交付期对应交付/质量类）
弱关联（WARN）：geo_bucket一致但topic_code不匹配，或时间窗稍偏离 → 允许提交，但触发抽查复测加密
不关联（FAIL）：geo_bucket不一致或无对应项目指纹 → 不允许用该编号申请exception
红线（ABUSE）：同一服务商在多项目出现“跨桶编号”或短期内大规模SOC编号集中出现 → 进入诱导异常线索池
“我们不判你是不是‘故意引导’。”林远说，“我们只判：你拿来的火警，和你这栋楼有没有关系。没关系，就别拿它开门。”
争议：居民投诉权与“借编号”的边界
RFC挂上去不到半天，争议就来了。
一个试点城市的城投负责人在群里直接发语音，带着明显的火气：“你们这样做，会不会让居民投诉更难？我们怕被说成压投诉。还有，区县网格桶也可能多个项目重叠，怎么保证不误伤？”
林远没有回避这个敏感点。他知道一旦被扣上“压投诉”的帽子，制度就会被舆论拖进泥里。
他在群里回得很短，但每句话都对准边界：
1）**我们不影响投诉。**投诉走/信访原系统，平台不接触投诉内容，也不决定受理与否。
2）我们只决定：这个编号能不能作为exception的证据。
这章没有结束，请点击下一页继续阅读！
喜欢重生2005：我在惠州买地皮请大家收藏：(m.zjsw.org)重生2005：我在惠州买地皮爪机书屋更新速度全网最快。