> ## Documentation Index > Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # S7: ブランドアイデンティティと検証 > AdCP スペシャリストモジュール S7: Brand Protocol の習熟。brand.json アイデンティティ解決、分散パブリッシングと相互アサーション相互性、双方向 adagents.json 確認、verify_brand_claim 署名レスポンス検証、商標曖昧性解消、実験的な権利ライフサイクル。 # S7: ブランドアイデンティティと検証 **メンバー限定** — Practitioner 資格が必要。Addie と約 60 分。ハンズオンラボとアダプティブ試験を組み合わせます。 このスペシャリストモジュールは、Brand Protocol のアイデンティティと検証レイヤーの習熟をテストします。サンドボックスエージェントと協働してブランドの `brand.json` を解決し、`brand.json` と `adagents.json` にまたがる双方向トラストチェーンをウォークし、`verify_brand_claim` を呼んでその署名レスポンスをトラストのために解釈し、複数の法域にわたって商標を曖昧性解消します。Addie はあなたのハンズオン作業とプロトコルのトラストモデルについて推論する能力の両方を評価します。 合格すると **AdCP specialist — Brand** 資格を獲得します。 **これはブランド資格で、暗号の資格ではありません。** それはブランドドメインの *判断* を証明します — アイデンティティの解決、組織階層の読み取り、誰がブランドのために行動できるか知ること、トラストモデルの適用、検証結果が何を *意味する* か決めること。**ハイパー技術的ではありません**: 署名レスポンスが現れる場所では、ゲートは「有効 / 期限切れ / 偽造された署名が何を教えるか、そしてそれについて何をするか」であり — 暗号を実装することではありません。署名メカニクス（キー解決、正規化、署名チェック）は **[S6: セキュリティ](/docs/learning/specialist/security)** のセキュリティスペシャリストスキルで、関連する場所で相互参照されます。 **このドメインは 2 速で、このモジュールもそうです。** アイデンティティと検証の表面 — `brand.json` 解決、分散セルフパブリッシング、`verify_brand_claim` 署名レスポンス、`adagents.json` 確認 — は成熟しており、この資格が **ゲートする** ものです。**権利ライフサイクル**（`get_rights` / `acquire_rights` / `update_rights`）は `brand.rights_lifecycle` フィーチャークラスターに属し、[実験的ステータス](/docs/reference/experimental-status) で **実験的** とマークされています。あなたはそれをウォークすることを学びますが、その習熟は **教えられ、評価されません** — それに依存するゲートされた基準はありません。 ## このトラックが検証を準備する専門分野 以下の `specialisms` は `brand` ドメインに該当します。それぞれ独自のコンプライアンスストーリーボードを持ちます — 完全な分類については [コンプライアンスカタログ](/docs/building/verification/compliance-catalog) を参照。 | Specialism | Status | カバーするもの | | -------------- | ------ | ---------------------------------------------------------------- | | `brand-rights` | stable | ブランドアイデンティティ解決（`get_brand_identity`）と権利ライセンシング（タレント、音楽、ストックメディア） | `brand-rights` 専門分野ストーリーボードは stable ですが、**実験的** とマークされた `brand.rights_lifecycle` フィーチャークラスター（`get_rights`、`acquire_rights`、`update_rights`）を実行します — 部分的権利、サブライセンス、失効、紛争解決は進化することが予想されます。このモジュールはドメインのアイデンティティと検証の半分をゲートします; 権利ライフサイクルは実験的として教えます。 ## 組織階層: 属性だけではない ブランドアイデンティティは **組織が誰であり誰がそれのために行動できるか** を、2 つの異なる軸に沿ってエンコードします — そしてこのモジュールは属性（色、トーン、ロゴ）だけでなく両方をゲートします: * **軸 1 — ブランド対ブランド（ハウス階層）。** どのブランドがハウスに属するか: `house_of_brands` 対 `branded_house` アーキテクチャ、`keller_type`（`master` / `endorsed` / `independent`）、`brand_refs[]` ↔ `house_domain` 相互性。 * **軸 2 — ブランド対オペレーター（誰がブランドの *ために* 行動するか）。** ハウスはその `brand.json` で `authorized_operators[]` を宣言します — そのブランドを代表することを許可されたエージェンシー、プラットフォーム、インハウスチームで、それぞれ `domain`、`brands[]`（または `*` ワイルドカード）、`countries`、`scopes[]`（`media_buying`、`creative_generation`、`rights_clearance`、`governance`、`measurement`、`agent_operations`）でスコープされます。 3 つの関係タイプを区別しておきます — 混同しやすいです: | Relationship | 宣言される場所 | 方向 | 答える質問 | | ------------ | --------------------------------------- | --------------------------- | ---------------------------- | | ハウスメンバーシップ | `brand_refs[]` ↔ `house_domain` | ブランド ↔ ブランド | どのブランドがこのハウスに属するか? | | オペレーター認可 | `brand.json` の `authorized_operators[]` | ブランド → オペレーター（**バイサイド**） | 誰がこのブランドの *ために* 購入 / 行動できるか? | | エージェント委任 | `adagents.json` の `authorized_agents[]` | パブリッシャー → エージェント（**セルサイド**） | 誰がこのパブリッシャーの在庫を *売れる* か? | ランタイムでオペレーター軸は **Accounts Protocol** で表面化します: すべてのアクションは自然キーが `{brand, operator}` である `account` を運びます（`operator` はアカウントを運用するエンティティのドメインで; ブランドが直接運用するときはブランド自身のドメインに等しい）。セラーの `require_operator_auth` ケイパビリティが参照形状を選択します — `true` ⇒ 独立したオペレーター認証を持つセラー割り当ての `account_id` 名前空間; `false` ⇒ `sync_accounts` 経由のバイヤー宣言 `{brand, operator}` ペア。`get_brand_identity` の **authorized** ティアは、まさにアイデンティティのオペレーター（リンクされたアカウント）ビューです。 ## あなたが知れること — そして知れないこと この資格の知的中核は **トラストフレームワーク** です: ブランドアイデンティティの認識論。ここでの暗号は *誰かが何かを言った* ことを証明し、*それが真実かどうか* ではありません。トラストはクリーンに分離する 2 つのレイヤーで解決します: * **アイデンティティ属性**（ロゴ、色、トーン、タグライン） — 単一の TLS でサーブされる `brand.json` から信頼されます。自身のドメインを制御するブランドは、自身の属性について権威的です、以上 — 親関係が相互化されていなくても。（「主張されたが未検証 ⇒ リーフを完全に無視」は **間違い** です: リーフのアイデンティティは依然として本物です。） * **関係**（誰がブランドを所有するか、誰がそれのために話せるか） — **両方の** 側が相互化するときのみ信頼されます。 次に *各シグナルが実際に何を証明するか* のはしごを登ります: | Signal | 証明するもの | 証明 **しない** もの | | --------------------------- | ------------------------------------------ | ---------------------------------------------------- | | TLS + ドメイン制御 | この当事者がこのドメインを制御する | それがあなたが期待する現実世界のエンティティであること | | `signed_response`（JWS） | この当事者が `iat`/`exp` 内で公開キーの下でこの回答を **作成した** | 回答が **真実** であること（そしてそれは否認防止レシートではない） | | 相互アサーション（両側 `owned`） | 2 つの当事者が **合意する**（一貫性） | 現実世界の **地位** — 2 つの攻撃者制御ドメインが両方とも一致する `owned` に署名できる | | 拒否（`not_ours` / `disputed`） | 単一の署名レスポンスについて権威的 | —（ブランドは常に関連を拒否できる） | **プロトコルがあなたのために確立できないもの** — そしてあなたが代わりにどこへ行かなければならないか: * **現実世界の法的地位** → あなたが期待する法的エンティティに対する消費者側ドメイン制御 + TLS; 高信頼決定のための帯域外アイデンティティ。（これは *検証済みアイデンティティ証明* が存在する場所です — **別の、実験的** フィーチャーで、この資格の範囲外。） * **商標の実際の登録** → 公開 **レジストリ** レコードをクロスチェック（エージェントは `matched_registration` を主張するだけ）。 * **プロパティクレーム** → **DNS/TLS** をクロスチェック。 * **`licensed_in`** → 名指されたライセンサーが **`licensed_out`** を相互化するまで未検証。 * **保留された内部状態**（キュー位置、チケット状態、チームルーティング） → 決して露出されない; それを推論しない。 * **`exp` を過ぎた鮮度** → 期限切れのエンベロープは監査証拠で、新鮮な認可シグナルではない。 避けるべき 2 つの罠: `managed_by` は **ディレクトリ** フィールドで、決してトラスト / 認可シグナルではない; そしてスタンドアロンリーフの沈黙は、それを主張する任意のサードパーティハウスに **勝る**。 ## ブランドアイデンティティがクリエイティブ生成をどう駆動するか ブランドアイデンティティは装飾ではありません — それはオンブランド生成への **入力** で、それが authorized ティアが存在する *理由* です。クリエイティブエージェントは `brand.json` をフェッチ（または `get_brand_identity` authorized を呼び）、次にワードマークを引き出し、正確なパレットとタイプスケールを適用し、トーンオブボイスを採用し、制限に従います — `visual_guidelines` が食品画像の上のテキストを禁止するので、見出しを画像の *下* に置いたフードフォワードなコンポジションを生成します。推測なし、修正なし。2 つのロールを分離します: * ジェネレーターが消費する **入力**: `logos`、`colors`、`fonts`、`tone.voice`、`voice_synthesis`（provider / voice\_id / settings）。 * それが生成してよいものを束縛する **制約**: `tone.dos` / `tone.donts`、`visual_guidelines.restrictions`（例: 「アスリートの上に決してテキストを置かない」）、`content_restrictions`。 入力品質が出力品質を駆動します — よりリッチな `brand.json` はより少ない修正でより良い生成を生みます。これらはまさに `get_brand_identity` が認可の背後にゲートするフィールドです、ブランドが生成入力を保護するから。 **2 番目の、実験的** パスは、ライセンスされたタレントの肖像や声で生成するとき（`brand.rights_lifecycle`）に適用されます: `acquire_rights` が、特定のプロバイダー（肖像には Midjourney、声には ElevenLabs）が *生成時に* 検証する **スコープされた `generation_credentials`** を発行します — 権利エージェントが許可を設定し、プロバイダーがそれを強制します — `rights_constraint`（用途 / 国 / インプレッション上限）、必須の開示テキスト、生成されたアセットをレビューのためにブランドエージェントに戻す **`creative_approval`** ループとともに。インプレッション上限に達すると生成が停止します。 **範囲境界。** このモジュールはハンドオフのブランド *側* をカバーします — 入力 / 制約としてのアイデンティティ、そして権利 / 承認インターフェース。クリエイティブ自体の生成（`build_creative` マニフェスト / コードモード、フォーマット選択、プレビュー、同期）は **[S2: クリエイティブ](/docs/learning/specialist/creative)** と **[S5: Sponsored Intelligence / 生成広告](/docs/learning/specialist/sponsored-intelligence)** に属します — 相互参照され、ここで再教育されません。権利ゲートされた半分は教えられ、ゲートされません（それは実験的な権利ライフサイクルに乗ります）。 ## このモジュールでの stable 対 experimental | Surface | Maturity | この資格で | | ------------------------------------------------------------------------------------------------------- | ------------ | ------------------------------- | | `brand.json` アイデンティティ解決 + public/authorized フィールドティア | stable | **ゲート** | | 分散パブリッシング + 相互アサーション相互性（`brand_refs[]` ↔ `house_domain`） | stable | **ゲート** | | オペレーター認可（`authorized_operators[]`: domain / brands / countries / scopes）+ アカウント `{brand, operator}` モデル | stable | **ゲート** | | 双方向 `adagents.json` 確認（委任された権限、署名キー `kid`） | stable | **ゲート** | | `verify_brand_claim` / `verify_brand_claims` — トラストのための署名レスポンスの解釈 | stable (3.1) | **ゲート**（署名 *メカニクス* は S6 セキュリティ） | | 方向非対称トラスト + 商標曖昧性解消 | stable | **ゲート** | | トラストフレームワーク / 知り得性（作成≠真実、一貫性≠地位、2 つのレイヤー、必須のクロスチェック） | stable | **ゲート** | | クリエイティブ生成入力 / 制約としてのブランドアイデンティティ（authorized ティアフィールド） | stable | **ゲート** | | 権利ゲートされた生成（`generation_credentials`、開示、インプレッション上限、`creative_approval` ループ） | experimental | 教えられる、ゲートされない | | クリエイティブプロダクション（`build_creative`、フォーマット、マニフェスト） | — | 範囲外 → S2 / S5 | | 権利ライフサイクル（`get_rights` / `acquire_rights` / `update_rights`、`brand.rights_lifecycle`） | experimental | 教えられる、ゲートされない | ## あなたがデモンストレーションすること * ブランドのアイデンティティを、静的な `brand.json` と `get_brand_identity` エージェントタスクの両方から解決; `available_fields` を読んで未認可の呼び出し元が何を欠いているか検出し、次に `authorized=true` を再リクエストしてゲートされた `colors` / `fonts` / `tone` / `voice` / `rights` セクションを取得 * ブランド階層関係が本物であることを **両方の** 方向をチェックして確立 — 親ハウスの `brand_refs[]` とサブブランドの `house_domain` バックポインター — し、なぜ片側のアサーションがトラストを拡張しないか説明 * ハウスの `authorized_operators[]` を解決し、与えられたオペレーター（エージェンシー、プラットフォーム、インハウスチーム）が特定のブランドのために行動できるか判定 — `domain`、`brands[]`（`*` ワイルドカード含む）、`countries`、`scopes[]` をチェック — し、このバイサイドオペレーター軸をハウスメンバーシップとセルサイドエージェント委任から区別; `require_operator_auth` が `{brand, operator}` 対 `account_id` 参照形状をどう選択するか推論 * 委任された販売エージェントを双方向に確認: パブリッシャーの `adagents.json` がそれを認可 *かつ* エージェントが自身の `brand.json` で自己宣言（どちらも単独では不十分）; なぜエージェントの署名キーをピンするパブリッシャーがエージェントの署名レスポンスのトラスト権威になるか（侵害されたエージェントが自身のキーにスワップできないように）理解し、パブリッシャーがリストしないエージェントを拒否 *（署名チェックのメカニクスは S6 セキュリティ）* * 署名された `verify_brand_claim` レスポンスをトラストのために **解釈** — 有効な署名はブランドが回答を *作成した* ことを証明（真実であること、否認防止ではない）、期限切れのものは監査のみ、検証に失敗するか署名された内容が一致しないレスポンスは拒否されなければならず、未署名 / 未検証の回答や `verification_status` フィールド単独は決してトラストを拡張しない *（署名がどう検証されるかは S6 セキュリティスキル — ここでは各結果が何を意味するか推論）* * **方向非対称トラストルール** を適用: 単一の `owned` / `pending_review` / `licensed_in` アサーションを、他の側が相互化するまで有益だがトラストを拡張しないものとして扱い、`not_ours` / `disputed` を単一の署名レスポンスについて権威的として扱う * レジストリと Nice クラスにわたって商標クレームを曖昧性解消: あるレジストリで `owned` だが別で `disputed` または `licensed_in` であるマークを解決し、`AMBIGUOUS_MATCH` を絞り、間違った登録に対してクリエイティブをクリアすることを回避 * ブランドの解決されたアイデンティティを **クリエイティブ生成** にマップ: どのフィールド（`logos`、`colors`、`fonts`、`tone.voice`、`voice_synthesis`）がジェネレーターが消費する *入力* か、どれ（`tone.donts`、`visual_guidelines.restrictions`、`content_restrictions`）がハードな *制約* か; なぜこれらが認可ゲートされたフィールドか説明し、ブランド / プロダクション境界（`build_creative` と実験的な権利ゲートされた `generation_credentials` + `creative_approval` ループが引き継ぐ場所）を特定 * **トラストフレームワークの知り得性境界** について推論: アイデンティティレイヤー（TLS 検証可能）を関係レイヤー（相互アサーションゲート）から分離; なぜ署名が *真実ではなく作成* を証明し相互アサーションが *地位ではなく一貫性* を証明するか説明; そしてブランドについての任意の事実について、プロトコルが確立できるもの、できないもの、ギャップを閉じる外部クロスチェック（レジストリ、DNS/TLS、ライセンサー相互化、消費者側地位）を名指す * 実験的な権利ライフサイクル（`get_rights` → `acquire_rights` → `update_rights`）をウォークし、権利支出ガバナンスについて推論 — 表面をまだ安定していないと正しくフラグしながら ## 前提読書 ブランドドメイン: アイデンティティ、分散パブリッシング、階層、検証、権利。 セルフパブリッシュされたアイデンティティドキュメント — ハウスアーキテクチャ、`brand_refs[]`、エージェント、相互アサーショントラストモデル。 4 つのクレームタイプ、署名レスポンスエンベロープ、方向非対称トラストルール。 2 つのトラストレイヤー、相互化テーブル、なぜ一貫性が地位でないか — 知り得性フレームワーク。 双方向 `adagents.json` + `brand.json` トラストチェーン — Northwind / StreamHaus / Sportshaus Holdings。 ランタイムのオペレーター軸: `authorized_operators`、`{brand, operator}` アカウントモデル、`require_operator_auth`、課金。 クリエイティブエージェントがどう `brand.json` アセット、トーン、制限を引き出してオンブランドを生成するか — そして権利ゲートされた `generation_credentials` パス。 `get_brand_identity`、`verify_brand_claim`、レスポンス署名キーの実装。 なぜ `brand.rights_lifecycle` が実験的か、それが採用者にとって何を意味するか。 ## テストエージェントへの接続 ラボ演習は公開テストエージェントのブランドテナントに対して実行します。共有トークンを使います — サインアップ不要: ```bash theme={null} export ADCP_AUTH_TOKEN="1v8tAhASaUYYp4odoQ1PnMpdqNaMiTrCRqYo9OJp6IQ" export AGENT_URL="https://test-agent.adcontextprotocol.org/brand/mcp" ``` ディスカバリーとウォークスルーのドキュメントはホストルートでサーブされます: * `https://test-agent.adcontextprotocol.org/.well-known/brand.json` — エージェント自身のアイデンティティドキュメント * `https://test-agent.adcontextprotocol.org/.well-known/adagents.json` — 販売認可 * `https://test-agent.adcontextprotocol.org/.well-known/jwks.json` — 署名キー（`response-signing` キーを含む） * `…/fixtures/walkthrough/northwind/.well-known/brand.json` — 委任されたエージェンシーのアイデンティティ * `…/fixtures/walkthrough/streamhaus/.well-known/brand.json` と `…/fixtures/walkthrough/streamhaus/.well-known/adagents.json` — サブブランドパブリッシャーのアイデンティティと販売認可（`adagents.json` フィクスチャをサーブする唯一のロール） * `…/fixtures/walkthrough/sportshaus-holdings/.well-known/brand.json` — 親ハウスのアイデンティティ、`brand_refs[]` **と** `authorized_operators[]` 付き（ポートフォリオ全体のエージェンシーとブランドスコープの US のみのインハウスオペレーター） これらは [セラー検証ウォークスルー](/docs/verification/overview) のマルチティアトラストチェーンフィクスチャです。 最初の呼び出しのウォークスルーについては [クイックスタート](/docs/quickstart) を参照。 ## ラボ演習 1. **ブランドアイデンティティの解決** — 認可なしでサンドボックスブランドの `get_brand_identity` を呼び、`available_fields` を読んでどのセクションがゲートされているか見る。`authorized=true` で再度呼び、`colors`、`fonts`、`tone`、`rights` セクションが現れることを確認。なぜブランドがこれらのフィールドをリンクされたアカウントの背後にゲートするか説明。 2. **アイデンティティ → クリエイティブ生成** — タレントブランド（例: `daan_janssen`）で、`authorized=true` で `get_brand_identity` を呼び、`colors`、`fonts`、`tone`（`dos` / `donts`）、`voice_synthesis`、`visual_guidelines.restrictions` を読む。各フィールドをクリエイティブエージェントが消費する生成 **入力** か出力を束縛するハードな **制約** かに分類し、ジェネレーターが従うオンブランドブリーフを書く。なぜこれらがまさに認可ゲートされたフィールドか説明し、`build_creative`（S2/S5）と実験的な権利ゲートされた `generation_credentials` + `creative_approval` ループが引き継ぐ場所を指す。 3. **分散パブリッシング相互性** — Sportshaus Holdings の `brand.json` をフェッチしその `brand_refs[]` を読む。StreamHaus の `brand.json` をフェッチしその `house_domain` を読む。関係が **両方の** 方向でアサートされることを確認。1 つの方向だけがチェックされた場合に悪意あるハウスが何を主張できるか説明。 4. **オペレーター認可** — Sportshaus Holdings の `brand.json` で `authorized_operators[]` を読む。`meridian-agency.example` が `streamhaus` のために購入できること（`brands: ["*"]` を持つ）、`courtside-inhouse.example` が **できない** こと（`brands: ["courtsidehq"]`、`countries: ["US"]` にスコープされている）を確認。このバイサイドオペレーター軸がハウスメンバーシップ（`brand_refs[]`）とセルサイドエージェント委任（`adagents.json`）とどう異なるか、`require_operator_auth` が `{brand, operator}` 自然キーとセラー割り当ての `account_id` のどちらを渡すか決めるかを説明。 5. **双方向 adagents.json 確認** — StreamHaus の `adagents.json` をフェッチし Northwind Media を認可するエントリーを見つける; `delegation_type: "delegated"` を確認。Northwind の `brand.json` をフェッチし同じ販売エージェントを宣言することを確認 — パブリッシャーがそれを認可 *かつ* エージェントが自己宣言、どちらも単独では不十分。なぜエージェントの署名キーをピンするパブリッシャーがそのエージェントの署名レスポンスのトラスト権威になるか（侵害されたエージェントが自身のキーにスワップできないように）、なぜパブリッシャーがリストしないエージェントが失敗するか説明。*（署名チェックのメカニクスは S6 セキュリティ。）* 6. **verify\_brand\_claim — 署名された回答を解釈** — `streamhaus.example` について `claim_type: "subsidiary"` で `verify_brand_claim` を呼び、回答を **解釈**: それはブランドによって署名されているので、有効な署名はブランドが *それを作成した* ことを証明 — 真実であることではない; 期限切れの署名は監査のみ; 検証に失敗するか署名された内容が一致しないレスポンスは拒否されなければならない; `verification_status` フィールド単独を決して信頼しない。*（暗号検証の実行は S6 セキュリティスキル — ここでは各結果がトラストにとって何を意味するか推論。）* 次に `claim_type: "parent"` でリーフ側のミラーを検証し、相互アサーションがエージェントレイヤーで完了することを確認。 7. **方向非対称トラスト** — 無関係なプロパティについて `verify_brand_claim` を呼び `not_ours` を観測。なぜこの拒否が単一の署名レスポンスについて権威的で、`owned` または `licensed_in` の回答がそうでないか — そして `licensed_in` がどの相互化ステップを要求するか説明。 8. **商標曖昧性解消** — 同じマークについて 2 つの異なるレジストリの下で `claim_type: "trademark"` で `verify_brand_claim` を呼び、異なるステータス（`owned` 対 `licensed_in`）を観測。レジストリなしで一度呼び `AMBIGUOUS_MATCH` を観測。`registry`、`countries`、`nice_classes` がどう曖昧性を解決するか、なぜこれがクリエイティブクリアランスにとって重要か説明。 9. **トラスト境界 — 知れないこと** — エージェントが `courtsidehq` サブシディアリークレームに `owned` で署名し、Sportshaus Holdings が `brand_refs[]` に `courtsidehq` をリスト — しかし `courtsidehq` ドキュメントが相互化しない。なぜ署名された `owned` が *真実ではなく作成* を証明するか、なぜこのハウスのみのエッジが `courtsidehq` のアイデンティティ（それが 1 つを公開したなら）が依然として本物であっても関係レイヤーで **未検証** か説明。次に `sportshaus-holdings.example` があなたが思う *本物の* 組織であると信頼するためにあなたがまだ必要とするもの — そしてなぜ署名も相互アサーションもそれを与えられないか述べる。 10. **権利ライフサイクル（実験的）** — `get_rights` を使ってタレントオファリングを発見し、`acquire_rights` → `update_rights` ライフサイクル、スコープされた `generation_credentials` と `creative_approval` ループ、権利支出ガバナンスについて推論。この表面を実験的（`brand.rights_lifecycle`）として識別し、それが本番採用にとって何を意味するか説明。*資格ゲートとして評価されない。* ## 評価 | Dimension | Weight | Addie が評価するもの | | ----------------- | ------ | ------------------------------------------------------------------------------------------------------------------- | | アイデンティティ解決 & 生成入力 | 20% | public/authorized フィールド分割を解決 *かつ* フィールドをクリエイティブ生成入力と制約としての役割にマップできるか? | | トラストチェーン検証 | 25% | 3 つの軸すべて — `brand_refs[]`/`house_domain` 相互性、`authorized_operators[]`、`adagents.json` 委任 — をウォークできるか? | | クレーム検証 | 25% | 署名レスポンスをトラストのために *解釈*（作成≠真実、期限切れ=監査のみ、不一致で拒否、ステータスフィールド単独を決して信頼しない）し、商標を曖昧性解消できるか? 署名メカニクスは S6 セキュリティで、ここではゲートされない。 | | トラストモデル推論 | 30% | 2 つのトラストレイヤーを分離し、作成≠真実と一貫性≠地位を説明し、プロトコルが確立できないもの + 各ギャップを閉じるクロスチェックを名指せるか? | 合格しきい値: 70%。