pbf/tasks/pbf/NavSea_Reversible_Normalization_Audit_Plan_v1.md

NavSea 可逆标准化审计方案 v1

版本：v1 Draft
用途：定义 NavSea 可逆标准化规则的审计方案，用于验证标准化过程是否完整、可逆、稳定、可重复、对渲染无破坏。

1 审计目标

本审计方案要验证五件事：

• 原始信息有没有丢
• 标准化规则有没有被正确应用
• 每个结果能不能回查
• 同一规则重复执行是否稳定
• 标准化后渲染和业务能力有没有被破坏

2 审计对象

审计覆盖以下对象：

• 规则文件
• SQL 规则表
• feature trace 表
• delivery pbf
• engineering pbf
• style 消费关系

3 审计维度

3.1 完整性审计

检查是否所有需要标准化的对象都进入了规则体系。

检查项：

• 每个实际出现的 source_layer_jp 都有标准化规则
• 每个实际出现的关键原始字段都有保留策略
• 每个 delivery feature 都有对应 trace

3.2 可逆性审计

检查是否能从标准值回查原始值。

检查项：

• source_layer_std 是否能映射回 source_layer_jp
• 标准化字段是否有对应规则 ID
• feature 是否能查到 bundle 版本

3.3 稳定性审计

检查相同输入在相同规则版本下是否得到相同输出。

检查项：

• 同一输入重复运行结果一致
• 同一 rule_id + revision 输出不漂移

3.4 渲染兼容审计

检查标准化后是否破坏当前样式表现。

检查项：

• style 引用的 layer 是否仍然存在
• 关键对象是否仍能显示
• 旧兼容表现是否没有异常缩水

3.5 业务可用性审计

检查标准化后是否仍满足检索、碰撞、点击、排障需求。

检查项：

• fid 是否保留
• taxonomy 字段是否保留
• 关键内容型日文字段是否保留
• trace 是否可回查

4 审计表设计

建议新增以下审计表：

• navsea_normalization_audit_run
• navsea_normalization_coverage_audit
• navsea_normalization_reversibility_audit
• navsea_normalization_stability_audit
• navsea_render_compatibility_audit

5 每次审计运行应记录

建议在 navsea_normalization_audit_run 中记录：

• audit_run_id
• bundle_id
• bundle_version
• source_snapshot
• target_scope
• started_at
• finished_at
• status
• notes

6 审计检查项

6.1 规则覆盖检查

目标：确认没有“实际数据里出现，但没有规则”的对象。

建议 SQL：

• 所有实际出现的 source_layer_jp
• 左连接 navsea_source_layer_rules
• 找出未命中项

通过标准：

• 未命中数量必须为 0

6.2 原值保留检查

目标：确认原始关键字段没有在工程体系中丢失。

检查字段：

• fid
• fid_legacy_raw
• source_layer_jp
• 分類番号
• 形状分類番号
• 表示用番号
• 名称
• 日本語地名
• at_raw

通过标准：

• engineering 口径中必须可回查

6.2.1 fid 可逆检查

目标：确认 NavSea 自有 fid 不是旧 fid 原样外露，且能可逆回查。

检查项：

• delivery / engineering 主 fid 是否为 16 进制字符串
• fid_legacy_raw 是否保留于 engineering / trace
• fid_algo_id 是否存在
• fid_key_id 是否存在
• 是否可通过 decrypt_number 从 fid_navsea_int 还原 fid_legacy_raw

通过标准：

• 抽样回解正确率必须为 100%
• 不允许出现“新 fid 与旧 fid 只是格式改写”的情况

6.3 规则追溯检查

目标：确认每个标准化结果都有 trace。

检查项：

• source_layer_std 是否有 source_layer_rule_id
• canonical_object_type 是否有 taxonomy_rule_id
• chart_* 是否有 render_rule_id

通过标准：

• 关键标准化字段 trace 覆盖率必须达到 100%

6.4 可逆回查检查

目标：确认能从标准值回查原值。

抽样要求：

• 随机抽样 fid
• 随机抽样 source_layer_std
• 随机抽样 canonical_object_type
• 随机抽样 chart_symbol_code

检查：

• 是否能回查 fid_legacy_raw
• 是否能回查原始 source_layer_jp
• 是否能回查 source_fields_used_json
• 是否能回查规则文件版本

6.5 重放一致性检查

目标：确认相同输入反复执行不会漂移。

方法：

1. 使用同一 bundle 版本运行两次
2. 比较以下字段：
   • source_layer_std
   • canonical_family
   • canonical_object_type
   • detection_key
   • chart_render_type
   • chart_symbol_code

通过标准：

• 差异率必须为 0

6.6 delivery / engineering 差异检查

目标：确认 delivery 简化没有破坏回查能力。

检查项：

• delivery 是否去掉了一部分原值字段
• engineering 是否仍保留完整 trace
• 是否能通过 fid 从 delivery 回查到 engineering / SQL trace

通过标准：

• 回查链条必须完整

6.7 渲染覆盖检查

目标：确认标准化后 style 仍消费当前存在的 source-layer。

检查项：

• 数据侧实际 source-layer 集合
• 样式侧引用的 source-layer 集合
• 差集

通过标准：

• 若目标是“全覆盖样式”，差集必须为 0
• 若目标是“有意忽略样式”，必须给出 ignore 清单和理由

7 审计输出

每次审计至少输出四类结果：

7.1 覆盖报告

内容：

• 实际 source-layer
• 已映射数量
• 未映射数量
• 未映射列表

7.2 可逆性报告

内容：

• 可回查率
• 无 trace feature 数量
• 缺失规则 ID 数量

7.3 稳定性报告

内容：

• 两次重放差异数
• 差异字段分布
• 受影响 feature 列表

7.4 渲染兼容报告

内容：

• style 消费的 source-layer
• 数据存在但样式未消费的层
• 关键对象抽样截图或抽样核验结果

8 审计频率

建议分三类：

8.1 每次规则变更后

必须执行：

• 规则覆盖检查
• 规则追溯检查
• 可逆回查检查

8.2 每次大批量构建后

必须执行：

• delivery / engineering 差异检查
• 渲染覆盖检查
• 抽样渲染兼容检查

8.3 每次 bundle 升级前

必须执行：

• 重放一致性检查
• 差异审计

9 不通过条件

出现以下任一情况，审计应判定不通过：

• 实际出现的 source-layer 无规则
• 关键标准化字段无 trace
• 无法从标准值回查原值
• 同版本重复执行结果漂移
• delivery 无法通过 fid 回查 engineering / SQL trace
• 样式消费覆盖与目标不符且无明确豁免

10 v1 最低可执行方案

如果要先快速落地，建议第一阶段至少做到：

1. 建 source-layer 标准化规则表
2. 建 fid 标准化规则文件和 fid 可逆回查检查
3. 在 trace 表中补 source_layer_rule_id
4. 建立 source_layer_jp -> source_layer_std 覆盖审计
5. 建立 fid -> trace 回查检查
6. 每次样式更新都跑 source-layer 覆盖差集

11 结论

NavSea 的可逆标准化不能只靠规则文档存在，必须配套审计。

审计的核心不是“看起来转换成功”，而是验证：

• 原值未丢
• 规则有据
• 结果可回查
• 重放可一致
• 渲染不被破坏

只有规则和审计同时成立，标准化这件事才算真正严谨。