ログは「起こらなかったこと」を記録できない
ほとんどのAIセーフティツールは、アーティファクト（痕跡）を探します。ログのエントリ、署名、あるいはツールの実行結果などを探すのです。ツールの結果が偽物であれば、システムはそれをフラグ立てします。JSONブロックが壊れていれば、システムはそれを検知します。
これらは痕跡が残るため、検知しやすい失敗です。
真の危険は「欠落」にあります。欠落とは、何も起こらないことを指します。
追加専用（append-only）のログにおいて、「不在」は以下の3つの状態として同じように見えてしまいます。
- 起こらなかった。
- まだ起こっていない。
- 起こったが、記録されなかった。
ログには何も表示されず、監査クエリも何も返しません。「沈黙」が「同意」となってしまうのです。
これを解決するには、3つの設計ルールがあります。
沈黙に期限を設ける エージェントがアクションを実行した場合、レビュアーがそれを承認（sign off）しなければなりません。署名の欠落はセキュリティ上の穴となります。「保留中（pending）」のまま永遠に放置してはいけません。期限を設定してください。期限が過ぎた場合、システムは
REVIEW_EXPIREDのような終端状態（terminal state）を記録する必要があります。これにより、空白が「検索可能なエラー」へと変わります。主張には引用を必須にする エージェントはしばしば、散文（文章）を用いて世界を記述します。例えば、エージェントが「ファイルは空でした」と言ったとします。それを裏付けるツールの実行結果がなければ、その主張は危険です。
主張が将来のアクションに影響を与える場合、必ず observation ID を含める必要があります。エージェントが真実を言っているかどうかを推測しようとしてはいけません。単に、その主張が実在するデータソースを指しているかを確認するだけでよいのです。引用のない主張は、不正な形式のメッセージ（malformed message）です。
- アクションには2つのイベント分割を用いる エージェントがメール送信などのタスクを開始した際、結果をログに記録する前に停止してしまうことがあります。これによりギャップが生じます。メールは送信されたのか？ 再試行すべきなのか？
次のフローを使用してください：
- 一意のキーを持つ
INTENTイベントを追加する。 - アクションを実行する。
OUTCOMEイベントを追加する。
これにより、中間状態を確認できるようになります。INTENT はあるが OUTCOME がない場合、システムのどこで失敗したのかを正確に把握できます。推測する代わりに、状態を整合（reconcile）させることが可能です。
ルールは単純です。システムが記録するあらゆる「成功」に対して、「その記録が欠落していた場合に何が起こるか」を問いかけてください。もし答えが「何も起こらない」であれば、そこにブラインドスポット（死角）が存在します。
ネガティブな状態を「第一級のレコード（first-class records）」として設計してください。名前を与え、責任者（owner）を割り当て、ゲート（判定プロセス）で失敗させるようにしてください。
Source: https://dev.to/anp2network/your-log-cant-record-what-didnt-happen-2ga7
Optional learning community: https://t.me/GyaanSetuAi