Finding をレビューしてフィードバックを記録する

設備 Finding は、管理された証跡を 1 つのレビューワークフローにまとめるユーザー向け運用記録です。raw model event、保証された故障診断、故障確率ではありません。

入口と権限

タスク	入口	権限
Finding の一覧と詳細	/pdm/anomalies、/pdm/findings/:alertId	pdm:read
最初の人による判定を記録	Finding 詳細	pdm:write
以前の判定を訂正	Finding 詳細	system.config
Advisory を開く	/pdm/advisory/inbox	操作に対応する PdM 権限

Finding lookup は tenant scope です。別 tenant のリンクから、その ID の存在を推測できてはいけません。

レビューフロー

最初に証跡時刻とデータ品質を確認します。stale、missing、suspect、not-running のデータに基づく精密な数値は、現在の結論には使えません。

何が起きたかを理解する

Summary には対象設備と target、attention、Finding status、first/last seen、abnormal/clear persistence window、Data as of が含まれます。

項目	値	意味
Attention	OBSERVE、INVESTIGATE、URGENT	どの程度早く工学的レビューが必要か。
Status	OPEN、ACKNOWLEDGED、RESOLVED	Finding が運用フローのどこにあるか。

URGENT でも証跡レビューと安全な保全手順は必要です。ラベルだけで現場作業を自動承認しません。

4 層の証跡をレビューする

標準またはルール証跡

適用基準、grade、observed value、threshold を表示します。モデルは必須標準の結果を書き換えたり置き換えたりできません。標準とモデルが異なる場合も両方を保持します。

設備ベースライン証跡

現在の運転 segment を設備自身の分布と比較します。baseline judgement、current level、segment baseline、drift、segment days、operating context を確認します。比較不可能または履歴不足の場合、baseline は abstain できます。

モデル証跡

Execution mode、model version、score、score meaning、runtime observation time を示します。Model score は判断信号であり故障確率ではありません。別に管理された確率校正がない限り、0.8 を「故障確率 80%」とは説明しません。

SHADOW は比較専用で、ユーザー向け alert、health score、advisory、Finding を作成または変更できません。

データ品質証跡

状態	意味	対応
EVALUABLE	現在の評価条件を満たします。	工学的レビューを続けます。
NOT_RUNNING	必要な運転状態ではありません。	欠けている運転証跡から健康を推測しません。
COVERAGE_GAP	必要なデータ期間が欠けています。	欠損区間を修復または待機します。
SENSOR_SUSPECT	Sensor evidence が信頼できない可能性があります。	Sensor、mapping、unit、mounting point を確認します。
STALE	最新データが許容判断期間より古い状態です。	収集を復旧してから現在の判断に使います。
INSUFFICIENT_HISTORY	Baseline または persistence の履歴が不足しています。	有効な運転履歴を追加します。
UNKNOWN	品質を判定できません。	評価不能として source を調査します。

これらは健康またはリスク 0 の結果ではありません。

Advisory の受け入れや判定記録の前に、4 層の証跡を分けてレビューします。

推奨確認から対応へ進む

Finding には、bearing と vibration point、cooling と lubrication、temperature sensor、operating condition など限定された確認項目を含められます。これらはレビュー手順であり、証明済みの root cause ではありません。現場作業前に site の安全、permit、isolation、maintenance 手順を守ります。

保存済み推奨がない場合、設備 profile、signal history、SOP、最近の work、maintenance owner から次の安全な確認を定義します。AI assistant は不足している事実、root cause、action を作りません。

Finding は証跡と attention を保存し、advisory は提案 action と運用フローを保存します。役割は異なります。

人による判定を記録する

最初の feedback event は outcome、judgement role、confidence、reason、note を記録します。Note には事実に基づく状況だけを書き、根拠のない診断を追加しません。

送信すると append-only event が追加され、保存済みの standard、baseline、model、data-quality、lifecycle evidence は書き換わりません。同じ idempotency key の再試行で重複 feedback を作成してはいけません。

Feedback は追記イベントとして保存され、transition evidence への適用は明示的に選択するまで無効です。

「transition evidence に適用」は既定で無効です。レビュー担当者が判断を支持する pending transition を明示的に選択した場合だけ有効にします。一般的な Finding 判定で、すべての transition を暗黙に label しません。

以前の判定を訂正する

system.config を持つユーザーは以前の判定を訂正できます。訂正は次の条件を満たします。

• 最新 feedback version が必要です。
• 新しい append-only event を追加します。
• 元の event、actor、time を保持します。
• 明示的に選択した transition だけを変更します。

保存前に Finding が変わった場合、UI は conflict を報告します。最新 Finding と feedback を再読み込みしてレビューし、再送信します。他のレビュー担当者の event を上書きしません。

新しい Finding がない場合

Finding がないことは、モデルが実行されなかったことや設備が健康であることを意味しません。次の順で確認します。

1. モデル使用詳細に新しい ACTIVE runtime evidence があるか。
2. データ品質が EVALUABLE か。
3. Standard、baseline、model が管理された fusion 条件を満たしたか。
4. Persistence、hysteresis、cooldown の動作。
5. 対象 equipment scope で Finding 作成が有効か。
6. 新規作成ではなく既存 open Finding が更新されたか。

SHADOW がユーザー向け Finding を作成しないのは正常です。

トラブルシューティングと確認

症状	確認項目
Finding link が not found	現在 tenant、権限、記録が tenant 内に存在するか。
Evidence を評価できない	Data quality、source freshness、operating state、sample count、minimum history。
判定を送信できない	pdm:write と既存 feedback。
判定を訂正できない	system.config。
保存時に conflict	最新 version を再読み込みし、レビュー後に再送信。

完了前に、設備、target、tenant、Data as of を確認し、4 層の証跡を分離したまま、model score を故障確率とせず、欠損や停止を健康とせず、判定履歴が完全に残ることを確認します。

関連ドキュメント

• モデル使用と実行証跡を理解する
• 設備モデルのトレーニングと管理
• 異常レビューと保全アドバイザリー
• アドバイザリーから作業指示へのクローズドループ