第462章 消防门的三道锁（1/2）

例外编号本来是“消防门”——火灾时砸开玻璃的那种。

它存在的意义不是让人走得更快，而是让系统在极端情况下不崩。林远当初同意设exception_id，就是因为现实里确实会有“不能等”的项目：大面积停工、重大安全隐患、群体性维权风险、关键供应链断点……这些事情一旦爆开，排期再公平也没有意义。

但当匿名入口里出现那条广告——

“例外编号申请指导，帮你更容易拿到紧急编号。”

林远知道，消防门开始被当成“VIP通道”卖了。

他把白板擦干净，写下三个词，每个词都像一把锁：

证据化

可追责

可统计

“消防门要装锁。”林远说，“锁住的是滥用，不是救命。”

联席会：把“紧急”从话术拉回事件

省信息处当天就组织了一个小范围联席会，参会阵容比平时更克制：信息处、法规处、审计联络、银行风控、数科安全、两个试点城市代表。协会与咨询公司被“礼貌地”放在旁听席，能听但不主导。

副处长联络员开场只说一句：“最近出现‘例外编号申请指导’的商业宣传。我们今天要把exception_id的申请、审批、使用写成规则，避免变相许可。”

旁听席的咨询总监想插一句，被法规处的人一个眼神压回去。

林远把自己的方案投到屏幕上，标题写得像消防演练：

《例外编号管理规则（EXC-01）—试行》

第一页就是三道锁，后面每道锁都有可执行条款。

第一锁：申请原因证据化（紧急必须是事件）

“紧急不是一句‘领导盯’，紧急是一件可复核的事。”林远开门见山。

EXC-01把“紧急原因”定义成四类事件，并且每类都必须有证据编号：

1）安全事件（SAF）

触发条件：存在人身/结构/消防等重大风险

必须提交：监理隐患单号 + 现场照片/视频元数据摘要（哈希）+ 整改时限

必须绑定：复测计划run_id（后续一定复测）

2）群体性风险（SOC）

触发条件：维权集中、舆情扩散、交付节点爆点

必须提交：投诉工单号/信访编号（脱敏）+ 风险评估模板（标准化）

必须绑定：整改工单链路ID

3）供应链断点（SUP）

触发条件：关键材料/设备断供导致全链停摆

必须提交：供方断供通知编号（脱敏）+ 影响范围清单

必须绑定：临时替代方案变更单编号

4）政策硬节点（POL）

触发条件：明确的法定期限/专项检查窗口

必须提交：通知文件编号 + 截止时间

必须绑定：审核回执编号

“你注意。”林远指着屏幕，“没有一条是‘因为我们着急’。全部是‘因为发生了什么’。发生必须有编号，编号必须能被抽查。”

城投代表忍不住问：“那领导盯的项目呢？领导一句话，我们怎么办？”

林远回答得很现实：“领导盯不是紧急原因，领导盯最多是风险放大器。你可以在SOC类里体现‘风险放大’，但你必须给出投诉编号或舆情证据。否则就是后门。”

审计联络当场点头：“紧急必须可抽查，不能靠口头。”

第二锁：例外编号可追责（谁开门谁负责）

EXC-01第二部分更硬：例外编号不是随便发，必须有人承担责任。

exception_id由省信息处签发，但必须双人审批：

一名业务审批（信息处）

一名旁听确认（审计旁听或银行旁听）——只确认材料齐全与编号存在，不判断内容

每个exception_id必须写明：

签发人（角色）

原因类别

有效期（默认48小时，最长不超过7天）

插队次数上限（默认1次）

本章未完，点击下一页继续阅读。