> ## 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.
# brand.json Specification
> AdCP の brand.json 仕様。ファイル形式、5 つのバリアント（ポートフォリオ、リダイレクト、エージェント、権威ある場所、ブランド正準ドキュメント）、ブランド定義フィールド、相互アサーション信頼モデル、ビジュアルガイドライン、カラーウェイ、タイプスケール、商標、解決アルゴリズム。
`brand.json` ファイルは、ブランドがアイデンティティを主張し、発見可能なブランド情報を確立するための標準的な手段を提供します。異なる公開モデルに対応するために 5 つのバリアントをサポートします。
`brand.json` はブランドアイデンティティデータの正準ソースです。ここで定義されるブランドオブジェクト（logos、colors、tone、tagline）は、AdCP 全体で使われる単一のブランド定義です。タスクはドメインと brand\_id でブランドを参照します — システムは `brand.json` または[レジストリ](/docs/registry/index)から完全なアイデンティティを解決します。
## Motivation
ホールドコのブランドアイデンティティは、親が所有する**1 つ**の brand.json に存在しうる — すべての子の変更が親のファイルの編集を必要とします。Converse がロゴを更新したいなら、誰かが Nike, Inc. のファイルを編集します。ホールドコが 100 の子会社ブランドを運営するなら、100 のすべてのチームが同じモノリシックなドキュメントに集約します。ブランドチームは自分のアイデンティティを所有しますが、モノリシックな形状はコーポレート親に単一の運用チョークポイントを強制します。それはまた独立ブランドがそもそも公開することをブロックします — 他人のポートフォリオにリストされたブランドは、ドメイン管理がそれを証明できる場合でも、自身の正準データを主張するプロトコルレベルのパスを持ちません。
仕様は、ハウスが家族に誰がいるかの権威であり続けながら、子ブランドが**自身の**正準ドキュメントを公開できるようにすることでこれを解決します。インライン `brands[]` は一級のオプションのままです（親がデータを所有）。`brand_refs[]` は、正準ドキュメントが別の場所に存在するポインター子を追加します（子がデータを所有）。ハウスは自由に混合します。階層は 1 レベルの深さです — ハウスのみが所有権を宣言し、ブランド自体は子を持てません。
## File location
ブランドは `brand.json` ファイルを次の場所にホストします。
```
https://example.com/.well-known/brand.json
```
[RFC 8615](https://datatracker.ietf.org/doc/html/rfc8615) の well-known URI 慣例に従います。
## Variants
brand.json ファイルは 5 つのバリアントをサポートします。
| # | Variant | Use when |
| - | ------------------------------- | --------------------------------------------------- |
| 1 | Authoritative Location Redirect | 正準ドキュメントが別の URL にホストされている |
| 2 | House Redirect | ブランドドメインがより大きなハウスにロールアップする |
| 3 | Brand Agent | MCP エージェントが権威あるブランドアイデンティティを提供する |
| 4 | House Portfolio | ハウスがブランドを公開する（インライン、ポインター、または両方） |
| 5 | Brand Canonical Document | ブランドが自身のアイデンティティを自己公開する（任意の `house_domain` ポインター付き） |
バリアント 1〜3 は互いに、およびバリアント 4〜5 と相互排他的です。バリアント 4 と 5 は合成します: House Portfolio（4）は `brand_refs[]` を通じて Brand Canonical Document（5）を参照でき、Brand Canonical Document は `house_domain` を通じてハウスを指し返せます。2 つの半分がどう解決するかについては [Mutual-assertion trust model](#mutual-assertion-trust-model) を参照。
### 1. Authoritative Location Redirect
別の URL にホストされた brand.json を指します。
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"authoritative_location": "https://adcontextprotocol.org/brand/abc123/brand.json"
}
```
次の場合に使います。
* brand.json が中央でホストされている（例: サービスプロバイダーによって）
* CDN 配信が必要
* マネージドブランドサービス
任意フィールド（House Redirect と共有 — [Redirect ergonomics](#redirect-ergonomics) を参照）:
* `redirect_reason`: キャッシュ処理のための構造化シグナル（`acquisition`、`rebrand`、`regional`、`legacy`、`consolidation`、`other`）
* `redirect_effective_at`: リダイレクトが有効になった ISO タイムスタンプ
* `note`: 自由テキストの根拠
### 2. House Redirect
完全なブランドポートフォリオを含むハウスドメインを指します。
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"house": "nikeinc.com",
"note": "Regional site - see house for brand portfolio"
}
```
任意フィールド:
* `region`: ISO 3166-1 alpha-2 国コード（例: "CN"）
* `redirect_reason`: キャッシュ処理のための構造化シグナル（[Redirect ergonomics](#redirect-ergonomics) を参照）
* `redirect_effective_at`: リダイレクトが有効になった ISO タイムスタンプ
* `note`: 自由テキストの根拠
次の場合に使います。
* ブランドドメインがより大きなハウスに所有されている
* 地域/ローカライズドメインがメインハウスを指す
* レガシードメインが正準にリダイレクトする
### Redirect ergonomics
両方のリダイレクトバリアントは、コンシューマーが古いキャッシュ状態に留まることなくリダイレクト遷移を処理できるよう、任意の `redirect_reason` と `redirect_effective_at` を受け入れます。
`redirect_reason` は enum です。
| Value | Meaning | Caching guidance |
| --------------- | --------------------------------------- | ------------------------------------ |
| `acquisition` | 所有エンティティが買収された（例: 1 つのホールドコが別のホールドコを購入） | 安定するまでキャッシュ TTL を短縮。多くのフィールドが移動する可能性 |
| `divestiture` | 所有エンティティがスピンアウトまたは売却された | 安定するまでキャッシュ TTL を短縮。新しい所有チェーン |
| `rebrand` | ブランドまたはハウスが改名/再ポジショニング | 安定するまでキャッシュ TTL を短縮 |
| `consolidation` | サブブランドがターゲットに統合された | 安定するまでキャッシュ TTL を短縮 |
| `regional` | 地域/ローカライズドメインがメインハウスを指す | 安定。標準キャッシュ |
| `legacy` | 正準にリダイレクトする古いドメイン | 安定。標準キャッシュ |
| `other` | 上記でカバーされない理由 | 自由テキストの根拠は `note` に属する |
`redirect_effective_at`（ISO 8601 タイムスタンプ）はハードなキャッシュ不変条件です: キャッシュは、このタイムスタンプより前にキャッシュされた任意のエントリを古いものとして扱い、リダイレクトを通じて再取得しなければなりません（**MUST**）。上記の TTL 短縮ガイダンスは SHOULD です。このタイムスタンプは MUST であり、M\&A や他の遷移中のキャッシュポイズニングに対する負荷を担う修正です。
これは、IAB Tech Lab の [ads.txt](https://iabtechlab.com/ads-txt/)（`OWNERDOMAIN`）と [sellers.json](https://iabtechlab.com/sellers-json/)（`seller_type`）の移行パターンに対する brand.json の類似物です。それらは歴史的に帯域外の調整に依存していました — 機械可読な遷移シグナルはありませんでした。`redirect_reason` + `redirect_effective_at` が brand.json についてそのギャップを閉じます。
例 — 買収リダイレクト:
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"house": "wpp.com",
"redirect_reason": "acquisition",
"redirect_effective_at": "2026-04-15T00:00:00Z",
"note": "Acquired by WPP April 2026"
}
```
### 3. Brand Agent
ブランド情報を提供する MCP エージェントを指定します。
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"brand_agent": {
"url": "https://agent.acme.com/mcp",
"id": "acme_brand_agent"
}
}
```
任意フィールド:
* `contact`: 連絡先情報
ブランドがエージェントを持つ場合、エージェントがブランドアイデンティティデータの権威あるソースです。
### 4. House Portfolio
ハウスがブランドを公開します。ハウスは、インラインの子定義、自己公開するブランドへのポインター参照、または両方を運べます。
* **`brands[]`** — インラインの子定義。**親がデータを所有。** 独自のドメインを持たないサブブランド（Nike SB、内部プロダクトライン）や、ホールドコが中央で管理したいサブブランドに最適。
* **`brand_refs[]`** — ポインターエントリ。**子が**自身の正準ドキュメント（バリアント 5）で**データを所有。** 自己公開権限を望む独自ドメインを持つサブブランド（Converse、Jordan）に最適。
特定の子は 2 つの配列の**正確に 1 つ**に現れます。`brands[]` または `brand_refs[]` の少なくとも 1 つが存在しなければなりません。
**シンプルなハウス（インラインのみ）:**
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"house": {
"domain": "nikeinc.com",
"name": "Nike, Inc.",
"architecture": "hybrid"
},
"brands": [
{
"id": "nike",
"names": [{"en": "Nike"}],
"keller_type": "master",
"properties": [
{"type": "website", "identifier": "nike.com", "primary": true}
]
}
]
}
```
**混合ハイブリッド（インライン + ポインター）:**
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"house": {
"domain": "nikeinc.com",
"name": "Nike, Inc.",
"architecture": "hybrid"
},
"brands": [
{
"id": "nike_sb",
"names": [{"en_US": "Nike SB"}],
"keller_type": "sub_brand"
}
],
"brand_refs": [
{ "domain": "converse.com", "brand_id": "converse" },
{ "domain": "jordan.com", "brand_id": "jordan" }
]
}
```
`brand_refs[]` エントリの形状:
| Field | Required | Meaning |
| -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `domain` | yes | 子の正準 brand.json が存在する場所。`brand_refs[]` 内で一意でなければなりません。 |
| `brand_id` | yes | ハウスのポートフォリオ内でのこのブランドの安定した識別子。`brand_refs[]` 内で一意で、`brands[]` にも現れてはなりません（MUST NOT）。 |
| `managed_by` | no | このブランドを運用的に管理するエンティティのドメイン（例: ホールドコ内のエージェンシーネットワーク）。ハウスが宣言。**コンシューマーは信頼や認可の決定に使ってはなりません（MUST NOT）。** ハウス横断の集計（「BBH が管理するすべてを表示」）が意図された用途です — これは信頼フィールドではなくディレクトリフィールドです。 |
| `effective_at` | no | ハウスがこの所有権クレームを確立した ISO 8601 タイムスタンプ。コンシューマーはこの日付から相互アサーションのエッジをエイジングします。省略すると、コンシューマーは自身の最初の観察からエイジングします。 |
このエントリと子の `house_domain` クレームの関係についての信頼セマンティクスは、下記 [Mutual-assertion trust model](#mutual-assertion-trust-model) で定義されます。
**委任を伴うハウス（WPP）:**
ホールドコはブランド管理をエージェンシーネットワークに委任します。WPP plc はブランドを所有しますが、Ogilvy や BBH が実際に日々運営します。`brand_refs[]` エントリの `managed_by` は、これを所有ハウスによる一方的な宣言として捕捉します。リーフブランドはマネージャーを参照しません。UI はエージェンシービューのために BBH Sport を BBH の下でレンダリングします。信頼検証は BBH Sport → WPP のみをたどります。
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"house": {
"domain": "wpp.com",
"name": "WPP plc"
},
"brand_refs": [
{ "domain": "bbh-sport.com", "brand_id": "bbh_sport", "managed_by": "bbh.com" },
{ "domain": "ogilvy-toyota.com", "brand_id": "ogilvy_toyota", "managed_by": "ogilvy.com" },
{ "domain": "wpp-direct.com", "brand_id": "wpp_direct" }
]
}
```
`managed_by` は**ディレクトリフィールドであり、信頼フィールドではありません。** コンシューマーが実際に日々運営する主体でブランドをグループ化できるように存在します — エージェンシーネットワーク横断でインベントリをショッピングするときにバイヤー側 DSP が望む正準ビューです。コンシューマーは信頼や認可の決定に使ってはなりません（MUST NOT）。その線は依然としてリーフとハウス間の相互アサーションを通じて流れます。[Conformance](#conformance) を参照。
### 5. Brand Canonical Document
ブランドが自身のアイデンティティ属性を所有する、ブランドごとの自己公開ドキュメント。ブランド自身の `/.well-known/brand.json`（または [authoritative location redirect](#1-authoritative-location-redirect) 経由）にホストされます。ブランドは `house_domain` を通じてハウスを宣言するか、単独で立つ（親ハウスなし — Patagonia、Liquid Death — フィールドを省略）ことができます。`house_domain` 関係の信頼セマンティクスは、下記 [Mutual-assertion trust model](#mutual-assertion-trust-model) で定義されます。
**ハウス付き — Nike 傘下の Converse:**
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"id": "converse",
"names": [{"en_US": "Converse"}],
"keller_type": "sub_brand",
"house_domain": "nikeinc.com",
"logos": [
{"url": "https://converse.com/logo.svg", "variant": "primary"}
],
"tagline": "Sneaker for the streets"
}
```
**スタンドアロン — Patagonia:**
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"id": "patagonia",
"names": [{"en_US": "Patagonia"}],
"keller_type": "independent",
"logos": [
{"url": "https://patagonia.com/logo.svg", "variant": "primary"}
],
"tagline": "We're in business to save our home planet."
}
```
ブランドが独自のドメインを持ち、そのアイデンティティ（logos、colors、tone、taglines）の自己公開権限を望む場合に使います。ブランドは `brands[]` のインラインエントリと同じアイデンティティフィールドを運びます。
**このバリアント固有のトップレベルフィールド:**
| Field | Type | Required | Description |
| ---------------------------------- | --------------- | -------- | ------------------------------------------------------------------------------------------------ |
| `id` | string | Yes | ブランド識別子（アンダースコア付きの小文字英数字） |
| `names` | array | Yes | ローカライズされた名前 |
| `house_domain` | string (domain) | No | このブランドが属するコーポレートハウスへのポインター。省略されるとブランドはスタンドアロンとして扱われます。シングルホップ — ブランド自体は `brand_refs[]` を宣言できません。 |
| `$schema`、`version`、`last_updated` | string | No | ドキュメントメタデータ |
**他のすべてのブランドアイデンティティフィールドが適用されます**（`logos`、`colors`、`fonts`、`tone`、`tagline`、`visual_guidelines`、`keller_type`、`parent_brand`、`properties[]`、`industries[]`、`target_audience`、`description`、`agents[]`、`contact`、`trademarks[]`、`data_subject_contestation` など — 完全なフィールドリストは [Brand definition](#brand-definition) を参照）。ドキュメントは、ハウス専用フィールド（`house`、`brands`、`brand_refs`、`authorized_operators`）やリダイレクトフィールド（`authoritative_location`、文字列としての `house`、`region`、`note`、`redirect_reason`、`redirect_effective_at`）を運んではなりません（MUST NOT）。
## Mutual-assertion trust model
信頼は 2 つの層で解決します — **ブランドアイデンティティ**（logos、colors、tone、tagline など）と**ブランド関係**（このブランドを誰が所有するか、誰がそれを代弁できるか）。2 つの層はきれいに分離します。アイデンティティは単一の TLS 提供ドキュメントから検証可能です。関係は両側が相互に応答することを必要とします。
| Edge | Identity trust | Relationship trust | Notes |
| ------------------------------------------------------------------- | ------------------------------------ | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `brands[]` のインライン子 | Trusted（親の TLS がデータをカバー） | Trusted（ハウスがエントリを作成） | 古典的な形状。親がデータを所有。 |
| **相互アサーション**: リーフが `house_domain: A` と言い、A の `brand_refs[]` がリーフを含む | Trusted（リーフの TLS） | Trusted（両側が相互応答） | **完全な信頼。** ガバナンス伝播、メンバー機能継承、課金可能な包含がすべて流れる。 |
| **リーフのみ**: リーフが `house_domain: A` と言い、A の `brand_refs[]` がリーフを含まない | Trusted（リーフの TLS） | 未検証 | アイデンティティは本物 — ブランドは自身のドメインを管理。親クレームは未検証。ガバナンスと課金可能な包含は相互応答待ちでブロックされる。[Self-healing through notification](#self-healing-through-notification) を参照。 |
| **ハウスのみ**: A の `brand_refs[]` がリーフを含み、リーフが `house_domain` を持たない | Trusted（リーフの TLS — スタンドアロンドキュメントとして） | 逆方向で未検証 | リーフは A を主張していない。リーフをスタンドアロンとして扱う。A のクレームは補助メタデータ。 |
| スタンドアロン（`house_domain` なし） | Trusted（リーフの TLS） | n/a — 主張された関係なし | Patagonia、Liquid Death。ブランドはそれ自体のもの。 |
**主要な非対称性。** 自身のドメインで検証済み TLS を持つリーフは、その親クレームが相互応答されているかどうかに関係なく、*自身のアイデンティティ属性*について権威を持ちます。相互アサーションがゲートするのは関係層です。素朴な「主張されたが未検証 ⇒ リーフを完全に無視」という読みは誤りです — リーフの logos/colors/tone は依然として本物です。
**スタンドアロンは第三者クレームに勝る。** `house_domain` のない Brand Canonical Document はスタンドアロンです。他のハウスの `brand_refs[]` がそれをリストしていても、リーフの沈黙が決定的です: スタンドアロンとして扱い、第三者クレームは未検証メタデータのみです。規範的な記述については [Conformance](#conformance) を参照。
検証はランタイムチェックです（クローラーが両方のドキュメントを取得して比較）。JSON スキーマはフィールドを独立して受け入れます。
### Self-healing through notification
リーフのみのエッジケースは実際に一般的です — サブブランドチームが、親のポートフォリオチームが相互エントリを追加する時間を持つ前に、自身の正準ドキュメントを立ち上げます。今日これはブランドを行き詰まらせます: アイデンティティは良好ですが、メディアバイとガバナンス決定はブロックされます。
仕様は自己修復ループを定義します。ブランドエージェント**なし**のハウスの場合:
1. ハウスがその `brand.json` のトップレベルで到達可能な `contact.email` を公開します。
2. コンシューマーがリーフのみのエッジ — リーフが `house_domain: A` を主張し、A の `brand_refs[]` がリーフを含まない — に遭遇したとき、コンシューマーは、リーフが相互応答を主張し検証待ちでブロックされていることを A の `contact.email` に通知すべきです（**SHOULD**）。
3. ハウスチームがエントリを `brand_refs[]` に追加します。次のクロール/再検証で、エッジは相互にアップグレードします。
[`verify_brand_claim`](/docs/brand-protocol/tasks/verify_brand_claim) をアドバタイズするブランドエージェント**あり**のハウスの場合、コンシューマーは代わりにエージェントに直接尋ねます — 下記 [Agent-augmented verification](#agent-augmented-verification) を参照。エージェントパスは、メールループが表現できるよりリッチな状態（`pending_review`、`transferring`、`disputed`、`licensed_in`）を表面化し、ハウスとリーフの両方がエージェントを公開する場合、静的ファイルのクロールなしに 2 つの署名付きエージェント呼び出しを通じて相互アサーションが完了します。
### Agent-augmented verification
ブランドがブランドエージェント（[variant 3](#3-brand-agent)、またはバリアント 4/5 の `agents[]` の `type: "brand"` エントリ）を公開する場合、エージェントに [`verify_brand_claim`](/docs/brand-protocol/tasks/verify_brand_claim) を通じて検証の質問ができます — `claim_type`（`subsidiary` / `parent` / `property` / `trademark`）を取り、ブランドの権威ある回答を返す単一のツールです。ブランドエージェントは、サーバーの背後に隠された brand.json です: 静的ファイルが運ぶのと同じデータに加え、静的ファイルが捕捉できないよりリッチな状態（`pending_review`、`transferring`、`disputed`、`licensed_in`、`licensed_out`）です。
**信頼モデルは方向によって非対称です。** この非対称性がなければ、悪意ある、または誤ったハウスが所有していない子会社を主張し、署名だけの強さでコンシューマーに信頼を拡張させることができます。
| Direction | Trust rule |
| ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **拒否** — エージェントが `disputed` または `not_ours` に署名 | 一方的に権威を持つ。ブランドは他の当事者が何を公開しようと関連を拒否する立場を持つ。任意の相互応答クレームをオーバーライドする。 |
| **アサーション** — エージェントが `owned` / `pending_review` / `transferring` / `licensed_*` に署名 | 情報提供的だが単独では信頼を拡張しない。相互側が（自身のブランドエージェントの `parent` クレームタイプを通じて、または静的クロールを通じて）依然として確認しなければ、関係信頼は拡張しない。 |
ハウスとリーフの両方がブランドエージェントを公開する場合、相互アサーションはエージェント層で完了できます: パートナーがハウスに `claim_type: "subsidiary"` で、リーフに `claim_type: "parent"` で `verify_brand_claim` を呼び出します。両方が `owned` → 相互アサーション、リアルタイム、両当事者による署名、クロール不要。これが信頼拡張の最もクリーンなパスです。
**相互アサーションは 2 当事者間の一貫性を証明し、立場を証明しません。** 攻撃者が制御するドメインの相互アサーションを行う 2 つのエージェントは、一致する `owned` レスポンスに署名できます。相互アサーションは、彼らが同意することのみを確認し、いずれかが基礎となるブランドに対して正当な権限を持つことは確認しません。最終的な信頼ゲートは依然としてドメイン管理 + TLS です — コンシューマー側で、コンシューマーがドメインを所有すると期待する法的/運用エンティティに対して検証されます。エージェント層での相互アサーションは下限です。コンシューマー側の立場チェック（ドメイン登録、実世界のアイデンティティ）は、高信頼の決定については依然として呼び出し元の責任です。
エージェントレスポンスはブランドの `adcp_use: "response-signing"` JWK の下で署名されます。完全なリクエスト/レスポンス形状とクレームタイプごとの詳細については、[タスクリファレンス](/docs/brand-protocol/tasks/verify_brand_claim) を参照。
### Field resolution
継承/オーバーライドブロックはありません。各コンシューマー側の質問には単一の回答があります。
| Question | Resolution |
| -------------------------------------------------- | ------------------------------------------------------- |
| ブランドアイデンティティ（logos、colors、tone、tagline、voice） | ブランド自身の正準ドキュメントから読む。インライン子については、親の `brands[]` エントリから読む。 |
| ブランド連絡先、properties、industries | ブランド自身の正準ドキュメントから読む。 |
| Trademarks、authorized\_operators、コーポレート連絡先 | ハウスの brand.json から読む。 |
| `data_subject_contestation`、コンプライアンスポリシー、規制カテゴリフラグ | ハウスレベルとブランドレベルの**最も厳格なもの**。下記参照。 |
| 相互アサーション検証 | ブランドとハウスの両方を取得し、`house_domain` ↔ `brand_refs[]` を比較。 |
**アイデンティティフィールド**（`name`、`names`、`logos`、`colors`、`fonts`、`tone`、`voice`、`tagline`、`visual_guidelines`、`avatar`）: ブランドレベルの値が権威を持ちます。ハウスの値は参照されません。ブランドチームがブランドアイデンティティを所有します。
### Authorized Operator Resolution
`authorized_operators[]` エントリは、ブランド、国、アクティビティ、時間でスコープできます。オペレーター関係を評価するコンシューマーは、現在時刻が `valid_from` より前、または `valid_until` 以降のとき、エントリを無視しなければなりません（MUST）。省略された有効性フィールドは、ハウスが機械可読な開始または終了境界を公開していないことを意味します。
`scopes` が省略された場合、コンシューマーはエントリを、リストされたブランドと国に対する後方互換の広範な認可として扱うべきです。`scopes` が存在する場合、オペレーターはリストされたアクティビティのみ、または明示的に `all` を含む場合はすべてのアクティビティについて認可されます。
`authorized_operators[]` はパブリッシャー側のインベントリ認可を置き換えません。委任またはネットワークインベントリについては、バイヤーは依然としてパブリッシャーの一致する `adagents.json` 認可を必要とします。ブランドファイルは誰がブランドまたはハウスを代表できるかを確立し、`adagents.json` は誰がパブリッシャーのインベントリを販売できるかを確立します。
**コンプライアンスとガバナンスのフィールド**: 解決される値はハウスレベルとブランドレベルの値の**最も厳格なもの**です。ブランドはハウスのガバナンスアサーションを弱められません。より厳しい制約を追加できるだけです。次に適用されます。
* `data_subject_contestation` — 両方の連絡先がデータ主体に提示されるべきです（SHOULD。コンシューマーはいずれかを使ってもよい。ブランドレベルはハウスレベルを置き換えない）
* `compliance_policies`、オーディエンス除外、規制カテゴリフラグ — 和集合として解決（より多くの制限が勝つ）
これが、ホールドコがコーポレートレベルのガバナンスを公開する負荷を担う理由です: ブランドチームが自己公開によってコンプライアンスを緩められるべきではありません。アイデンティティはブランドチームが所有するものなのでブランドが勝ち、ガバナンスは法務/コンプライアンスレジームが実際に機能する方法なので最も厳格なものです。スキーマはこのルールをエンコードしません。これは解決層のセマンティクスです。
完全なクローラー手順については、下記 [Resolution algorithm](#resolution-algorithm) を参照。
### Acquisitions and reorganizations
既存のリダイレクトバリアントは M\&A をネイティブに処理します。
1. ディール前: `dentsu.com/.well-known/brand.json` は House Portfolio です。Dentsu ブランドの正準ドキュメントは `house_domain: "dentsu.com"` と言います。
2. ディール成立: Dentsu の `brand.json` が [House Redirect](#2-house-redirect) → `{ "house": "wpp.com" }` に置き換えられます。WPP は買収したブランドを、運用継続のための `managed_by: "dentsu.com"` とディール成立日に設定された `effective_at` とともに `brand_refs[]` に追加します。
3. ディール後: 依然として `house_domain: "dentsu.com"` を指すリーフは、リダイレクトを通じて WPP に解決します。相互アサーション検証はリダイレクトチェーンをたどり（[Conformance](#conformance) を参照）、保持されます。緊急のリーフ移行は不要です。
### Adopting brand\_refs\[] for an existing portfolio
既存の House Portfolio パブリッシャー（今日インライン `brands[]` 上）は移行する必要はありません。`brand_refs[]` は追加的でプルベースです — ブランドは、そのチームが自己公開を決定したときにのみ `brands[]` から移動します。
単一ブランドの移行パス:
1. 子ブランドが自身のドメインで `/.well-known/brand.json` を Brand Canonical Document として立ち上げ、`house_domain: ""` を宣言します。
2. ハウスチームが子のエントリを `brands[]` から削除し、`{ domain, brand_id, effective_at }` を `brand_refs[]` に追加します。`brand_id` は子が使う値に一致しなければなりません（MUST）。そうでなければ、クロス配列の一意性不変条件が将来の読者を助けません。
3. クローラーが次のリフレッシュで相互アサーションを取得します。
ステップ 1 と 2 の間、リーフのみのエッジは関係層で未検証ですが、リーフの*アイデンティティ*は依然として TLS で信頼されます（[Self-healing through notification](#self-healing-through-notification) を参照）。コンシューマーは、ステップ 2 を促すためにハウスの `contact.email` にメールすべきです（SHOULD）。
AAO レジストリは今日両方の形状を消費し、`brands[]` から `brand_refs[]` に移動するブランドを再分類しません — `brand_id` が移行を通じた安定した識別子です。
### Out of scope
単一ハウス、シングルホップの信頼モデルは、意図的に 4 つの形状をカバーしません。
* **2 つの親を持つジョイントベンチャー**（Disney 以前の Hulu、ファーマの JV、自動車パートナーシップ）。リーフは最大 1 つの `house_domain` を持ちます。JV 構造は 1 つの正準親を選ぶか、持株エンティティを使わなければなりません。プロトコルは 2 親所有をモデル化しません。
* **不透明性を望む PE ロールアップとホワイトラベル取り決め。** 相互アサーションは所有権を well-known URL で公開します。公開開示なしにブランドを運営したいホールドコは、既存のモノリシックな `brands[]` 形状（リーフドメインのクローラーに親を公開しない）を使えますが、相互アサーションは使えません。相互アサーションは不透明性を検証可能性と引き換えにします — それが設計です。
* **管轄ガバナンスの乖離**（例: データ主体の争議ルールが米国親と異なるドイツの Marriott フランチャイジー）。最も厳格な解決は、ブランドレベルのパブリッシャーが制約を*追加*できるだけであることを意味します。規制の緩い管轄のブランドは、それに適用されないハウスレベルのルールを落とせません。回避策: ハウスが最も厳格な適用可能な地域ごとのルールを公開します。
* **静的な brand.json サーフェスとしての標準的なライセンス関係。** `claim_type: "trademark"` を伴う [`verify_brand_claim`](/docs/brand-protocol/tasks/verify_brand_claim) は、基礎となる関係が本物であるため `licensed_in` / `licensed_out` を返せます — Marriott フランチャイジーはライセンスの下で MARRIOTT マークを使い、音楽カタログは領域ごとにライセンスアウトされ、管轄ライセンス分割（「CN でライセンス、他では自己管理」）は一般的です。ブランドエージェントは内部記録からこれらについて語れます。**しかし `brand.json` 自体は、所有権のための `brand_refs[]` と並行する、標準的なライセンス関係の公開サーフェスをまだ持ちません。** 既存の権利プロトコル（`rights_agent`、`acquire_rights`）は、標準的な宣言ではなく*トランザクショナルな*ライセンス — ディールの交渉 — を処理します。このギャップは本物で、フォローアップとして追跡されています。verify サーフェスは、パートナーがそれらを消費する必要があるため状態を公開しますが、それらを支える静的ファイル基盤は権利プロトコルチームとともに別個の設計です。
これらのケースは brand.json ではなくガバナンス / コーポレート構造の仕様に属します。`brand.json` はブランドアイデンティティのサーフェスです。コーポレート法務構造とライセンス関係の公開は、それぞれ独自の関心事です。
## House definition
house オブジェクトはコーポレートエンティティを表します。
| Field | Type | Required | Description |
| -------------- | ------ | -------- | ---------------------------------------------- |
| `domain` | string | Yes | ハウスの主要ドメイン |
| `name` | string | Yes | 表示名 |
| `names` | array | No | ローカライズされた名前 |
| `architecture` | enum | No | `branded_house`、`house_of_brands`、または `hybrid` |
## Brand definition
`brands` 配列内の各ブランド:
| Field | Type | Required | Description |
| ------------------- | ------ | -------- | -------------------------------------------------------------------------------------------------------------------------- |
| `id` | string | Yes | ブランド識別子（アンダースコア付きの小文字英数字） |
| `names` | array | Yes | ローカライズされた名前（下記参照） |
| `keller_type` | enum | No | `master`、`sub_brand`、`endorsed`、`independent` |
| `parent_brand` | string | No | 親ブランドの id |
| `properties` | array | No | このブランドに関連付けられたデジタルプロパティ |
| `brand_agent` | object | No | ブランドアイデンティティデータを提供するエージェント `{ url, id }` |
| `rights_agent` | object | No | 権利ライセンスエージェント `{ url, id, available_uses, right_types, countries }` |
| `logos` | array | No | ブランドロゴアセット |
| `colors` | object | No | ブランドカラーパレット |
| `fonts` | object | No | ブランドタイポグラフィ |
| `tone` | object | No | ブランドのボイスとメッセージングガイドライン（`voice`、`attributes`、`dos`、`donts`） |
| `tagline` | string | No | ブランドタグラインまたはスローガン |
| `visual_guidelines` | object | No | 生成クリエイティブシステム向けの構造化ビジュアルルール |
| `trademarks` | array | No | このブランドが所有またはライセンスする登録商標（`registry`、`number`、`mark`、任意の `status`、`license_type`、`countries`）。[Trademarks](#trademarks) を参照。 |
### Names Array
名前は言語コードでローカライズされます。
```json theme={null}
{
"names": [
{"en": "Nike"},
{"en": "The Swoosh"},
{"zh": "耐克"},
{"ja": "ナイキ"}
]
}
```
言語ごとに複数のエントリが許可されます（エイリアス用）。
### Keller Types
マーケティング理論からのブランドアーキテクチャ分類:
| Type | Description | Example |
| ------------- | -------------------- | -------------------- |
| `master` | ハウスの主要ブランド | Nike, Inc. の Nike |
| `sub_brand` | 親ブランド名を運ぶ | Nike SB |
| `endorsed` | 独立したアイデンティティ、親によって推奨 | Air Jordan "by Nike" |
| `independent` | ハウスとは別に運営 | Converse |
### Extended color roles
`colors` オブジェクトは 5 つの標準ロール（`primary`、`secondary`、`accent`、`background`、`text`）を持ちますが、ブランドはより細かい粒度のために追加のロールを提供でき、また提供すべきです。スキーマは `additionalProperties` を通じて任意の追加カラーロールを受け入れます。
```json theme={null}
{
"colors": {
"primary": "#FF6600",
"secondary": "#0066CC",
"background": "#FFFFFF",
"text": "#1A1A1A",
"heading": "#FF6600",
"body": "#333333",
"label": "#666666",
"border": "#E5E5E5",
"divider": "#F0F0F0",
"surface_1": "#F9F9F9",
"surface_2": "#F0F0F0"
}
}
```
| Role | Purpose |
| ----------- | ----------------------- |
| `heading` | 見出しテキストの色（本文テキストと異なる場合） |
| `body` | 本文テキストの色 |
| `label` | ラベル/キャプションテキストの色 |
| `border` | ボーダー/アウトラインの色 |
| `divider` | ディバイダー/セパレーターの色 |
| `surface_1` | 主要サーフェス/カード背景 |
| `surface_2` | 副次サーフェス背景 |
これらの拡張ロールは、クリエイティブエージェントが推測せずにテキスト階層とサーフェスレベルを区別するのに役立ちます。
## Visual guidelines
`visual_guidelines` オブジェクトは、生成クリエイティブシステムがオンブランドのアセットを一貫して生成するために使える構造化ルールを提供します。これらはブランド定数です — キャンペーンごとに変わりません。
ビジュアルガイドラインは基本的なアイデンティティフィールド（`colors`、`fonts`、`logos`）を補完します。colors はブランドパレットが*何*かを定義し、visual guidelines はそれを*どう*使うかを定義します。fonts はフォントファミリーを定義し、visual guidelines はタイプスケールを定義します。
### Photography
ブランド写真が選択または生成されるときにどう見えるべきかを制御します。
```json theme={null}
{
"photography": {
"realism": "natural",
"lighting": "soft daylight",
"color_temperature": "warm",
"contrast": "medium",
"depth_of_field": "medium",
"subject": {
"people": {
"age_range": "25-45",
"diversity": "mixed",
"mood": ["confident", "relaxed"]
},
"product_focus": "in-use",
"setting": "outdoor"
},
"framing": {
"subject_position": "center-left",
"crop_style": "waist-up",
"perspective": "eye-level"
}
}
}
```
| Field | Type | Description |
| ------------------------- | ------ | ------------------------------------------- |
| `realism` | enum | `natural`、`stylized`、`hyperreal`、`abstract` |
| `lighting` | string | ライティングスタイルの説明 |
| `color_temperature` | enum | `warm`、`neutral`、`cool` |
| `contrast` | enum | `low`、`medium`、`high` |
| `depth_of_field` | enum | `shallow`、`medium`、`deep` |
| `subject` | object | 被写体ガイドライン（people、product focus、setting） |
| `framing` | object | カメラフレーミングルール（position、crop、perspective） |
| `preferred_aspect_ratios` | array | 優先アスペクト比（例: `["16:9", "4:5", "1:1"]`） |
| `tags` | array | 追加のスタイル記述子 |
### Graphic style
ブランドグラフィックとイラストのビジュアル言語を定義します。
```json theme={null}
{
"graphic_style": {
"style_type": "flat_illustration",
"stroke_style": "rounded",
"stroke_weight": "2px",
"corner_radius": "12px"
}
}
```
スタイルタイプ: `flat_illustration`、`geometric`、`gradient_mesh`、`editorial_collage`、`hand_drawn`、`minimal_line_art`、`3d_render`、`isometric`、`photographic_composite`。
| Field | Type | Description |
| --------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `style_type` | enum | `flat_illustration`、`geometric`、`gradient_mesh`、`editorial_collage`、`hand_drawn`、`minimal_line_art`、`3d_render`、`isometric`、`photographic_composite` |
| `stroke_style` | enum | `rounded`、`square`、`mixed`、`none` |
| `stroke_weight` | string | ストローク太さ（例: `2px`） |
| `corner_radius` | string | グラフィック/イラスト要素のコーナー半径（例: `12px`）。UI コンポーネントには `border_radius` を参照。 |
| `tags` | array | 追加のスタイル記述子 |
### Shapes
ビジュアルアイデンティティの一部として使われるブランドシェイプ:
```json theme={null}
{
"shapes": {
"primary_shape": "circle",
"secondary_shapes": ["rounded_rectangle", "diagonal_wave"],
"usage": {
"max_per_layout": 2,
"overlap_allowed": true
}
}
}
```
| Field | Type | Description |
| ----------------------- | ------- | ----------------------------------------------------- |
| `primary_shape` | string | 主要ブランドシェイプ（例: `circle`、`rounded_rectangle`、`hexagon`） |
| `secondary_shapes` | array | ブランド語彙の副次シェイプ |
| `usage.max_per_layout` | integer | レイアウトごとの最大の異なるシェイプ数 |
| `usage.overlap_allowed` | boolean | シェイプが重なってよいか |
### Iconography
アイコンスタイルシステムと使用ルール:
```json theme={null}
{
"iconography": {
"style": "outline",
"stroke_weight": "2px",
"corner_style": "rounded",
"usage": {
"max_per_frame": 3,
"size_ratio": "1:8"
}
}
}
```
| Field | Type | Description |
| --------------------- | ------- | -------------------------------------------------------- |
| `style` | enum | `outline`、`filled`、`duotone`、`flat`、`glyph`、`hand_drawn` |
| `stroke_weight` | string | アイコンのストローク太さ（例: `2px`） |
| `corner_style` | enum | `rounded`、`square`、`mixed` |
| `usage.max_per_frame` | integer | クリエイティブフレームごとの最大アイコン数 |
| `usage.size_ratio` | string | アイコン対レイアウトのサイズ比（例: `1:8`） |
### Composition
オーバーレイ、テクスチャ、背景のレイアウトルール:
```json theme={null}
{
"composition": {
"overlays": {
"gradient_style": "linear",
"gradient_direction": "45deg",
"opacity": "70%"
},
"texture": {
"style": "subtle_grain",
"intensity": "low"
},
"backgrounds": {
"types_allowed": ["solid_color", "gradient", "image"]
}
}
}
```
テクスチャスタイル: `none`、`subtle_grain`、`noise`、`paper`、`fabric`、`concrete`。強度: `low`、`medium`、`high`。
背景タイプ: `solid_color`、`gradient`、`blurred_photo`、`image`、`video`、`pattern`、`transparent`。
### Border radius
UI コンポーネントとレイアウト要素の名前付きボーダー半径プリセット。ボーダー半径は最も目立つブランド差別化要因の 1 つです — 大きな半径は温かく親しみやすく感じられ、小さいまたはゼロの半径は精密で編集的に感じられます。
```json theme={null}
{
"border_radius": {
"none": "0",
"default": "12px",
"small": "4px",
"large": "20px",
"pill": "999px"
}
}
```
| Field | Type | Description |
| --------- | ------ | --------------------------------------- |
| `none` | string | 明示的にシャープなコーナー（`0`） |
| `default` | string | UI コンポーネントのデフォルトボーダー半径（例: `8px`、`12px`） |
| `small` | string | コンパクト要素用の小さい半径（例: `4px`） |
| `large` | string | カードとコンテナ用の大きい半径（例: `16px`、`24px`） |
| `pill` | string | 完全に丸い / ピル形状（例: `999px`） |
5 つの標準レベルを超えて追加の名前付きプリセットを追加できます。
`graphic_style.corner_radius` はグラフィック/イラスト要素のデフォルト半径を定義します。`border_radius` は UI コンポーネントとレイアウト — ボタン、カード、入力、モーダル — の名前付きスケールを定義します。
### Elevation
要素がサーフェスから浮き上がって見える方法を定義する名前付きシャドウレベル。ブランドはエレベーションをアイデンティティとして使います — ドラマチックな多層シャドウを好むものもあれば、単一の拡散シャドウを使うものもあります。
```json theme={null}
{
"elevation": {
"none": "none",
"subtle": "0 1px 3px rgba(0,0,0,0.08)",
"card": "0 4px 8px -1px rgba(0,0,0,0.1), 0 2px 4px -2px rgba(0,0,0,0.06)",
"modal": "0 20px 25px -5px rgba(0,0,0,0.1), 0 8px 10px -6px rgba(0,0,0,0.06)"
}
}
```
値は CSS `box-shadow` 構文を使います。生成システムはこれらを直接適用できます。
| Field | Type | Description |
| -------- | ------ | ------------------- |
| `none` | string | シャドウなし（`none`） |
| `subtle` | string | インタラクティブ要素の軽い浮き上がり |
| `card` | string | カードレベルのエレベーション |
| `modal` | string | モーダル/オーバーレイのエレベーション |
追加の名前付きレベル（例: `dropdown`、`tooltip`）を追加できます。
### Spacing
一貫したレイアウトリズムのためのスペーシングシステム。ベースユニットと名前付きスケールにより、クリエイティブエージェントは推測せずに正しくスペースされたレイアウトを生成できます。
```json theme={null}
{
"spacing": {
"unit": "8px",
"scale": {
"xs": "4px",
"sm": "8px",
"md": "16px",
"lg": "24px",
"xl": "32px",
"2xl": "48px"
}
}
}
```
| Field | Type | Description |
| ------- | ------ | ----------------------------------------------------------------- |
| `unit` | string | このスケールが設計されたベースグリッドユニット（例: `8px`）。情報提供 — エージェントは名前付きスケール値を直接使うべき。 |
| `scale` | object | 名前付きスペーシングスケール（`xs` から `2xl`） |
`scale` オブジェクトは標準サイズ（`xs`、`sm`、`md`、`lg`、`xl`、`2xl`）をサポートし、追加の名前付き値（例: `3xl`、`section`）を含められます。
### Graphic elements
ブランドアイデンティティの一部である再利用可能な装飾的または構造的なビジュアル要素 — 破れた紙の端、ウォーターマーク、ディバイダー、背景パターン:
```json theme={null}
{
"graphic_elements": [
{
"name": "Paper Tear",
"type": "frame",
"description": "Torn paper edge used as section dividers and photo frames. Use primarily vertical orientation.",
"orientation": "vertical",
"colors": ["#a75230", "#f6f1f1", "#fba007"],
"max_per_layout": 2
},
{
"name": "Location Sketch Watermark",
"type": "watermark",
"description": "Light hand-drawn building sketch behind content, visible through the logo area",
"colors": ["#a75230"]
}
]
}
```
| Field | Type | Required | Description |
| ---------------- | ------- | -------- | ------------------------------------------------------------------------------- |
| `name` | string | Yes | 要素名 |
| `type` | enum | No | `border`、`divider`、`frame`、`watermark`、`pattern`、`texture_overlay`、`decorative` |
| `description` | string | No | 要素がレイアウトでどう使われるか |
| `orientation` | enum | No | `horizontal`、`vertical`、`any` |
| `colors` | array | No | この要素が現れてよい色 |
| `max_per_layout` | integer | No | レイアウトごとの最大インスタンス数 |
### Motion
動画、アニメーションディスプレイ、インタラクティブフォーマットのモーションとアニメーションルール:
```json theme={null}
{
"motion": {
"transition_style": "dissolve",
"animation_speed": "moderate",
"easing": "ease-in-out",
"text_entrance": "fade",
"pacing": "lingering",
"kinetic_typography": false
}
}
```
| Field | Type | Description |
| -------------------- | ------- | ---------------------------------------------------------- |
| `transition_style` | enum | `cut`、`dissolve`、`slide`、`wipe`、`zoom`、`fade` |
| `animation_speed` | enum | `slow`、`moderate`、`fast` |
| `easing` | string | デフォルトのイージング関数（例: `ease-in-out`、`spring`、`linear`） |
| `text_entrance` | enum | `fade`、`typewriter`、`slide_up`、`slide_left`、`scale`、`none` |
| `pacing` | enum | `lingering`、`moderate`、`fast_cuts` |
| `kinetic_typography` | boolean | アニメーション/キネティックタイポグラフィが許可されるか |
| `tags` | array | 追加のモーションスタイル記述子 |
### Logo placement
自動化されたクリエイティブ制作のためのロゴ配置とクリアスペースルール:
```json theme={null}
{
"logo_placement": {
"preferred_position": "bottom-left",
"min_clear_space": "0.5x",
"min_height": "40px",
"background_contrast": "any"
}
}
```
| Field | Type | Description |
| --------------------- | ------ | ----------------------------------------------------------------------------------------- |
| `preferred_position` | enum | `top-left`、`top-center`、`top-right`、`bottom-left`、`bottom-center`、`bottom-right`、`center` |
| `min_clear_space` | string | ロゴ高さの倍数（例: `0.5x`、`1x`）または固定値（例: `16px`）としての最小クリアスペース |
| `min_height` | string | 可読性のための最小ロゴ高さ（例: `40px`） |
| `background_contrast` | enum | `light_only`、`dark_only`、`any` |
### Logo selection slots
ライトロゴカード、ダークロゴカード、プロファイルマーク、CTV エンドカード、コブランドロックアップ、マーケットプレイスリスティングなどの特定のサーフェスに対して、レンダラーが正しいロゴバリアントを選ぶ必要がある場合に `logos[].slots[]` を使います。`logos[].id` は、可変のアセット URL に依存しない安定したターゲットをダウンストリームルールに与えます。
```json theme={null}
{
"logos": [
{
"id": "primary_horizontal",
"url": "https://assets.example.com/logos/primary.svg",
"orientation": "horizontal",
"background": "light-bg",
"variant": "primary",
"slots": ["logo_card_light", "nav_header", "marketplace_listing"]
},
{
"id": "knockout_horizontal",
"url": "https://assets.example.com/logos/knockout.svg",
"orientation": "horizontal",
"background": "dark-bg",
"variant": "secondary",
"slots": ["logo_card_dark", "ad_end_card"]
}
]
}
```
正準クリエイティブフォーマットは、マニフェストアセットグループに依然として `asset_group_id: "logo"` を使います。プロダクトがそのスロットを `format_options[].params.slots[].logo_slots[]` で狭める場合、ビルダーは `logos[].slots[]` が要求されたスロットと交差する `brand.json` の `logos[]` から選択すべきです。フォーマットが `required_logo_slots[]` も宣言する場合、カバレッジの欠如は、黙って文章にフォールバックするのではなく、検証警告または承認マッピングとして表面化すべきです。
`visual_guidelines.logo_usage_rules[]` は、安定した `logo_id` に配置制約を適用できます。
```json theme={null}
{
"visual_guidelines": {
"logo_usage_rules": [
{
"logo_id": "primary_horizontal",
"slots": ["logo_card_light", "marketplace_listing"],
"minimum_size": { "height": "18px" },
"clear_space": "1x cap height",
"forbidden_contexts": ["photography_without_knockout"],
"severity": "must"
}
]
}
}
```
### Color constraints
アクセント専用の色、禁止された背景の組み合わせ、決して一緒に現れるべきでない色などの機械可読なカラー使用とペアリングルールのために `visual_guidelines.color_constraints[]` を使います。
```json theme={null}
{
"visual_guidelines": {
"color_constraints": [
{
"color": { "kind": "name", "name": "market_yellow" },
"applies_to": ["accent"],
"forbidden_on": [
{ "kind": "surface", "surface": "background" },
{ "kind": "surface", "surface": "text" }
],
"never_pair_with": [{ "kind": "name", "name": "linen" }],
"contexts": ["digital", "print", "ctv_end_card"],
"severity": "must",
"description": "Market yellow is accent only."
}
]
}
}
```
各 `color_ref` は明示的な `kind` 識別子を使います: `kind: "name"` は `colors{}` のキーをルックアップし、`kind: "value"` はリテラルの hex カラーを運び、`kind: "surface"` は `background`、`text`、`logo_background` などのレイアウトサーフェスを識別します。
### Mark lockups
コブランド、パートナー、スポンサー、プログラム、または副次マークのレイアウトルールのために `visual_guidelines.mark_lockups[]` を使います。これらのフィールドは、順序、スペーシング、セパレーター、サイズ比のガイダンスをクエリ可能にしながら、光学的バランシングをレイアウト/レンダーレビューに残します。
```json theme={null}
{
"visual_guidelines": {
"mark_lockups": [
{
"lockup_type": "co_brand",
"ordering": "brand_first",
"brand_logo_id": "primary_horizontal",
"contexts": ["partner_campaign", "sponsored_content"],
"separator": {
"type": "keyline",
"color": { "kind": "name", "name": "text" },
"width": "1px"
},
"min_gap": "1x clear space",
"brand_min_optical_weight_ratio": 1,
"partner_max_optical_weight_ratio": 1,
"severity": "must"
}
]
}
}
```
### Tooling notes: ingesting brand books
ブランドガイド PDF からドラフト `brand.json` を作成するツールは、アセット抽出とガイドライン解釈を分離すべきです。
決定的な抽出を使って候補アセット ID を生成します。
* 写真、モックアップ、ラスターアイコン、例のための埋め込み PDF 画像
* ベクターロゴ、マーク、カラースウォッチ、埋め込み画像ファイルでないロゴサンプルのためのレンダーページクロップ
次にマルチモーダルモデルを使って、それらの候補 ID を提案された `logos[]`、`assets[]`、`colors`、`visual_guidelines` ルールに分類します。モデルは既知の候補 ID にマップし戻すべきです。オリジナルのアセットバイトのソースとして扱うべきではありません。
ドラフト取り込み記録は、提案されたロゴエントリから証拠を指せます。
```json theme={null}
{
"asset_id": "candidate_logo_0007",
"source_page": 15,
"extraction_method": "rendered_page_crop",
"proposed_logo": {
"id": "primary_wordmark_dark_card",
"variant": "wordmark",
"background": "dark-bg",
"slots": ["logo_card_dark", "marketplace_listing"]
},
"review_status": "needs_review"
}
```
レビュアーがクロップを確認し、正しいスロット/背景を割り当て、候補ファイルを耐久性のある HTTPS ロゴアセット URL に置き換えるまで、これらの候補を正準 `logos[]` として直接公開しないでください。ソース PDF がホストされたアセット、オペレーター認可、または商標証拠を欠く場合、それはスキーマギャップではなく取り込み警告です。
### Public hosted asset promotion
AAO ホストのブランドアセットは、レビュアーまたは検証済み所有者がパブリックな `brand.json` 使用のためにプライベートアップロードを承認したケース用です。抽出のみでバイトが公開されることは決してありません。プライベート分析アーティファクトはパブリックアセット行とは別のままで、`brand.json` は承認後にのみパブリック URL を受け取ります。
推奨フロー:
1. アップロードまたは抽出されたファイルを分析のためにプライベートに保存します。
2. 正確な提案された `brand.json` diff とともに候補をオペレーターに提示します。
3. プロモーション前に明示的な承認を要求します。
4. 承認されたバイトを安定したパブリック HTTPS URL にプロモートします。
5. そのパブリック URL を `logos[]` に書き込みます。
AAO ホストの URL はこの形状を使います。
```text theme={null}
https://agenticadvertising.org/assets/brands/{domain}/{assetId}.{ext}
```
例:
```json theme={null}
{
"logos": [
{
"id": "primary_wordmark",
"url": "https://agenticadvertising.org/assets/brands/acme.example/{assetId}.png",
"variant": "wordmark",
"slots": ["logo_card_light"],
"width": 512,
"height": 128
}
]
}
```
パブリックロゴプロモーションは、公開された `brand.json` の外部で来歴メタデータを保持しなければなりません: オリジナルのファイル名、既知の場合のアップローダーユーザーと組織、ソースフロー、作成時刻、コンテンツタイプ、寸法、ハッシュ、パスが所有者証明・委任・コミュニティ提出のいずれか。モデレーションと所有者承認の状態は運用メタデータです。コンシューマーがそれらをパブリック URL からパースする必要はないはずです。
初期のプロモーション制限は意図的に保守的です: ロゴに必要な画像 MIME タイプのみを受け入れ（`image/png`、`image/jpeg`、`image/webp`、`image/gif`、およびサニタイズされた `image/svg+xml`）、アップロードを 5 MB に制限し、公開前にラスター寸法を検出し、SVG を積極的にサニタイズするか、サニタイザーがサーフェスで有効になるまで拒否します。プライベート署名付き URL、ファイルビューアーリンク、分析専用のオブジェクトパスは、公開された `brand.json` に現れてはなりません。
削除は URL を無関係なバイトに再利用するのではなく、パブリックアセット行をトゥームストーンすべきです。置換は新しいアセット URL を作成し、`brand.json` をそれを指すよう更新すべきです。以前に公開された URL は、キャッシュ安定性のために古い承認済みバイトを提供し続けるか、1 対 1 の後継がある場合は置換にリダイレクトするか、法的/セキュリティのテイクダウン後に `404` を返してもよいですが、同じ ID の下で異なるアセットを黙って提供してはなりません。
### Colorways
色がどう連携するかを定義する名前付きカラーペアリング。クリエイティブブリーフが、すべての色を指定せずに「私の primary カラーウェイを使う」と参照できるようにします。
```json theme={null}
{
"colorways": [
{
"name": "primary",
"foreground": "#FFFFFF",
"background": "#FF6600",
"accent": "#0066CC",
"cta_foreground": "#FFFFFF",
"cta_background": "#0066CC"
},
{
"name": "inverted",
"foreground": "#FF6600",
"background": "#FFFFFF",
"accent": "#0066CC",
"border": "#FF6600"
}
]
}
```
| Field | Type | Required | Description |
| ---------------- | --------- | -------- | ------------------------------------------------------------------------- |
| `name` | string | Yes | カラーウェイ名（例: `"primary"`、`"inverted"`、`"dark"`） |
| `foreground` | hex color | Yes | テキスト/前景色 |
| `background` | hex color | Yes | 背景色 |
| `accent` | hex color | No | アクセント色 |
| `cta_foreground` | hex color | No | CTA テキスト色 |
| `cta_background` | hex color | No | CTA ボタン色 |
| `border` | hex color | No | ボーダー色 |
| `channels` | array | No | このカラーウェイが適用されるチャネル（例: `["online"]`、`["print", "pos"]`）。ユニバーサルなカラーウェイでは省略。 |
### Type scale
異なるテキストロールのサイズとウェイトを定義するタイポグラフィスケール:
```json theme={null}
{
"type_scale": {
"base_width": "1080px",
"heading": {
"font": "primary",
"size": "48px",
"weight": "700",
"line_height": "1.1"
},
"subheading": {
"font": "primary",
"size": "24px",
"weight": "600",
"line_height": "1.3"
},
"body": {
"font": "secondary",
"size": "16px",
"weight": "400",
"line_height": "1.5"
},
"caption": {
"font": "secondary",
"size": "12px",
"weight": "400",
"line_height": "1.4"
},
"cta": {
"font": "primary",
"size": "18px",
"weight": "700",
"text_transform": "uppercase",
"letter_spacing": "0.05em"
}
}
}
```
`font` フィールドは、ブランドの `fonts` オブジェクトで定義されたフォントロール（`"primary"`、`"secondary"`）を参照するか、フォントファミリー名を直接指定できます。
サイズがピクセルの場合、これらのサイズが設計された参照キャンバスを示すために `base_width` を使います。生成システムは他のキャンバスサイズについて比例的にスケールすべきです — `1080px` 幅用に設計された `48px` の見出しは、`320px` のモバイルリーダーボードで `14px` にスケールします。
### Asset libraries
管理されたアセットライブラリ（アイコンセット、イラストシステム、画像コレクション）への参照。URL は人間のアクセス用です — 人がブラウザで開けるブランドポータル、プレスキット、または DAM ランディングページ。
```json theme={null}
{
"asset_libraries": [
{
"name": "Brand Illustrations v2",
"type": "illustration_system",
"url": "https://brand.example.com/illustrations",
"description": "Flat illustration system with defined color guide",
"color_guide": {
"roles": ["base", "shadow_1", "shadow_2", "highlight_1", "highlight_2", "stroke"],
"palettes": [
{
"name": "orange",
"colors": {
"base": "#FF6600",
"shadow_1": "#CC5200",
"shadow_2": "#993D00",
"highlight_1": "#FF8533",
"highlight_2": "#FFB380",
"stroke": "#662900"
}
}
]
}
}
]
}
```
| Field | Type | Required | Description |
| ------------- | ------------ | ----------- | ----------------------------------------------------------------------------------- |
| `name` | string | Yes | アセットライブラリの表示名 |
| `type` | enum | Recommended | `icon_set`、`illustration_system`、`image_library`、`video_library`、`template_library` |
| `url` | string (URI) | Yes | アセットライブラリへの URL（人間のアクセス用） |
| `description` | string | No | ライブラリの内容と使用の説明 |
| `color_guide` | object | No | ライブラリで使われるカラーロールとパレット |
`color_guide` は、ライブラリで使われるカラーパレットを生成システムに提供します — ライブラリ自体にアクセスせずにオンブランドのイラストやアイコンを生成するのに有用です。
### Restrictions
ビジュアルの禁止事項とガードレール — `tone.donts` のビジュアル版。生成システムに何を避けるべきかを伝えます。
```json theme={null}
{
"restrictions": [
"Never place text over the product",
"Do not use black backgrounds",
"No stock photography of people on phones",
"No split-screen layouts"
]
}
```
## Trademarks
登録商標は、**ハウスレベル**（コーポレートマーク — 例: Nike, Inc. が所有する NIKE）または**ブランドレベル**（ブランド固有のマーク — 例: Converse が所有する CONVERSE）に現れます。両方の配列が有効なクレームです。それらの間の解決は**和集合**です。
**ライセンスイン / ライセンスアウト関係**（MARRIOTT マークを使う Marriott フランチャイジー、領域ごとにライセンスされる音楽カタログなど）は、`claim_type: "trademark"` を伴う [`verify_brand_claim`](/docs/brand-protocol/tasks/verify_brand_claim) を通じて今日ブランドエージェント経由でクエリ可能です。標準的なライセンス関係のための静的な `brand.json` 公開サーフェス（所有権のための `brand_refs[]` と並行する）は、権利プロトコルチームとともに将来の RFC です。下記の静的 `trademarks[]` 配列は所有権のみをカバーします。ライセンスの姿勢はエージェントから来ます。
```json theme={null}
{
"trademarks": [
{
"registry": "USPTO",
"number": "12345678",
"mark": "CONVERSE",
"status": "active",
"license_type": "owned",
"countries": ["US"]
}
]
}
```
| Field | Type | Required | Description |
| -------------- | ------ | -------- | ------------------------------------------------------------------------------------- |
| `registry` | string | Yes | 商標レジストリ（例: `USPTO`、`EUIPO`、`JPO`、`CNIPA`） |
| `number` | string | Yes | レジストリが発行した登録番号 |
| `mark` | string | Yes | 公開された登録マーク |
| `status` | enum | No | `active`、`pending`、`abandoned`、`cancelled`、`expired`。ステータス追跡が維持されていない場合、アクティブマークでは省略。 |
| `license_type` | enum | No | `owned`（デフォルト）、`licensed_in`、`licensed_out` |
| `countries` | array | No | この登録が適用される ISO 3166-1 alpha-2 国コード。グローバル、またはレジストリの管轄が暗黙的な場合は省略。 |
クロス管轄の競合を持つホールドコ（異なる所有者の USPTO `CONVERSE` 対 EUIPO `CONVERSE`）は、各登録を別個のエントリとして公開し、`countries` を使ってマークが適用される場所をスコープすべきです。
## Property definition
プロパティはブランドに関連付けられたデジタルタッチポイントです。
| Field | Type | Required | Description |
| -------------- | ------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type` | enum | Yes | プロパティタイプ（下記参照） |
| `identifier` | string | Yes | ドメインまたはアプリ ID |
| `store` | enum | No | アプリストア（`apple`、`google` など） |
| `region` | string | No | ISO 国コードまたは `global` |
| `primary` | boolean | No | これが主要プロパティか？ |
| `relationship` | enum | No | このブランドがプロパティにどう関係するか: `owned`（デフォルト）、`direct`、`delegated`、`ad_network`。委任/ネットワークの値は、双方向検証のために adagents.json の `delegation_type` に一致します。`owned` は brand.json のみの所有権クレームです。[アドネットワーク](/docs/sponsored-intelligence/networks) を参照。 |
### Property types
AdCP の property-type enum に一致します。
* `website`
* `mobile_app`
* `ctv_app`
* `desktop_app`
* `dooh`
* `podcast`
* `radio`
* `streaming_audio`
### Property relationships
プロパティはデフォルトで `owned` です — ブランドがプロパティを直接運営します。所有していないインベントリを販売するネットワークと SSP について、`relationship` フィールドは商業的取り決めを宣言します。
| Value | Meaning | Example |
| ------------ | ---------------------------------------------- | ------------------------------- |
| `owned` | ブランドがこのプロパティを所有・運営（デフォルト） | 自身のウェブサイト |
| `direct` | 第三者がテクノロジーを運営していても、ブランドが直接の販売パス | ベンダーのプラットフォームを使うパブリッシャーの社内広告チーム |
| `delegated` | ブランドがマネタイズを管理 — 広告販売を担当 | フードブログを管理する Mediavine |
| `ad_network` | ブランドがネットワーク/エクスチェンジの一部として販売 — 唯一のパスではなく 1 つのパス | SSP としての PubMatic |
これは `sellers.json` の AdCP 版です — オペレーターがどのパブリッシャーと連携するかの公開宣言です。委任またはネットワークパスについては、パブリッシャーが自身の [adagents.json](/docs/governance/property/adagents) でエージェントの認可に一致する `delegation_type` を設定することで確認します。ファーストパーティインベントリについては、`relationship: "owned"` はオペレーターのインライン所有権宣言です。セルサイド実装は、オペレーターの `brand.json` クレームと、インベントリがパブリッシャー認可または委任の場合はパブリッシャーの一致する `adagents.json` 認可を必要とします。ステップバイステップのセルサイドパターンについては [セラーセットアップ](/docs/brand-protocol/seller-setup) を、ネットワーク固有のガイダンスについては [アドネットワーク](/docs/sponsored-intelligence/networks) を参照。
## Resolution algorithm
ドメインを正準ブランドに解決するには:
1. `https://{domain}/.well-known/brand.json` を取得します。
2. バリアントを確認します:
* **authoritative\_location**: その URL から取得し、ステップ 2 から続行します。
* **house**（文字列）: ハウスドメインから取得し、ステップ 2 から続行します。
* **brand\_agent**: エージェント URL を返します — エージェントが権威を持ちます。
* **House Portfolio**（`house` オブジェクト + `brands[]` および/または `brand_refs[]`）: インライン子については、`properties[]` または `id` がクエリに一致するブランドを見つけます。ポインター子については、`brand_refs[].domain` をたどって一度解決します — たどったドキュメントは Brand Canonical Document でなければならず、決して別の House Portfolio であってはなりません（MUST）。
* **Brand Canonical Document**（トップレベルの `id` + `names`）: ドキュメントがブランドです。`house_domain` が存在する場合、ハウスの `brand.json` を取得して、その `brand_refs[]` での相互応答を検証します（相互アサーション）。ハウス側自体が [House Redirect](#2-house-redirect) の場合、比較する前にハウス側のリダイレクトチェーンをたどります。ブランドに存在しない場合、コーポレートレベルのフィールド（例: `data_subject_contestation`）をハウスから読みます。コンプライアンスフィールドについては、ハウスとブランドの**最も厳格なもの**を解決します（[Mutual-assertion trust model](#mutual-assertion-trust-model) を参照）。
3. 正準ブランド情報を返します。
最大リダイレクト深さ: 3 ホップ。ブランド → ハウスのルックアップはシングルホップです（再帰的な親ウォークなし）。信頼セマンティクスについては [Mutual-assertion trust model](#mutual-assertion-trust-model) を参照。
## Complete examples
### Small Business
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"house": {
"domain": "bobsburgers.com",
"name": "Bob's Burgers LLC"
},
"brands": [
{
"id": "bobs_burgers",
"names": [{"en": "Bob's Burgers"}],
"keller_type": "master",
"properties": [
{"type": "website", "identifier": "bobsburgers.com", "primary": true}
],
"logos": [
{ "url": "https://bobsburgers.com/logo.svg", "tags": ["icon"] }
],
"colors": { "primary": "#FF6B35" }
}
]
}
```
### Enterprise with Agent
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"brand_agent": {
"url": "https://brand-agent.enterprise.com/mcp",
"id": "enterprise_brand_agent"
},
"contact": {
"name": "Enterprise Brand Team",
"email": "brand@enterprise.com"
}
}
```
### Multi-Brand Portfolio
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"house": {
"domain": "nikeinc.com",
"name": "Nike, Inc.",
"architecture": "hybrid"
},
"brands": [
{
"id": "nike",
"names": [{"en": "Nike"}, {"zh": "耐克"}, {"ja": "ナイキ"}],
"keller_type": "master",
"properties": [
{"type": "website", "identifier": "nike.com", "primary": true},
{"type": "website", "identifier": "nike.cn", "region": "CN"},
{"type": "mobile_app", "store": "apple", "identifier": "com.nike.omega"}
]
},
{
"id": "air_jordan",
"names": [{"en": "Air Jordan"}, {"en": "Jordan"}, {"en": "Jumpman"}],
"keller_type": "endorsed",
"parent_brand": "nike",
"properties": [
{"type": "website", "identifier": "jordan.com", "primary": true},
{"type": "website", "identifier": "jumpman23.com"},
{"type": "mobile_app", "store": "apple", "identifier": "com.nike.snkrs"}
]
},
{
"id": "converse",
"names": [{"en": "Converse"}],
"keller_type": "independent",
"properties": [
{"type": "website", "identifier": "converse.com", "primary": true}
]
}
],
"contact": {
"name": "Nike Brand Team",
"email": "brand@nike.com"
}
}
```
### Talent Agency with Rights
ライセンス可能な権利を持つアスリートブランドを管理するタレントエージェンシー:
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"version": "1.0",
"house": {
"domain": "lotientertainment.com",
"name": "Loti Entertainment",
"architecture": "house_of_brands"
},
"brands": [
{
"id": "daan_janssen",
"names": [{"en": "Daan Janssen"}],
"description": "Dutch Olympic speed skater, 2x gold medalist",
"industries": ["sports"],
"logos": [
{
"url": "https://cdn.lotientertainment.com/janssen/headshot.jpg",
"variant": "primary"
}
],
"brand_agent": {
"url": "https://rights.lotientertainment.com/mcp",
"id": "loti_entertainment"
},
"rights_agent": {
"url": "https://rights.lotientertainment.com/mcp",
"id": "loti_entertainment",
"available_uses": ["likeness", "voice", "endorsement"],
"right_types": ["talent"],
"countries": ["NL", "BE", "DE"]
}
}
]
}
```
`rights_agent` フィールドは、MCP 呼び出しなしにクローラーに何がライセンス可能かを伝えます — 利用可能な用途、権利タイプ、国。バイヤーエージェントは「音声ライセンスに利用可能なオランダのアスリート」をレジストリで検索し、インデックスされた brand.json データからマッチを見つけられます。
### Regional Domain Redirect
`nike.cn/.well-known/brand.json` 上:
```json theme={null}
{
"$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
"house": "nikeinc.com",
"region": "CN"
}
```
## Caching
推奨キャッシュ TTL:
* 正準ファイル: 24 時間
* リダイレクトファイル: 24 時間
* 失敗したルックアップ: 1 時間
## Conformance
これらの不変条件は、バリデーターとクローラーによって強制されなければなりません（MUST）。JSON スキーマはそれらを直接表現できません。
**ポートフォリオ不変条件**
* **`brand_id` のクロス配列一意性。** 特定の `brand_id` は、同じハウスの `brands[]` と `brand_refs[]` の両方に現れてはなりません（MUST NOT）。パブリッシャーは 1 つを選ばなければなりません。
* **`brand_id` の配列内一意性。** 特定の `brand_id` は、同じハウスの `brands[]` 内で一意で、`brand_refs[]` 内で一意でなければなりません（MUST）。
* **`domain` の配列内一意性。** 各 `brand_refs[].domain` は配列内で一意でなければなりません（MUST）。異なる `brand_id` 値で同じドメインを指す 2 つのエントリは未定義です — ハウスごと、ドメインごとに 1 つの正準ポインターしか存在できません。
* **`house_domain` の配置。** `house_domain` は `brands[]` 内のエントリに現れてはなりません（MUST NOT）。それは Brand Canonical Document のトップレベルフィールドです。インライン子は自身の親ポインターを運べません。
**信頼不変条件**
* **相互アサーションが関係信頼のエッジです。** コンシューマーは、一方的なクレームを通じて関係信頼（自動プロビジョニング、メンバー機能継承、課金可能なシート包含）を拡張してはなりません（MUST NOT）。相互アサーション（子の `house_domain` が名付けられたハウスの `brand_refs[]` エントリに一致）が正準の信頼エッジです。
* **アイデンティティは TLS のみ。** リーフブランド自身のアイデンティティ属性（logos、colors、tone、tagline、visual\_guidelines）は、相互アサーション状態に関係なく、リーフの TLS 提供ドキュメントのみに基づいて権威を持ちます。リーフのみの関係クレームはリーフのアイデンティティを無効にしません。
* **ハウス側の House Redirect はたどらなければなりません（MUST）。** 相互アサーションを検証するとき、名付けられたハウスの `brand.json` が House Redirect の場合、コンシューマーは `brand_refs[]` メンバーシップを比較する前にリダイレクトチェーン（3 ホップ制限まで）をたどらなければなりません（MUST）。そうでなければ、買収後のリーフが黙って信頼を失います。
* **スタンドアロンは第三者クレームに勝る。** `house_domain` のない Brand Canonical Document は、それについての任意の第三者ハウスの `brand_refs[]` クレームに関係なく、スタンドアロンです。リーフの沈黙が決定的です。（ここで一度述べられます。他の場所の記述的な文章はこの句に従います。）
* **`managed_by` はディレクトリフィールドであり、信頼フィールドではありません。** コンシューマーは信頼や認可の決定に `managed_by` を使ってはなりません（MUST NOT）。`managed_by` による集計（「BBH が管理するすべてを表示」）が意図された用途です — これは信頼アサーションではなく、ハウス横断の運用ディレクトリです。
**解決不変条件**
* **コンプライアンスフィールドは最も厳格なもの。** ガバナンスフィールド — `data_subject_contestation`、`compliance_policies`、`policy_categories`、オーディエンス除外、規制カテゴリフラグ、およびハウスも公開するブランドレベルの `disclaimers[]` を含む — について、解決される値はハウスレベルとブランドレベルの和集合/最も厳格なものです。ブランドレベルのパブリッシャーは、ハウスレベルのアサーションを弱めることに依存してはなりません（MUST NOT）。これは関係信頼とは異なります — 最も厳格なものは信頼ゲートではなく解決ルールです。
* **エッジエイジング。** 相互アサーションのエッジはエイジングされるべきです（SHOULD）: コンシューマーは、パブリッシャー宣言の `brand_refs[].effective_at`（または、ない場合はコンシューマーの最初の観察）と最後の成功した再検証の間のギャップがコンシューマーの選んだ TTL を超えるとき、エッジを一方的として扱うべきです（SHOULD）。AAO の参照クローラーは 180 日でエイジングします。コンシューマーは異なる選択をしてもかまいません（MAY）。
**自己修復**
* **リーフのみのエッジは通知をトリガーすべきです（SHOULD）。** コンシューマーが X 上の相互エントリなしに `house_domain: X` を主張するリーフに遭遇したとき、コンシューマーは、ハウスチームが相互応答を完了できるよう X の `contact.email` に通知すべきです（SHOULD）。通知する当事者は、フラッディングを避けるために `{leaf, house}` ペアごとにレート制限しなければなりません（MUST）。
* **エージェント強化検証。** 名付けられたハウスが `supported_tasks` で関連する `claim_type`（subsidiary / parent / property / trademark）とともに [`verify_brand_claim`](/docs/brand-protocol/tasks/verify_brand_claim) をアドバタイズするブランドエージェントを公開する場合、コンシューマーは、クロールベースの相互アサーション推論を実行することに加えてエージェントを呼び出すべきです（SHOULD）。信頼モデルは方向によって非対称です: 署名付き `disputed` / `not_ours` は任意の相互応答クレームをオーバーライドします（拒否は一方的）。署名付き `owned` / `pending_review` / `transferring` / `licensed_*` は相互アサーション検証を置き換えません — 相互側が関係信頼を拡張する前に依然として確認しなければなりません。両側がブランドエージェントを持つ場合、相互アサーションは 2 つの署名付きエージェント呼び出し（ハウスの `subsidiary` + リーフの `parent`）を通じて完了します。クロールパスは、エージェントが到達不能または `unknown` を返す場合のフォールバックです。メール通知の SHOULD は、ブランドエージェントのないハウスについて引き続き適用されます。完全な信頼表については [Agent-augmented verification](#agent-augmented-verification) を参照。
## Prior art
相互アサーションの信頼プリミティブは、IAB Tech Lab の [`ads.txt`](https://iabtechlab.com/ads-txt/) と [`sellers.json`](https://iabtechlab.com/sellers-json/) の相互公開モデル — およびパターンがウェブバンドルからモバイルアプリにきれいに移行することを証明した [`app-ads.txt`](https://iabtechlab.com/wp-content/uploads/2019/03/app-ads.txt-v1.0-final-.pdf) 拡張 — を反映しています。バイヤーは、両側が well-known URL で関係を公開する場合にのみ、セラーのリセラーとして信頼されます。同じ信頼形状、同じ非暗号的な「誰が誰について何を主張するか」の検証、部分的な公開に対する同じ一方的/未検証へのフォールバック。デプロイされた耐久性のある業界パターンです。
well-known URL に加えた構造化 JSON リソースディスカバリーの形状は ads.txt より前からあります — IETF の類似物については [WebFinger](https://datatracker.ietf.org/doc/html/rfc7033)（RFC 7033）と [host-meta](https://datatracker.ietf.org/doc/html/rfc6415)（RFC 6415）を参照。`brand.json` は [RFC 8615](https://datatracker.ietf.org/doc/html/rfc8615) を通じてこの慣例を借用します。
AdCP 内では、[プロベナンス検証者コントラクト](https://github.com/adcontextprotocol/adcp/pull/3468)（セラー公開 / バイヤー表明 / セラー確認）が、異なるフィールドファミリーに対して同じ構築ファミリーを使います。
## Best practices
1. **シンプルに始める**: 最小限の brand.json から始め、必要に応じて複雑さを追加する
2. **子会社にはリダイレクトを使う**: ブランドドメインをハウスドメインに指す
3. **すべてのプロパティをリストする**: 地域ドメイン、アプリ、レガシードメインを含める
4. **名前を最新に保つ**: ローカライズされた名前と一般的なエイリアスを含める
5. **ビジュアルガイドラインは任意**: 生成システムにオンブランドのアセットを一貫して生成させる必要があるときに追加する。カラーウェイと restrictions から始める — それらが最も高い即時のインパクトを持つ。
6. **ポートフォリオをリーンに保つ**: 多くのブランドを持つハウスポートフォリオでは、必要なブランドにのみビジュアルガイドラインを含める。大きなポートフォリオのすべてのブランドに完全なビジュアルガイドラインを付けると、ファイルサイズが大幅に増加する。