2 つのギャップのフレームワーク（two-gap framework）は、現実こそが最終検証者である：エージェント型ソフトウェアエンジニアリングにおける 2 つの主要なギャップについて で提案されたもので、実装・検証ループの外側にある 2 つの不一致を記述する。このループでは、開発者またはコーディングエージェントが、デプロイ環境のモデルの下で、記録された要件に照らして評価器が受け入れるまで実装を修正し続ける。要件ギャップとは、それらの要件と、責任あるステークホルダーが実際に望んでいること、すなわちそれ自体には正式に記録された形を持たない彼らの意図との間の差である。モデルギャップとは、環境モデルと、ソフトウェアが実際にデプロイされる現実の世界との間の差である。ここでの「モデル」は想定されたデプロイ条件を意味し、言語モデルのことではない。どちらのギャップも、ループがどう実行されるかではなく、ループへの入力が意図と世界をどれだけ忠実に表しているかに関わるものであるため、論文は、より強力な評価器によってはどちらも埋まらず、機械検査された証明でさえそれらの外側については何も立証しないと論じている。
用法
著者らはこのフレームワークを主に、エージェント型ソフトウェアエンジニアリングの故障モードを説明するために用いている。彼らの説明によれば、報酬ハッキングはこれらのギャップにつけ込むものである。適応的な最適化は、評価器に対するスコアが、要件やモデルが取りこぼしている何かの恩恵を受けているという理由で、ある実装を選んでしまう。彼らの例は、キーバリューストアの最適化器が、ベンチマークの値を保存する代わりに予測可能な値を再生成することで、大幅なスループット向上を報告したというものである。取りこぼされたストレージの要件が要件ギャップにあたり、予測可能な評価値がモデルギャップにあたる。ハルシネーションは逆方向に働き、ギャップを内側から広げる。根拠のないビジネスルールを作り出せば実際に作用する要件が増え、存在しない API やパッケージを想定すれば実際に作用するモデルが増える。
論文は第 3 のギャップとして評価ギャップを区別している。これは、モデルが許容する実行において要件に違反する実装を、評価器が受け入れてしまうものである。このギャップはループの内部にあり、要件とモデルが固定されていれば原理的には埋められるものとして扱われている。フレームワークの主張は、それを埋めることは検証を強化するが、2 つの外部のギャップを克服することはできない、というものである。要件ギャップは、欠落、曖昧さ、矛盾、変化を通じて生じるとされ、モデルギャップは、実行に関する前提（入力、ワークロード、タイミング、リソース、障害、プラットフォーム、外部サービス）または評価器に関する前提（評価器が実装をどのように観察し判断するか）において生じるとされている。
適用される場面
- このフレームワークは、開かれた、変化し続けるシステムを対象としている。著者らは、こうしたシステムではどちらのギャップも一般には埋まったと認定できないと論じている。ステークホルダーの意図は部分的に暗黙的であり、実装とのやり取りを通じて洗練されていくものであり、モデルギャップを認定するには、変化し続ける世界において、モデルが関連するあらゆる条件を表していることを示す必要があるからである。
- 明示的に境界付けられたドメインでは、特定の性質についてギャップを狭めたり埋めたりできることを認めている。論文の例には、8 ビット加算器の単一の機能的性質、形式数学における証明検査、ハードウェア設計の一部が含まれ、これらを例外ではなく連続体として扱っている。
- 経験豊富な開発者が欠落を補うために使う、暗黙的なドメインや組織のコンテキストの多くをエージェントが欠いていることを前提としている。これが、ギャップ自体は AI エージェント以前から存在するにもかかわらず、エージェントがそれを拡大すると著者らが論じる理由である。
- その実践的な対応は、ギャップを埋めることではなく、ステークホルダーの判断とデプロイから得られる証拠によって駆動される外側の 保証・改訂ループ（Assurance-Revision Loop） を通じて、継続的にギャップを狭めていくことである。
- このフレームワークは一つの研究グループによる提案である。論文が引用する、要件工学、形式的正しさの限界、McCarthy の限定問題（qualification problem）、不完備契約理論といった長年の考え方を統合したものであり、例示したケースは測定による検証としてではなく、フレームワークと整合するものとして提示されている。