主张审计清单_v0.1.md 16 KB
主张审计清单 v0.1
依据：
wind_analytics_算法模型分类报告（上游仓wind-analyticsmain357350d4，2026-09-30 静态核验快照） 的 §4「历史要求与当前实现的关键差异」（9 条） 与 §5「TCM 原判断与修正边界」（6 条）。 目的：把该报告的「原判断 → 反例 → 修正 → 适用域」写法，落到观澜自己的代码与文档上，防名实误读。核验方式（本清单的证据级别）：对观澜仓单次遍历 23,828 个文本文件逐条正则核验 ＋ 命中处逐行看上下文（是注释/文案，还是真实逻辑）。 口径纪律：报告中以上游
357350d4的 file:line 为准，不得直接引为观澜结论；下表「观澜实测」列是本清单唯一可引用的结论来源。标签：
[记]报告/文档主张 ·[码]本轮核到观澜代码 ·[待核]需进一步定位 ·[不适用]观澜无此实现 ·[已优于]观澜已优于上游
一、§4 历史要求与当前实现的关键差异（9 条）
| # | 报告条目 | 报告原判断 / 反例 / 修正 [记] |
观澜实测 [码] |
结论与处置 |
|---|---|---|---|---|
| 1 | C04 固有线图谱与共模分解 | 「缺陷率>50% ⇒ fleet 全盲」已于 9/5 撤销；当前六层文档仍残留旧句 | 观澜全仓 全盲 仅 1 处：app_algorithmModel/app_algorithmModel_guanlan/windcms/report_std.py:182，上下文是具体机组的说明——"全盲台 02/18/37 各部件皆不可判 → 整机自然不可判" |
不残留 ✓：同词不同义（观澜说的是"某几台不可判"，不是那条已撤销的失明定理）。处置：无需改代码；如需彻底消歧，可在六层链文档加一句"本处'全盲台'指具体机组，非'缺陷率>50%⇒fleet 全盲'定理" |
| 2 | A03 CMS 采集可用性与 IEPE 绝对链 | 9/25 已在 l0_view.py:131–156 加告警滞留特判、report_std 已接 avail_detail；但旧缺陷表未同步 |
观澜 report_std.py 有完整三轴口径（状态等级 优秀/良好/报警/危险/不可判 × 证据状态 确诊/准定论·预警/候选/INSUFFICIENT × 行动 P0–P3）与"不可判"释义；discriminators.py 有 Active/CurrentCount/TargetCount（TCM 侧）。观澜无 l0_view.py 同名模块（已重构） |
部分适用 [待核]：观澜无报告所指"旧缺陷表"，故不存在"未同步"；处置：登记"可用性口径以 report_std 三轴为准"，并把"能否区分告警滞留 Active 与在场数据"列入补核 |
| 3 | A04 冻结参照的跨域测量链疑似 | 9/17 判定已改「疑似」；l0_absolute/cms_availability 有绝对电气链；9/18 已有 D1b 绝对检查 |
该主题在观澜多处存在：app_algorithmModel/.../taxonomy.py、subsys/fusion.py、windcms/report_std.py、app_ontology/.../ontology/codes.py、sop/discriminators.py、scripts/rudong_fusion_handoff.py |
[待核]：观澜侧"疑似"这一措辞与判据是否已落文档（不是代码有无）；处置：列入 backlog，逐文件确认"疑似/不可判"是否与绝对链并存 |
| 4 | C02 自适应基线与滞回 | oem_hysteresis.py 已有可导入原厂规则；上游 apply_hysteresis 需逐窗 level 序列，而全窗裁决不产生该序列 ⇒ 函数存在 ≠ 默认生产链使用 |
观澜 app_ontology/.../sop/fusion_diag.py 有 3 处滞回相关；未见 oem_hysteresis/apply_hysteresis 同名实现 |
[待核]：需定位观澜的"显示锁存/原厂迟滞"落在哪一层，并确认是否被默认链调用（这正是报告告诫的"函数存在 ≠ 已使用"） |
| 5 | C05 同域能量锚与部件实物锚封顶 | 持续性已由固定 4/6 改 ceil(2N/3)；rudong_model_run.py:427–432 九窗要求 6 窗；不能再拿四窗当九窗中的同等证据 |
观澜 四窗 命中 3 处，全部是注释里的观测事实（discriminators.py:4796"四窗纹丝不动"、5082"跨四窗 1.61~1.74×fleet"、vib_confidence.py:85 同）；观澜 Python 全仓未出现 ceil(2N/3)，亦未见 九窗 |
局部适用 [待核]：观澜没有那条"四窗=九窗同等证据"的误用（注释语义清白 ✓），但也未采用比例门 ⇒ 处置：定位观澜的持续性门实现位置并明确其窗数口径（列入 backlog 第 1 项） |
| 6 | C01 ISO 速度 RMS 与宽带标量 | 上游 report_std.iso_state 实际只按 7.1 mm/s 二分报警与优秀，融合脚本另用 7.1/11 mm/s ⇒ 显示与融合口径须分别看 |
观澜 windcms/report_std.py:67：ISO_C, ISO_D = 7.1, 11.0，并带注释记录历史漏判实逮（"17# 8.9 超C / 27# 128 超D 漏判实逮"） |
已优于上游 [已优于] ✓：观澜 report_std 已同时携带 C/D 双阈 ⇒ 本例的"口径分列"问题在观澜不存在。处置：无需改；可在文档中把该双阈写成显式口径条目 |
| 7 | B21 四层异常检测与预警器 | 旧四层 trend_level.py:20 对空输入/无时间戳/少于 5 日输出 A，存在"旧入口语义风险" |
观澜除 src/windscada/en_text.py 一处翻译字符串外，无四层实现与调用 |
不适用 [不适用] ✓：观澜未移植该模块，风险不传递 |
| 8 | B02 限电、停机与离线分离 | 注册表状态陈旧（configs/analysis_modules.yaml 写 builtin_avail_verify 待实现，实际 discriminators.py:2223 已实现） |
确证同源缺陷：观澜 app_ontology/.../sop/discriminators.py:1094 原文写"…builtin_avail_verify/zero_gen_redflag 待实现"，而两者均已实现 —— builtin_avail_verify 在 2203 行、zero_gen_redflag 在 2234 行 |
真缺陷 → 本版已修 ✓：改为"两函数实现均已在本模块落地（§4.3 与同批 n≥2 提级），此处仅说明不入 A_op 抽取面、留 per-farm 传入比对" |
| 9 | D04 gym 算法探索与淘汰图 | 7 月"灰箱永久关闭"是特定实验/治理结论，不是所有灰箱方法被理论否定；应保留失败主张与重新进入条件 | 观澜无 gym 目录 ✗ |
不适用 [不适用] ✓：观澜无该实验套件；该报告条目仅作方法论参照 |
二、§5 TCM 原判断与修正边界（6 条）—— 逐条对照观澜
报告这 6 条写法(原判断 → 反例 → 修正 → 适用域)最具复用价值；观澜的 TCM/CMS 复算链正在同一主题上 （实测：
windcms/report_std.py含rms_200/Reference、discriminators.py:4426有"最终阈值是手填的全场统一固定值"的实逮记录、docs/振动六层链_接口规格与缺口_v0.1.md含 TCM/Hysteresis 口径）。
| # | 报告条目 | 报告要点 [记] |
观澜处置（建议） |
|---|---|---|---|
| 1 | Reference 基线 | 原判断"mask.Reference=样本均值"为 FALSE；修正为「均值+3×总体 SD 及 15 样本 Peak 最大值」的对照推断（9/17 登记准定论）；适用域：样本级重建未成，不能拿推断基线替实际数值阈定级 |
[待核]：核对观澜 TCM 文档/代码里对 Reference 的表述，补一句"推断值，不得替代实际数值阈" |
| 2 | CurrentCount 样本身份 | 原判断"同计数=同批样本"为假；修正：同计数可对应不同接受样本组；适用域：不可把计数当原始样本覆盖 | [待核]：加入口径说明（覆盖/样本量陈述时不得等同） |
| 3 | 原厂迟滞规则 | 原判断"mask.Hysteresis恒 3 即上限"被反例（rms_200 上限 100）；修正：逐测量读取 Red/YellowHysteresis、±1 钳位、到上限起报到 0 解除；适用域：紧邻完整记录，缺口不能当状态机反例 |
[待核]：与观澜 fusion_diag.py 的 3 处滞回实现对照（见 §4 第 4 条 C02） |
| 4 | 相对强度与绝对锚 | "×fleet 很高即严重损伤"被反例（同域能量极弱/共有固有线分母效应）；修正：同 shard 能量占比 ＋ 绝对锚 ＋ 空间证据 ＋ 持续性并列；适用域：单场标定阈，未知供应商频率阴性不能销案 | [待核]：观澜融合侧的"相对＋绝对"是否并列呈现（与 C05/C04 同源） |
| 5 | 证据独立性 | "谱线+宽带+峭度＝三条独立证据"被反例（同测点同信号）；修正：信号族合一，独立性须追传感链/事件/时间窗/共同原因/采集触发 | 建议直接采纳 ✓：观澜报告里"多证据"的表述需按此审查（避免把同源信号当独立证据） |
| 6 | 覆盖与缺测传播 | "缺一窗都盲/无判据触发就正常"被反例（部分覆盖被埋进健康）；修正：覆盖 ceil(2N/3)、盲区门传导、疑似健康证据撤回；适用域：谱窗与仅标量/原厂状态窗分列，不静默丢窗 |
[待核]：与观澜"不可判/盲区"口径直接相关；结合 §4 第 5 条一起定位持续性/覆盖门 |
三、A 档执行结果（本次）
| 项 | 结果 |
|---|---|
| 确证真缺陷 | 1 处：app_ontology/app_ontology_guanlan/sop/discriminators.py:1094 陈旧文案（两函数均已实现却写"待实现"）—— 本版已修 ✓ |
| 同词不同义（假阳性，已澄清） | 2 处：C04 全盲（指具体全盲台）· A03 滞留（指热滞留） |
| 观澜已优于上游 | 1 处：C01（report_std.py 已同时带 7.1/11 双阈） |
| 不适用（观澜无该实现） | 2 处：B21 四层异常 · D04 gym |
| 列入 backlog（需进一步定位） | 7 处：C05 持续性门位置与窗数口径（优先）· C02 滞回是否被默认链调用 · A03 可用性链路特判 · A04「疑似」措辞与判据 · §5 六条中除"证据独立性"外的 5 条 |
四、下一步（建议 B/C 档，未在本版执行）
- B 档：新增
docs/模型谱系与编号_v0.1.md（观澜自口径的 48 类骨架，A01–A05 / B01–B26 / C01–C10 / D01–D03 / D04 / E01–E03 ＋ L0–L5 分层），并在交付文档引入证据标签体例。 - C 档：把报告 §6「优先补核六项」做成观澜 backlog 并逐条推进（部分需现场数据/标准原件 ⇒ 标
[INS]）。 - 禁止：不并入上游分支；不照抄其 file:line 与状态；不用该报告替代观澜验收。
五、backlog 第 1 项 · 已定位（持续性门 / 覆盖门与窗数口径）
对应 §一 第 5 条（报告 C05）与 §二 第 6 条（TCM 覆盖与缺测传播）。本节为实测定位结果，实现位置与口径均为观澜自身证据。
| 门 | 观澜实现（file:line） | 现行口径 | 与报告 ceil(2N/3) 对照 |
|---|---|---|---|
| 持续性门（A 轴 3 分） | app_ontology/app_ontology_guanlan/sop/vib_confidence.py:146：p = 3.0 * min(persist_windows / max(min(4, n_windows), 1), 1.0) |
分母固定封顶 4；函数默认 n_windows=6 |
仅当 N=6 时 ceil(2·6/3)=4 恰好等价 ✓；N=9 时上游要求 6，观澜仍取 4 ✗ ⇒ 潜在隐患（扩窗即静默放宽） |
| 窗覆盖门（D 轴 10 分） | 同文件 :173：w = 10.0 * min(n_windows_covered / 4.0, 1.0) |
同样 4 封顶 | 同上；且 score_sample() 签名没有 n_windows 参数 ⇒ 无法随窗数伸缩 |
| 盲区门 | 同文件 :168–174：if is_blind: return 0.0 |
盲区台直接 0 分 | 与报告"盲区门传导"一致 ✓ |
| 逐日持续（冲击轴） | app_algorithmModel/.../windcms/report_std.py:187（acute = 持续恶化）、:213（n_high_days_all >= 3） |
3 天门 + 类型枚举（持续恶化/稳定高位/阶跃抬高/反复发作） | 另一轴（逐日），与窗数无关 |
| 比例门（同步/份额） | app_ontology/.../sop/farm_pipeline.py:57 sync_fraction >= 0.5；app_algorithmModel/.../service/fleet_views.py:458 _share >= 0.5 |
0.5 门 | 与"L0 覆盖也是比例门"的精神一致 ✓（观澜已有比例门，只是不在持续性轴上） |
| 实际窗数 | app_ETL/.../builders/baseline_38_build.py:41「本机实况: 只有 w0316 一窗」；component_history_build.py:34「FARMS['rudong']['windows'] 只解析出一个窗」；融合产物 fus.盲区 自述「单窗数据时"逐窗趋势"信息量有限(按日聚合后可见)」 |
当前 1 窗 | ⇒ "四窗当九窗同等证据"的情形在观澜尚未发生 ✗；但门是硬编码 4 ⇒ 扩到 9 窗时会静默放宽 ✗ |
| 是否接入生产链 | score_internal / score_sample 在观澜全仓（排除 .venv/vendor/node_modules）无任何调用点 |
未接线 | 正是报告反复告诫的「函数存在 ≠ 生产链使用」✓ —— 本清单按 [码]（存在）记录，不按 [场]（已用）记录 |
处置建议
- P0（低风险，建议做）：把两处硬编码
4改为随窗数的比例门 ——max(1, ceil(2*n_windows/3))。 理由：N=6 时行为完全不变（ceil(2·6/3)=4）⇒ 零回归；N=9 时自动变为 6，与报告口径一致。 注意：score_sample()需新增n_windows形参（当前签名没有）。 - P1：在文档中把窗数口径写成显式条目（当前 1 窗 / 目标 9 窗 / 门的形式），并把「单窗时不得用持续性、趋势类判据」提升为拒判条件（观澜
fus.盲区已有同义自述，仅需升格为明文口径）。 - P2：确认这两个评分函数是否应接入生产链：现状是未接线 ⇒ 要么接线，要么在代码注释与清单中明确标注"待接线"，避免被误读为"已在用"。
六、P1 执行结果（2026-10-06）
| 落点 | 内容 |
|---|---|
sop/vib_confidence.py 模块文档 |
修正 P0 后已过时的两处口径行（A 轴「持续≥4/6窗」、D 轴「覆盖窗数≥4」⇒ 均改为 max(4, ceil(2N/3))）；并把「窗数口径与单窗拒判」写入模块头 |
scripts/rudong_fusion_handoff.py |
振动 meta 的 纪律 增列窗数口径条款 ⇒ 经 service/fleet_views.py:581 传导到页面 fus.纪律 |
docs/振动六层链_接口规格与缺口_v0.1.md |
新增「窗数口径与拒判条件」节（含门的形式、单窗拒判、不得静默丢窗、当前实况 1 窗、四处出处 file:line） |
| 本清单 | 本节 |
条款要点：① 门 = max(4, ceil(2N/3))（N≤6 恒 4 · N=9 ⇒ 6 · 分母只增不减 ⇒ 不会更宽松）；
② N<3 时不得用持续性/逐窗趋势类判据出个体结论，只能标「窗内周段趋势（单窗补充口径，仅参考不作判据）」（与既有降级口径同源）；
③ 不得静默丢窗（谱窗与仅标量/原厂状态窗分列，缺窗显式进盲区）。
七、P2 执行结果（2026-10-06）
决定：标注「待接线」（unwired），不擅自接线。 理由：接线会改变报告/页面呈现，属产品决策；而报告告诫的核心风险是"函数存在 ≠ 生产链使用"，用明文标注即可消除误读。
| 落点 | 内容 |
|---|---|
sop/vib_confidence.py |
新增常量 WIRING = 'unwired' 与 WIRING_NOTE，并写明：接线实测证据（外部调用 0 处）、接线入口（api.py:45 注册 sop_vib_confidence）、接入前禁令（报告/交付件不得声称已用置信度）、以及接线后须改为 'wired' 并记录接入点与验收证据 |
docs/振动六层链_接口规格与缺口_v0.1.md |
新增「置信度模块接线状态」小节（同步同一事实） |
| 本清单 | 本节 |
实测依据（2026-10-06）：score_internal / score_independent / score_falsification / confidence / penalize / band 外部调用 0 处；score_physical、detectability 仅本文件内部使用；模块已在 ontology API 注册（api.py:45）⇒ 具备接线条件但尚未接线。
若日后要真正接线（产品决策，本版未做），需明确三件事：① 消费端（报告等级栏 / 页面字段 / 交付件）；② 输入来源（五轴的 A–E 各自取数口径，尤其 B 轴的共时源与 C 轴的实物锚）；③ 验收证据（接入点 file:line + 至少一个真实机组的分级结果）。