主张审计清单_v0.1.md 29 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 + 至少一个真实机组的分级结果）。
八、backlog 其余 6 项 · 收口结论（2026-10-06）
方法同前：观澜全仓实测（排除 .venv/vendor/node_modules）＋命中处逐行看上下文。 标签：
[已实现]观澜已有、[未接线]代码在但无调用、[不适用]观澜无此实现、[提示]仅作适用域提示。
8.1 C02 自适应基线与滞回 —— 结论 [未接线] ＋ 当前数据下不可实现
| 事实 | 证据 |
|---|---|
| 函数存在 | app_ontology/app_ontology_guanlan/sop/fusion_diag.py:88 apply_hysteresis(window_levels, *, h=3)；docstring「厂商 Hysteresis=3 的通用化：连续 h 窗同向才改级，否则保持」 |
| 无调用方 | apply_hysteresis 外部调用 0 处；oem_hysteresis 符号在观澜不存在 ✗（此前 3 处命中均为 Hysteresis 关键词，非该符号） |
| 上游输入缺失 | 其入参 window_levels（逐窗 level 序列）无生产端 ✗（level_sequence 命中 0 处）——与上游报告所述「要逐窗序列而全窗裁决不产生该序列」完全一致 |
| 当前数据下不可实现 | 观澜实况 1 窗（baseline_38_build.py:41／component_history_build.py:34／fus.盲区 自述）⇒ 连续 h 窗同向判据无窗可跨 |
处置：按 P2 同法标注「待接线 + 待扩窗（≥2 窗，理想 9 窗）」；不得在报告中称已使用原厂迟滞规则。
8.2 A03 CMS 采集可用性与 IEPE 绝对链 —— 结论 [不适用]（上游特判）＋ 观澜现行口径已明文
| 事实 | 证据 |
|---|---|
上游的「告警滞留特判」（l0_view.py:131–156） |
观澜无 l0_view.py 同名模块，亦无「告警滞留」实现 ✗（唯一命中是本清单自身） |
| 观澜现行不可判口径（等价纪律） | app_ETL/.../builders/scada_slim_build.py:19「缺列如实记（columns_missing），不造 0、不静默丢列 —— 各面按列名取，缺了就当"不可判"」 |
| 具体不可判门 | app_ETL/.../builders/pitch_face_build.py:33「消费者的不可判门是 窗内 nop < 144(≈不足 1 天等效)」 |
| 三轴口径 | app_algorithmModel/.../windcms/report_std.py（状态等级 × 证据状态 × 行动等级 + 不可判释义） |
处置：登记观澜现行口径（缺列即不可判 + 三轴），不照搬上游特判；IEPE 绝对链的现场核验仍列 backlog。
8.3 A04 冻结参照的跨域测量链「疑似」 —— 结论 [已实现]
app_ontology/.../sop/sensor_validation.py:429「疑似同一测量写多列 (仅舍入差) → parity/level/swap 全不可证」；:534「疑似派生/复制相 (rel pair-diff <1e-4)：parity 不可证 → INSUFFICIENT」- ⇒ 观澜已用「疑似」措辞并直接落到 INSUFFICIENT ✓，语义与上游 9/17 的修正一致。
- 处置：已具备；仅需在文档中写明该措辞口径（可选）。
8.4 §5-4 相对强度与绝对锚 —— 结论 [已实现] ✓
app_algorithmModel/.../perf/curves.py:100「显著门 = 物理绝对锚（z 只说"相对同类偏离"，定级必须过绝对量；MAD≈0 的镜头会造 z=200 的伪离群）」app_algorithmModel/.../service/fleet_views.py:687「灰域=全场四分位残差带；出带且过锚才算离群」app_algorithmModel/.../subsys/temp_nbm.py:6「⑦相对判据配绝对量（dev 以 K 计，报警需绝对 dev≥4K 非只 z）」；:225「单靠本表最高准定论·预警，升定论须外部绝对锚」app_algorithmModel/.../perf/powercurve.py:3「机舱风=self_ref ⇒ 绝对达成率 INSUFFICIENT 不产出」 ⇒ 与报告「相对很强 ≠ 严重损伤；须同 shard 能量占比 / 绝对锚 / 空间证据 / 持续性并列」方向一致 ✓。
8.5 §5-5 证据独立性 —— 结论 [已实现] ✓
app_ontology/.../sop/discriminators.py:937「疑似同源复制 → 勿当两路独立证据」- 且
app_ontology/.../sop/vib_confidence.py的PENALTY_KINDS['same_source_multi_stat'] = (-20, '同一路信号的多种统计量当多源')⇒ 与报告「信号族合一，独立性须追传感链/事件/时间窗/共同原因/采集触发」一致 ✓。
8.6 §5-6 覆盖与缺测传播 —— 结论 [已实现] ＋ 本版 P1 已明文化 ✓
scada_slim_build.py:19「缺列如实记、不造 0、不静默丢列」✓- 本版 P1 已把「不得静默丢窗（谱窗与仅标量/原厂状态窗分列，缺窗显式进盲区）」写成明文条款，并随
fus.纪律/fus.盲区上线 ✓
8.7 §5-1/2/3（Reference 基线公式 · CurrentCount 样本身份 · 原厂迟滞规则）—— 结论 [提示]
- 观澜没有上游这三条的公式与规则 ✗（既无「均值+3×总体 SD 及 15 样本 Peak 最大值」的对照推断实现，也无
CurrentCount样本身份治理、更无原厂逐测量迟滞读取） - 观澜仅有的 TCM 相关实逮记录：
app_ontology/.../sop/discriminators.py:4426-4427「(Method=StdDev/StdDevs=3/TargetCount=15)，基线也真的采满了（Active 条目中CurrentCount<TargetCount的 = 0，RejectCount全 0），但最终阈值是手填的全场统一固定值」 - 处置：作为适用域提示登记 —— 引用 TCM 值时不得把「参考/推断值」当作「实际数值阈」用于定级；不引入上游公式（属算法改动，需另立需求）。
九、backlog 全量状态（截至 2.89.5）
| 项 | 状态 |
|---|---|
| 第 1 项 · 持续性门/覆盖门定位与窗数口径 | 已完成（2.89.1 定位） |
P0 · 门随窗数伸缩 max(4, ceil(2N/3)) |
已完成（2.89.2） |
P1 · 口径明文化 + 随 fus.纪律/盲区 上线 |
已完成（2.89.3，线上实测条款在场） |
P2 · 置信度接线状态标注 unwired |
已完成（2.89.4） |
| C02 · 滞回接线与逐窗序列 | 已定论：未接线 + 当前 1 窗不可实现 ⇒ 标注「待接线 + 待扩窗」 |
| A03 · 可用性链路特判 | 已定论：上游特判不适用；观澜现行口径（缺列即不可判 + 三轴）已登记 |
| A04 · 「疑似」措辞 | 已定论：观澜已实现（sensor_validation 疑似 → INSUFFICIENT） |
| §5-4 相对强度与绝对锚 | 已实现（四处证据） |
| §5-5 证据独立性 | 已实现（discriminators + vib_confidence 扣分项） |
| §5-6 覆盖与缺测传播 | 已实现 + P1 明文化 |
| §5-1/2/3 TCM 公式与规则 | 未引入（作为适用域提示登记；引入属算法改动，需另立需求） |
十、共模（common_mode）为何未计入 E 轴 · 及扩窗收益表（2026-10-06）
10.1 结论：不补分（无产物承载）
E 轴的 checks_total 含四类：fleet_base_rate / common_mode / intrinsic_line / alternative_explanation。
实测（2026-10-06）：
| 类别 | 观澜是否有候选链上的闸/产物 | 计入 |
|---|---|---|
fleet_base_rate |
✓ 有：G8_NOT_FLEET_OUTLIER（过闸 funnel） |
计 5 分 |
intrinsic_line |
✓ 有：G4_INHERENT_OR_BATCH（固有线/批次） |
计 5 分 |
alternative_explanation |
✓ 有：G6_SELECTIVITY/G7_PEAK_OFFSET/G5_INTEGER_ORDER/G2_NO_LINE |
计 5 分 |
common_mode |
✗ 无：L6 过闸 funnel 里没有共模闸；G4_INHERENT_OR_BATCH 是固有线/批次（fleet 共有谱峰），与共模（fleet 同期共同变化）不同义 |
不计（0 分） |
⇒ E = 20×3/4 = 15.0（如实）。
观澜确有共模机制，但不在振动候选链上（实测出处）：
app_algorithmModel/.../subsys/temp_nbm.py:197–207（common_shift() 共模图，「实验 K 接线 2026-09-07」；
判据族见 sop.discriminators.fleet_two_component_split）· sop/analysis_kit.py:170（机群相对偏差扣同期共模）·
sop/stat_clean.py:17（>半数同向共模 = 反转，EXP-C4-01 ⇒ kill 熔断）· sop/hydraulic_validation.py（共模/差模分解）·
sop/discriminators.py（共模相关 67 处）。
10.2 为什么现在做不出来：与 C02、§5-3 同一根阻塞
共模 = 同期跨台共同变化 ⇒ 必须有时间序列 / ≥2 个窗才可判。而观澜实况是 1 窗（w0316）。
⇒ 共模类反证、逐窗滞回（C02）、原厂逐测量迟滞（§5-3）三者同源阻塞：都等扩窗。
10.3 扩窗收益表（若补齐更多周期 CMS 原始件）
| 受益项 | 现状 | 扩窗后（≥2 窗，理想 9 窗） |
|---|---|---|
D 轴窗覆盖（score_sample） |
2.5 分（1 窗 / 门 max(4,ceil(2N/3))=4 ⇒ 1/4） |
≥4 窗 ⇒ 满分 10；9 窗 ⇒ 门 6 ⇒ 6/9 覆盖按窗数计 |
A 轴持续性分量（score_internal） |
0（无逐窗序列） | 有逐窗序列 ⇒ 可达 3 分（门随 N 伸缩） |
| E 轴 common_mode | 0（无产物） | 可做"同期跨台同变"检验 ⇒ E 可达 20 |
| C02 逐窗滞回 | 不可实现（window_levels 无生产端） |
apply_hysteresis(window_levels, h=3) 可接线 ⇒ 显示锁存可落地 |
| §5-3 原厂逐测量迟滞 | 不可实现 | 可构造"缺口不被当状态机反例"的用例与实现 |
fus.盲区 的自述 |
「单窗数据时"逐窗趋势"信息量有限」 | 逐窗趋势可用 ⇒ 该盲区条目可撤 |
置信度 usable |
11/107 | 随 D/A/E 补齐而显著扩大（B 仍属现场数据现实） |
注：上表只列已实测到的机制与已知的取数口径，未承诺具体分值；扩窗后须逐项复跑并重新出件。
十一、置信度「消费口径」定案（2026-10-06 · 用户选 2：暂不扩窗）
决定：维持「诊断展示」，不参与任何判级、不进报告等级栏。
| 现状 | 位置 |
|---|---|
| 逐台五轴（A–E）+ 缺件清单 + caveat | API：/api/fleet → fus.置信度（per_row） |
| 页面展示（含分档计数 · 各可取轴已取到行数 · 结构性缺件 · 前 8 台明细 · 接线状态 · 不可判状态告诫） | 振动融合分析页「置信度（诊断）」面板（data-added="confidence"） |
| 判级影响 | 无（接线只新增字段，未改动任何 verdict/等级/结论） |
为什么不升级为"消费"（即不让它驱动报告/派工） —— 三个前提尚未满足：
- E 轴 common_mode 缺失（无候选链产物；且需 ≥2 窗时间序列 ⇒ 属"扩窗"前置）；
- A 轴仅粗口径（有 ≥1 条 PASS 线按 5 闸计；
model_run_l6只含 PASS 行 ⇒ 逐台逐闸明细无产物承载）； usable覆盖率低（本地 11/107；线上 69 行视图 6）—— 且 B 轴同窗独立源属现场数据现实（温度判「—」/油样 stale），非算法可补。
升级条件（三条同时满足，且需用户明确要求）：
① 扩窗到位（≥2 窗，理想 9 窗）⇒ 补 common_mode 与 A 轴逐窗序列；
② usable 覆盖显著扩大（并明确 B 轴缺件时的等级截断规则，如"B 缺 ⇒ 最高只能到中"）；
③ 用户明确下令"接入报告/派工"（届时须先列出判级变化范围，逐一核对）。
同时保留的禁令（延续 P2）：接线验收前，报告与交付件不得声称已使用置信度评分；现阶段的正确表述是
「置信度已作为诊断随 /api/fleet 下发，页面可见，但不作为判级依据」。
十二、窗数口径实测与扩窗结果（2026-10-06 · 用现有 raw 自行造窗）
背景：无需任何外部数据 —— windows/w0316/index.parquet（206.7 万行）含 file（相对 …/measurement/）与
trigger_time，覆盖 2026-03-16 → 04-21（37 天） ⇒ 可按时间粒度切窗。
已建成并跑通（本地与远端一致）：
| 粒度 | 窗数 | 门 max(4, ceil(2N/3)) |
各窗 PASS |
|---|---|---|---|
| 单窗（原始） | 1 | 4（形同虚设） | 14 |
| 周窗 | 5 | 4 | 14/15/10/18/8 |
| 半周窗（4 日，现用） | 10 | 7 | 14/7/9/4/4/2/6/8/6/5 |
| 3 日窗（构建中） | ~13 | 9 | —— |
对置信度的影响（实测）：中位 2.5 → 10.5（接 A/C 轴）→ 25.5（接 E 轴）→ 29.5（5 窗）→ 34.5（10 窗）；
usable 0 → 11 → 23 → 27/107（线上 69 行视图 17）。common_mode 在 5 窗时 3 条共有线、10 窗时 5 条。
融合面边界（如实）：融合级 fus.窗区间 仍锚在 1 窗 —— 因为它取自「振动线正本 handoff_vibration_v2.json」
（含人工裁决，rudong_fusion_handoff.py 拒绝覆盖，本清单未使用 --force）。
本轮只修了 scripts/rudong_fusion_run.py 的默认窗（原写死 w0127 首窗特例 ⇒ 清过产物的机器必然失败；
现改为"已发现的最新窗"，并把缺失首窗按既有 windows_missing 机制如实处理）⇒ rc=0，
产出 fleet_scalar_z.parquet（604 行）与 fusion_38.csv（38 台 · 融合级 参考 18/正常 13/候选 7）。
呈现：振动融合分析页新增两处 data-added 面板（不参与任何既有对拍判据、不改判级）：
「置信度（诊断）」与「迟滞诊断（原厂 Hysteresis）」（后者显示 33 条序列 / 5 条被迟滞改变 / 逐测量迟滞分布）。