Trustworthy Change（TC）は、エージェント時代のソフトウェアエンジニアリング：Trustworthy Change から人間–エージェント・ソフトウェア組織へ で提案されたエンジニアリング上のオブジェクトであり、影響の大きい 1 つのソフトウェア変更のライフサイクル全体にまたがるものである。同論文は、エージェントが作業を行うようになると、既存の成果物のどれもこれを果たさないと論じている。コミットはコードの履歴を記録するがその背後にある意図は記録しない。プルリクエストは議論とテストを集めるが、変更がどのようなリソースの枠と権限のもとで受け入れられるかは記録しない。変更要求は意図を記録するが、実装の来歴から切り離されていることがある。そしてリリースは、委任と検証を構造化するには遅すぎる。TC はその変更に対する成果物横断的なアイデンティティとして機能し、何が意図されたのか、どのような権限とリソースのもとで実行されたのか、何が変わり、それはどこから来たのか、変更について述べられた主張をどのようなエビデンスが裏付けるのか、変更がどのように運用に入り、運用の中で持ちこたえるのか、そして残るリスクを誰が受け入れられるのか、に答える。
用法
同論文は TC を 6 つの作業次元に整理している。すなわち、意図と仕様、委任とリソースの枠、変更と来歴、エビデンス、統合とランタイムの状態、そして責任である。同論文は、これらが 6 つの新しい文書ではなく、追跡可能なクロージャ（閉じること）の次元であることを強調している。情報は、同じ変更へと追跡可能であり続ける限り、1 つの記録に収まっている必要はない。同論文は、確立された変更管理と構成管理をこれらの次元に対応づけている。変更要求は意図と仕様に、影響分析は仕様の精緻化とリスク分析に、レビューとテストはエビデンスに、変更承認は責任の受け入れになる。
TC は 3 つの状態を移行する。エージェントの実行による出力は Candidate（候補）である。候補は、6 つの失敗条件のいずれも成り立たなくなったときに Eligible（適格）になる。その条件とは、意図または仕様が未決定であること、権限を超えているかリソースが統制されていないこと、来歴が追跡できないこと、重要な主張に十分なエビデンスがないこと、統合または運用の準備が不十分であること、そして責任の経路が欠けているか無効であること、である。TC が Accepted（受け入れ済み）になるのは、適格であり、かつその変更について受け入れが必須であるすべての責任アンカーが残余リスクを正式に受け入れた場合に限られる。権威あるベースラインを変更してよいのは、受け入れ済みの TC だけである。適格であり、必要なアンカーが存在するもののまだ承認していない変更は、責任の失敗ではなく受け入れ待ち（acceptance-pending）であるとされる。受け入れは、あるバージョン、あるエビデンスの集合、ある時点に相対的なものである。変更が依存する権威ある事実が変われば適格性を再検証しなければならず、受け入れの前提を覆すランタイムの事実が生じれば新たな TC が始まる。
同論文はまた、受け入れ済みの TC をプロジェクト内でのコスト計上の単位となる境界として用いること、たとえば受け入れ済みの変更 1 件あたりのトークン数や人間の注意量を計上することも提案している。その論拠は、エージェントによってそれらを生み出すことが安価になると、コード行数、コミット数、プルリクエスト数、エージェントのタスク数は実際の価値からますます乖離していく、というものである。同論文はこれを、ソフトウェアの価値をプロジェクト横断で測るスコアではなく、プロジェクト内のライフサイクルの尺度として提示している。
適用される場面
この構成概念が対象とするのは、1 つの意味的な変更が多数のエージェントの軌跡、コミット、ツール呼び出し、生成されたテスト、状態の提案に分散しており、個々の局所的な成果物を統治するだけでは生産、検証、構成、責任の間の関係が失われてしまうような状況である。これは、ある領域について残余リスクを受け入れる権限を誰が持つのかを組織が特定できることを前提としており、同論文はこれを 責任トポロジー（Responsibility Topology） によって扱っている。同論文自身の位置づけでは、この枠組みは長く確立されてきた変更管理と説明責任の関心事を新たに持ち込むのではなく再編成するものであり、6 つへの分解が網羅的であるとも一意に最小であるとも主張しておらず、また理論構築であって実証的な妥当性は未解決のままである。同論文は検証のための反証可能な命題を示しているが、評価結果は報告していない。
関連用語
責任トポロジー（Responsibility Topology）、ヒューマン・エージェント・セル、 Merge-Readiness Pack（MRP）、仕様駆動開発