入口故障公开化以后，最直观的变化是——没人再敢明目张胆说“我们能出M1”。
但门票从来不会消失，它只会换成更“技术”的词。
数科副总那句“统一由我们提供SDK”在群里发出来时，很多城市第一反应居然是支持：“统一好啊，省得各自折腾。”
这就是俘获最危险的地方：它常常披着“标准化”和“省事”的外衣。
林远没急着反对。他知道如果他直接说“不行”，就会被贴上“阻碍效率”的标签。
他要做的是把问题翻译成所有人都能理解的一句话：
“统一SDK没问题，但标准不能私有化。否则你就把入口变成收费站：谁符合你SDK版本，谁能更容易产出M1；谁不符合，就被卡在兼容性上。兼容性就是新门票。”
他在白板上写下四个词，像把“入口”从工具拉回公共设施：
开放规范
可替换实现
兼容性可审计
解释权不可私有
1）入口不再是“产品”，而是“规范”
省信息处牵头成立了一个小小的“入口规范编制组”，名字很行政：《采集入口开放规范（ING-STD）编制组》。成员不多：信息处两人、数科安全一人、两家试点城市的技术代表、银行IT旁听、审计旁听。协会与咨询公司仍然只能旁听。
林远把规范分成三层，开场就把边界钉死：
规范（Spec）是公共的：任何人都能实现
实现（Impl）可以多家：数科可以做，城市也可以做，第三方也可以做
验收（Conformance Test）是公开的：通过测试才算M1入口
“我们不是要反对数科做SDK。”林远说，“我们是要保证：数科做的SDK只是‘其中一种实现’，不是‘唯一入口’。”
数科副总立刻皱眉：“多家实现会带来碎片化，运维成本会爆炸。”
林远点头：“所以我们需要兼容性测试套件，用套件来控碎片，而不是用垄断来控碎片。”
2）ING-STD-01：规范写到“字节级”的那种公开
陈毅把规范草案投出来，编号：ING-STD-01（草案）。内容不像文案，更像接口文档，细到让人没法耍滑。
规范包含五块：
A. 挑战码与签名流程
nonce获取接口（输入project_id、ticket_id；输出nonce、有效期、nonce_hash）
发生签名摘要结构（字段顺序、哈希算法、盐值管理方式）
签名请求格式（只传摘要，不传原图）
签名回包（attestation_hash、签名链版本号）
B. 设备与位置的隐私边界
设备指纹桶允许字段：OS大类、机型段、采集入口版本号（禁止IMEI/手机号/精确GPS）
geo_bucket精度固定到区县级，不允许更细
时间戳允许漂移范围
C. 离线发生包格式
离线摘要结构
绑定incident_id的流程
超时降级规则
D. 错误码与可观测性
入口必须上报错误码、耗时、失败原因桶
入口必须支持本地日志摘要导出（供审计抽查）
E. 版本与变更单机制
入口规范每次变更必须有版本号与变更单
入口实现必须声明支持的规范版本范围
禁止“静默更新”：任何影响签名字段的更新必须提前公告
银行IT旁听看完，第一次主动说话：“有了这个，我们银行侧做验真对接就稳定了。我们怕的是某家SDK突然改字段，导致证据链断裂。”
审计旁听也点头：“禁止静默更新这条必须写死，否则解释权会被更新权吞掉。”
这句话直指俘获核心：更新权=解释权。
3）兼容性测试：公开套件 + 公平排期
规范有了，还必须有“考试”。否则规范只是纸。
林远要求把“入口兼容性测试”做成与ConformSuite同一套逻辑：公开、可复核、可轮换，但不卖门票。
于是新的测试套件上线：IngressConform-v0.1，内容不多，但覆盖关键路径：
nonce获取正确性
摘要结构正确性
签名请求正确性
离线包补签正确性
隐私边界校验（不允许上报禁字段）
错误码上报完整性
版本声明与变更单链接
通过测试的入口实现，会得到一个“入口合格标签”：
ingress_label_id（可验真）
并且写入公开目录：哪家实现、支持哪些版本、最近一次通过时间。
“这不是认证售票。”林远强调，“测试套件公开，任何人都能跑；标签只是告诉市场：这家入口实现符合规范，不会暗改字段。”
本小章还未完，请点击下一页继续阅读后面精彩内容！