複数の情報源が矛盾する：Trust Ringと裁定ルール

暗黙知の体系的な外部化を開始し、アーキテクチャ判断、既知の制約、歴史的教訓をドキュメントシステムに書き込んできた。しかし新たな問題が浮上する。情報源が増えるにつれ、それらが互いに矛盾し始めるのだ。

アーキテクチャドキュメントにはこのサービスはREST APIを使うべきだと書いてあるが、最近の設計議論のメモにはチームがgRPCに移行することを決定したと記されている。コードのコメントには非推奨のデータフォーマットと記されているが、仕様はまだそのフォーマットを参照している。プロダクト要件ドキュメントには「バッチ操作をサポート」と書いてあり、技術設計ドキュメントには「第一フェーズは単体操作のみサポート」と書いてある。

Agentがこれらの矛盾に遭遇した場合、その処理は人間とはまったく異なる。人間のエンジニアであれば立ち止まって同僚に尋ねるか、プロジェクト全体の理解を使ってどの情報源がより信頼できるかを判断する。Agentは矛盾する情報源の中から1つを選び、実行を続ける。その選択基準は、コンテキスト内で後に出現する方、より具体的な表現の方、あるいはその他の予測不能な要因かもしれない。結果として、実行のたびに異なる選択が生まれ、出力に隠れたランダム性の源泉が加わる。

Trust Ringはこの問題を解決するメカニズムである。中核的なアイデアは、情報源を優先度順にレイヤー化すること。情報が矛盾する場合、より高い優先度の情報源が低い優先度の情報源を上書きする。

Ring 0は仕様自体である。これがSingle Source of Truthであり、他のすべての情報源が矛盾する場合、仕様が優先される。仕様に書いてあることを、Agentは実行する。

Ring 1はアーキテクチャドキュメントとAPIコントラクトである。システムの構造的制約を定義する。仕様が特定の技術的判断に言及していない場合、アーキテクチャドキュメントが優先される。

Ring 2は設計議論の記録、技術提案、会議メモである。判断の背景とコンテキストを提供するが、過時または却下された提案を含む場合がある。

Ring 3はその他すべてである。コードコメント、個人メモ、外部参照。信頼性が最も低く、補足的な情報としてのみ機能する。

Trust Ringのルールは、Agentの作業指示に明示的に記述する必要がある。例えば：「複数の情報源が同じ判断について異なる記述をしている場合、以下の優先順位で裁定せよ。仕様 > アーキテクチャドキュメント > 設計議論 > その他。情報の矛盾を発見した場合、矛盾箇所と採用した情報源を出力に注記せよ。」

最後のルールは特に重要である。Agentに矛盾箇所の注記を求めること。これにより、暗黙のランダムな判断が、明示的で監査可能な選択に変わる。人間のレビューでは、コードを行単位で読む必要はなく、Agentが注記した矛盾箇所とその裁定根拠を確認するだけでよい。

Trust Ringもメンテナンスが必要である。設計議論の判断が確定した場合、アーキテクチャドキュメントまたは仕様の一部に昇格させるべきである。古いドキュメントが新しい判断によって上書きされた場合、古いドキュメントには非推奨のマークを付けるか削除すべきである。情報源の階層はプロジェクトの進化とともに変化する。Trust Ringのメンテナンスは仕様システムのメンテナンスの一部である。