ブランドエージェントは自身のデータを使って答えます — それは brand.json プラス、静的ファイルが表現できないよりリッチな状態（
pending_review、transferring、licensed_in など）です。ツールは get_brand_identity が読むのと同じアイデンティティ表面の上の 1 つの特定質問アフォーダンスです。
高ボリューム検証（ポートフォリオリフレッシュ、クリエイティブクリアランスバッチ、クローラースキャン）には、バルクバリアント verify_brand_claims を使います — 同じクレームごとのセマンティクス、バッチ全体に 1 ラウンドトリップと 1 レート制限スロット。
信頼ルール — 1 つではなく 2 つの呼び出し
単一の署名付きowned レスポンスは信頼拡張ではありません。相互主張が肯定的信頼のフロアのままです。 これは非対称信頼モデルの荷重を担うルールです — 主張方向は両側の同意を要求します。消費者は関係信頼を拡張するとき両側を呼ばなければなりません（MUST）:
subsidiaryクレームには、claim_type: "parent"でリーフのブランドエージェントも呼ぶ（またはリーフのbrand.jsonをhouse_domainのためクロール）。propertyクレームには、ブランドの静的brand.jsonproperties[]と（ドメインには）DNS/TLS 証拠に対してクロスチェック。trademarkクレームには、公開レジストリレコードをクロスチェック。特にlicensed_inには、ライセンシング関係が信頼される前に、details.licensor_domainで名指しされたライセンサーが同じマークについてlicensed_outを相互にすべき（SHOULD）。- 拒否（
disputed/not_ours）のみが単一の署名付きレスポンスで権威的 — ブランドは一方的に関連を拒否する立場を持つ。
brand.json § エージェント拡張検証 を参照してください。
スキーマ
- Request:
verify-brand-claim-request.json - Response:
verify-brand-claim-response.json
ケイパビリティディスカバリー
ブランドエージェントはget_adcp_capabilities レスポンスでこのタスクをアドバタイズします。一部のクレームタイプのみをサポートするエージェントは、ツールごとのケイパビリティ拡張経由でこれを宣言します:
supported_claim_types が省略されるとき、エージェントは 4 つすべてのサポートをアドバタイズします。消費者は特定のクレームタイプに依存する前にチェックしなければなりません（MUST）。サポートされないタイプは UNSUPPORTED_CLAIM_TYPE を返します（Error handling を参照）。
最小実行可能採用
ブランドエージェントは 4 つすべてのクレームタイプを一度に出荷する必要はありません。ワークフローに一致するスライスを選びます:- Property のみ — クリエイティブクリアランスと在庫オンボーディング消費者。最小の有用な表面。
- Subsidiary + parent — ブランド関係確立またはガバナンス信頼拡張を行うパートナー。相互主張がエージェント層で完了するよう両半分を一度に出荷。
- Trademark のみ — ライセンシー姿勢を必要とするクリエイティブクリアランスパイプライン（レジストリクロールからの差別化要因）。
- すべて 4 つ — 完全カバレッジ。多くのメンバー構成をサーブする AAO ホストエージェントに推奨。
supported_claim_types をチェックしそれに応じてルーティングします。サポートされないタイプはクリーンに UNSUPPORTED_CLAIM_TYPE を返します。
認可階層
クレームタイプごとの公開/認可分割:
キュー位置、内部チケット状態、チームルーティングは決して露出されません。
クレームタイプごとのリクエストとレスポンス形状
レスポンスのdetails フィールドは claim_type によって変わります。以下: リクエストペイロードと各クレームタイプが返す型付き details フィールド。
claim_type: "subsidiary"
ハウス側: 消費者が converse.com が house_domain: nikeinc.com を主張するのを検出。Nike のエージェントに尋ねる:
owned、pending_review、transferring、disputed、not_ours、archived、unknown。（licensed_in / licensed_out は適用されない — 子会社はライセンスされない。ブランドと商標がされる。）archived は、ブランドがかつてこの子会社を保持していた（例: 分離された事業単位）がもはやしないことを意味 — not_ours（決して所有しない）と区別。
リクエスト claim フィールド:
レスポンス
details フィールド:
claim_type: "parent" (leaf-side mirror)
リーフ側: 消費者がその親についてのリーフの権威的な答えを望む。Converse のエージェントに尋ねる:
subsidiary と同じ（ミラー）。
リクエスト claim フィールド:
レスポンス
details フィールド:
claim_type: "subsidiary"（ハウス上）AND claim_type: "parent"（リーフ上）の両方の verify_brand_claim が同じ関係について owned を返すとき、相互主張がエージェント層で確立 — 静的ファイルクロール不要。これは信頼拡張の最もクリーンなパスです。
claim_type: "property"
リクエストは 1 つのプロパティについて尋ねます。レスポンスは、関係が適用されるすべてのリージョン（クエリで名指しされたものを超えるかも）を含む、そのプロパティとのブランドの関係を記述します。
owned、transferring、disputed、not_ours、archived、unknown。（pending_review はプロパティには珍しい。飛行中の所有権変更には transferring を使う。）archived は、ブランドがかつてこのプロパティを運用していた（例: 売却されたドメイン）がもはやしないことを意味。
リクエスト claim フィールド:
レスポンス
details フィールド:
claim_type: "trademark"
licensed_in 相互性。 消費者は、名指しされた licensor_domain のブランドエージェントが同じマークについて licensed_out を相互にするまで、licensed_in を 未検証 として扱うべきです（SHOULD）（所有権と同じ相互主張形状、ただしライセンシングエッジ全体で）。相互性なしでは、ブランドが存在しないライセンス関係を一方的に主張しうる。
ブランドは拒否もできる — 拒否方向は単一の署名付きレスポンスで権威的:
owned、licensed_in、licensed_out、transferring、disputed、not_ours、archived、unknown。（pending_review は珍しい — 商標登録は任意の時点で確定的な所有権を持つ公開記録イベント。）archived は、ブランドがかつてこのマークを保持していた（期限切れ、キャンセル、別の当事者に移転）がもはやしないことを意味。
details フィールド:
Trust model
エージェントのレスポンスはブランドのadcp_use: "response-signing" JWK の下で署名されます。これはペイロードエンベロープ JWS です — 署名はレスポンスボディ内に存在し、RFC 9421 §2.2.9 トランスポートレスポンス署名（AdCP 3.x は定義しない）と区別されます。verify_brand_claim は仕様の 指定タスクレスポンス署名リスト にあります。そのリスト外のタスクでのレスポンス署名は禁止されます。
署名は、エンベロープの iat/exp ウィンドウ中にブランドの公開鍵の下でレスポンスペイロードの著作を証明します。それは否認防止レシートではなく、下の方向非対称セマンティクスを超えてブランドを主張に拘束しません。必須の signed_response エンベロープは、レスポンスを指定タスク、解決された brand_domain、応答する agent_url、呼び出し元アイデンティティ、リクエストペイロード、鮮度ウィンドウにバインドします。署名に依存する検証者は、エンベロープを response-payload-jws-envelope.json に対して検証しなければならず（MUST）、オンライン決定のため期限切れエンベロープを拒否し、署名されていないタスクボディフィールドと signed_response.payload.response 間の任意の不一致を拒否しなければなりません。
信頼モデルは 方向非対称 です:
- 拒否方向（エージェントが
disputed/not_oursと言う）は権威的。ブランドは一方的に関連を拒否できる。相互性不要。 - 主張方向（エージェントが
owned/pending_review/transferring/licensed_*と言う）は情報的だがそれ自体では信頼拡張ではない。相互する側が信頼拡張前に依然として確認しなければならない。
claim_type: "subsidiary" と claim_type: "parent" 経由）、相互主張がエージェント層で確立 されます。片側のみがエージェントを持つとき、brand.json § 相互主張信頼モデル に従いクロールベースの相互主張推論にフォールバックします。
完全な信頼テーブルと悪意あるハウスのウォークスルーについては brand.json § エージェント拡張検証 を参照してください。
キャッシング
ステータスごと:owned/not_ours/disputed— 安定。24-72h。pending_review— 変動的。Max-age ≤1h。transferring— 遷移まで変動的。Max-age ≤4h。licensed_in/licensed_out— 中程度に変動的。24h。use_case_authorization— 最も変動的。セッションごとに再チェック。unknown— 短いキャッシュ（≤1h）。
Cache-Control: max-age=N を設定すべきです（SHOULD）。消費者は下方にオーバーライドしてもよい（MAY）が、エージェント供給の max-age を超えるべきでありません（SHOULD NOT）。
エージェントは signed_response.payload.exp を Cache-Control: max-age が含意する HTTP 鮮度寿命より遅くない時に設定すべきです（SHOULD）。オンライン決定に署名付きレスポンスを使う消費者は、HTTP キャッシュ期限切れと署名付き exp のうち早い方を使わなければなりません（MUST）。その時点の後、エンベロープは新鮮な認可シグナルではなく監査証拠のみのままです。