要約

  • SAMP個人草案の第04版は、AIエージェントへのCONFIG・EXEC操作の結果にrecord_revisionを加えた。結果が実質的に変わるたび番号を上げ、以前の記録は追記専用の監査履歴に残す。第03版にはこの欄がなかった。
  • 遅れて確認した成功には、元の操作の効果を示す証拠が要る。同一の要求を再送しても最新結果を読み出すだけで、操作は繰り返さない。端末が確定済みの最新番号を特定できない場合は、古い結果を現在の真実として出さず、結果なしのback_pressureを返す。

「後で分かった」と「最初から分かっていた」は違う

引き継ぎの直前に管理者がエージェントの設定を書き換えたとする。応答は不明。次の担当者が望みどおりの設定値を見つけても、その変更を誰が実行したかは分からない。別の担当者が触った可能性もある。画面上の現在値だけで最初の命令を成功扱いにすると、証拠と推測の境が消える。

新しい草案では、操作参照番号と認証済み要求の結び付きを固定する。最初の権威ある結果が改訂1。元の命令に帰属する効果を後から検証できた場合に改訂2を記録し、最初の不確実性、許可の文脈、証拠参照、判明時刻も残す。バイト列まで同じ再試行は記録の照会となり、二度目の実行にはならない。

草案が求めるのは、単に「健康状態が良い」「設定値が合っている」という報告ではない。証拠の形式が、その効果を当該操作に結び付けなければならない。すでに確定した最終結果と矛盾する観測は監査上の不整合として扱い、黙って過去を塗り替えない。

実行と証拠保存の失敗も分けて報告する。操作は成功したが監査記録の永続化が失敗したなら、現在の改訂を安全に確定できる限り両方を示す。再起動や複製先への切り替えで最新改訂が判別できなければ、端末は結果を出さずにback_pressureを返す。管理側も受理済みの最大改訂を保存し、番号の逆戻りや同番号・異内容を異常とする。応答の到着順は権威の順番ではない。

IETFの文書記録では個人提出のExperimental志向の草案だ。結果不明から証拠の到着、改訂の増加、再起動までを認証付きで追う実装記録があれば、この仕組みの実効性を確かめられる。

出典：第04版、第03版、IETF文書記録。