判断した後も、その理由が続いているかを監視する

結果が悪くなってから、AIに「なぜ始めたのか」を説明させても、当時の理由を復元したことにはなりません。期待した変化、使用した根拠、その根拠が有効な期間、撤回する条件を開始時に記録します。

複数の理由がある場合は、主な理由と補助的な理由を分けます。どれか一つ崩れたら見直すのか、複数の条件が崩れたときに見直すのかも、先に決めます。

異常を見つけられなかったことが、前提の維持を意味するとは限りません。必要な資料を取得できない、対象を特定できない、情報が古い場合は、確認できない状態として扱います。

短期の結果が悪くても、最初の理由が残っている場合があります。逆に数値が良く見えていても、理由を支えていた条件が崩れている場合があります。結果、理由、リスク上限を別の観測として扱います。

例えば架空の仕入先選定なら、価格の上昇、品質保証の失効、品質データの未取得は別の出来事です。それぞれに対応する見直し条件を定めると、場当たり的な継続や停止を減らせます。

監視は、前提が崩れた根拠を示します。操作を実行するかは、利用者、対象、変更範囲、許可、重複の確認を通して決めます。監視の結論だけで、新しい権限を作らない設計にします。

通知には、起きたこと、対象への影響、対応状況、利用者の操作が必要かを載せます。内部の状態コードだけで通知を終えると、正しい検知があっても実務の対応につながりません。