> ## 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.

# Property Governance Specification

> AdCP プロパティガバナンスの正式仕様 — プロパティモデル、フィーチャー評価、リスト管理、配信検証。

<Info>
  **AdCP 3.0 提案** - この仕様は AdCP 3.0 向けに開発中です。フィードバックは [GitHub Discussions](https://github.com/adcontextprotocol/adcp/discussions) へどうぞ。
</Info>

**Status**: Request for Comments
**Last Updated**: January 2026

本文書における「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) の定義に従って解釈します。

## Abstract

Property プロトコルは、プロパティの識別・認可・データ提供・選定のための標準 MCP/A2A インターフェースを定義します。これにより、パブリッシャーはプロパティと認可エージェントを宣言し、データプロバイダーはプロパティインテリジェンスを提供し、バイヤーは準拠したプロパティ集合を選択できます。

## 概要

The Property Protocol addresses four distinct concerns:

| Concern                 | Question          | Owner          | Mechanism                              |
| ----------------------- | ----------------- | -------------- | -------------------------------------- |
| **Property Identity**   | どのプロパティが存在するか     | Publishers     | `adagents.json` の properties 配列        |
| **Sales Authorization** | 誰がこのプロパティを販売できるか  | Publishers     | `adagents.json` の authorized\_agents   |
| **Property Data**       | このプロパティについて何がわかるか | Data providers | `get_adcp_capabilities` 経由のガバナンスエージェント |
| **Property Selection**  | 要件を満たすプロパティはどれか   | Buyers         | フィルター付きプロパティリスト                        |

最初の 2 つは adagents.json による **パブリッシャー側の宣言**、後ろの 2 つはガバナンスエージェントのデータを用いる **バイヤー側の処理** です。

### プロパティデータと選定

プロパティデータと選定は **ステートフル** モデルです:

* **Feature discovery**: Agents advertise what they can evaluate via `get_adcp_capabilities`
* **Property list management**: CRUD operations for managed property lists with filters
* **Brand references**: Let agents automatically apply rules based on brand identity
* **Webhook notifications**: Real-time updates when resolved lists change
* **Marketplace architecture**: Multiple specialized agents as subscription services

すべての評価（スコアリング、フィルタリング、ディスカバリ）は `get_property_list` でリストが解決されるときに暗黙的に行われます。

## コア概念

### リクエストの役割と関係

Every governance request involves two key roles:

#### Orchestrator (Buyer Agent)

ガバナンスエージェントへ API リクエストを送るプラットフォーム/システム。メディアバイ文脈ではしばしば「buyer agent」と呼びます。

* **Examples**: DSP、トレーディングデスク、キャンペーン管理ツール
* **Responsibilities**: API 呼び出し、認証、技術的なやり取りを管理
* **Account**: ガバナンスエージェントへの技術的な資格情報と API アクセスを持ちます

#### Principal

リクエストを代理している主体:

* **Examples**: 広告主（Nike）、代理店（Omnicom）、ブランドチーム
* **Responsibilities**: キャンペーン目標やポリシー要件の所有者
* **Policies**: 独自の閾値、ブロックリスト、コンプライアンス要件を持つ場合があります

### プロパティ識別

Properties are identified using the standard AdCP property model:

```json theme={null}
{
  "property_type": "website",
  "name": "Example News",
  "identifiers": [
    { "type": "domain", "value": "example.com" }
  ],
  "supported_channels": ["display", "olv"]
}
```

プロパティタイプ: `website`, `mobile_app`, `ctv_app`, `dooh`, `podcast`, `radio`, `streaming_audio`。プロパティは `supported_channels` を宣言して在庫が対応する広告チャネルを示してもよい。

### プロパティリスト参照

For large property sets, use property list references instead of embedding properties:

```json theme={null}
{
  "property_list_ref": {
    "agent_url": "https://lists.example.com",
    "list_id": "premium_news_sites",
    "auth_token": "eyJhbGciOiJIUzI1NiIs..."
  }
}
```

受信側エージェントがリストを取得・キャッシュすることで実現:

* **スケール**: ペイロード肥大化なしに 50,000 件以上のプロパティを扱える
* **更新**: リクエストを変えずにリストを進化させられます
* **認可**: トークンでリストへのアクセスを制御

### ガバナンスエージェントの種類

#### Compliance Agents

プロパティのコンプライアンスインテリジェンスを提供するベンダー:

* **Examples**: データ整合性スコア、同意品質の測定
* **Business Model**: サブスクリプションまたは従量課金
* **Methodology**: 透明性のための公開ルーブリック

#### Brand Safety Agents

コンテンツ分類とリスク評価:

* **Examples**: コンテンツカテゴライズ、ブランドセーフティスコアリング
* **Coverage**: チャンネルや地域に特化する場合があります

#### Quality Agents

パフォーマンスと不正計測:

* **Examples**: Viewability 予測、IVT 検知
* **Integration**: キャンペーン成果と相関させる場合があります

### スコアリングとデータプライバシー

#### スコアは内部のみ

**重要な設計原則**: 生のスコアはバイヤーや下流クライアントに共有しません。データ漏洩を防ぎます。

ガバナンスエージェントは内部スコアモデルを保持しますが、プロトコルはスコアを露出させず **リスト管理** を中心に設計されています:

* Buyers specify **thresholds** via `feature_requirements` (e.g., `"min_value": 85`)
* Agents return **pass/fail lists** of properties that meet the thresholds
* Raw scores never leave the governance agent

この設計により以下を防ぎます:

* スコア逆算のための列挙攻撃（閾値を変えたリスト要求など）
* 競合インテリジェンスの漏洩
* スコアデータの転売によるアービトラージ

#### バイヤーが受け取るもの

When calling `get_property_list`, buyers receive a compact list of identifiers (not full property objects) for efficiency:

```json theme={null}
{
  "list_id": "pl_abc123",
  "identifiers": [
    { "type": "domain", "value": "bbc.co.uk" },
    { "type": "domain", "value": "theguardian.com" },
    { "type": "domain", "value": "ft.com" }
  ],
  "total_count": 847
}
```

閾値を通過したプロパティのみが含まれ、落ちたプロパティは除外されます。スコアやメタデータは返さず、入札時参照に必要な識別子のみを返します。

#### メソドロジーの開示

The `get_adcp_capabilities` task returns information about what features an agent evaluates and their methodology, but NOT the underlying scores:

```json theme={null}
{
  "features": [
    {
      "feature_id": "mfa_score",
      "name": "Made For Advertising Score",
      "type": "quantitative",
      "range": { "min": 0, "max": 100 },
      "methodology": "mfa_detection",
      "methodology_version": "v2.1",
      "methodology_url": "https://quality.example.com/methodology"
    }
  ]
}
```

これによりバイヤーは:

* エージェントが何を測っているか把握
* エージェント間でメソドロジーを比較
* 適切な閾値を設定

ただし個々のプロパティの実スコアを取得することはできません。

## タスク

### ディスカバリ

#### get\_adcp\_capabilities

ガバナンスエージェントが評価できる機能を発見します。

**ユースケース**:

* 機能ディスカバリ: 何を評価できるか把握
* マーケットプレイス閲覧: エージェント間で機能比較
* 統合計画: リスト作成前に利用可能なフィルターを把握

### プロパティリスト管理

#### create\_property\_list

フィルターと任意の Brand Manifest を伴うプロパティリストを新規作成します。

**必須パラメータ**:

* `countries_all` に少なくとも 1 つの国（ISO 3166-1 alpha-2）
* `channels_any` に少なくとも 1 つのチャネル（display, video, audio など）

**Base Properties**: 評価対象となるプロパティソースの配列。各要素は `selection_type` を識別子とする判別可能ユニオンです:

* **`publisher_tags`**: `{ "selection_type": "publisher_tags", "publisher_domain": "...", "tags": [...] }` - パブリッシャー内のタグ
* **`publisher_ids`**: `{ "selection_type": "publisher_ids", "publisher_domain": "...", "property_ids": [...] }` - パブリッシャー内の property\_id
* **`identifiers`**: `{ "selection_type": "identifiers", "identifiers": [...] }` - パブリッシャーコンテキスト不要
* **Omitted**: エージェントのプロパティ DB 全体を参照

[base-property-source schema](https://adcontextprotocol.org/schemas/v2/property/base-property-source.json) で完全な仕様を確認してください。

**フィルタロジック**（フィールド名に明示）:

* `countries_all`: 指定されたすべての国のフィーチャーデータが必要（AND）
* `channels_any`: 指定されたチャネルのいずれかをサポートしていれば可（OR）
* `feature_requirements`: すべての要件を満たす（AND）

**ユースケース**:

* フィルター（国、チャネル、フィーチャー閾値）で準拠リストを定義
* Brand Manifest を渡してルールを自動適用
* 変更通知用の Webhook を登録

#### update\_property\_list

既存のプロパティリストを更新します。

**ユースケース**:

* ベースリストにプロパティを追加/削除
* キャンペーン要件に応じてフィルター調整
* Webhook URL の更新

#### get\_property\_list

解決済みプロパティリストを取得します。

**ユースケース**:

* フィルター適用後の準拠リストを取得
* 入札時利用のためリストをキャッシュ
* Webhook 通知後に更新版を取得

#### list\_property\_lists

認証済みプリンシパルがアクセスできるプロパティリストを列挙します。

#### delete\_property\_list

プロパティリストを削除します。

### Validation

#### validate\_property\_delivery

配信記録をプロパティリストに照らして準拠性を判定し、「意図」と「結果」を突き合わせます。

独立した 2 つの検証を行います:

1. **プロパティ準拠**: 識別子が解決済みリストに含まれるか
2. **サプライパス認可**: セールスエージェントがそのプロパティを販売する権限を持つか（任意、`sales_agent_url` が必要）

**ユースケース**:

* ポストキャンペーン検証: インプレッションが準拠プロパティに配信されたか確認
* サプライパス検証: セールスエージェントがパブリッシャーに認可されているか確認
* リアルタイム監視: 実行中キャンペーンの準拠率を確認
* 監査証跡: 規制/ブランドセーフティ審査向けにレポート生成

**プロパティ検証ステータス**:

* `compliant`: 識別子が解決済みリストに含まれます
* `non_compliant`: 識別子が解決済みリストに含まれない
* `not_covered`: 識別子は認識したが当該プロパティのデータがない（新規など）
* `unidentified`: このエージェントでは解決できない識別子（検出失敗・非対応）

**認可検証ステータス**（`sales_agent_url` を提供した場合）:

* `authorized`: セールスエージェントが adagents.json に記載されています
* `unauthorized`: authorized\_agents に記載されていません
* `unknown`: adagents.json を取得/解析できません

**検証不能レコード**: `not_covered` と `unidentified` は準拠率計算から除外すべきです。データカバレッジの不足と識別子解決の問題を区別できます。

**レスポンス形式**: 準拠/非準拠/not\_covered/unidentified の生カウントを返します。必要に応じてクライアントサイドで率を計算します。オプションで `aggregate` フィールドに算出指標（スコア、グレード、ラベルなど）を含めることもできます（フォーマットはエージェント依存）。

## Typical Flows

### Property List Flow

Property lists enable buyers to define and manage compliant property sets:

1. **Create property list**: Buyer defines list on governance agent with filters
2. **Resolve and iterate**: Buyer calls `get_property_list` to see resolved properties
3. **Share list reference**: Buyer provides `list_id` to orchestrator/seller
4. **Cache locally**: Orchestrator/seller fetches and caches resolved properties
5. **Use at bid time**: Orchestrator/seller uses local cache (no governance agent calls)
6. **Refresh periodically**: Re-fetch based on `cache_valid_until` (typically 1-24 hours)

**Important**: Governance agents are NOT in the real-time bid path. All bid-time decisions use locally cached property sets.

### Webhook and Caching Pattern

Webhooks provide **notification** that a property list has changed. The webhook payload contains a summary of changes, but you must call `get_property_list` to retrieve the actual updated properties.

```
┌─────────────────────────────────────────────────────────────────┐
│                     Webhook Flow                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. Governance agent re-evaluates properties (background)       │
│  2. Webhook fires with change summary (added/removed counts)    │
│  3. Recipient calls get_property_list to fetch updated list     │
│  4. Recipient updates local cache                               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

**Best Practices for Downstream Consumers**:

Consumers of property lists (orchestrators, sellers, buyer agents) should implement **at least one** of these patterns:

1. **Webhook-driven updates** (recommended): Register a webhook URL when creating the property list. Re-fetch via `get_property_list` when notified of changes.

2. **Polling with cache hints**: Use `cache_valid_until` from `get_property_list` responses to schedule periodic re-fetches. Typical validity periods are 1-24 hours.

3. **Hybrid approach**: Use webhooks for immediate updates, with polling as a fallback safety net.

**Cache Expiry Guidance**:

Every `get_property_list` response includes:

* `resolved_at`: When the list was evaluated
* `cache_valid_until`: When consumers should consider the cache stale

```json theme={null}
{
  "resolved_at": "2026-01-04T10:00:00Z",
  "cache_valid_until": "2026-01-04T22:00:00Z"
}
```

Consumers MUST NOT use cached data beyond `cache_valid_until` without re-fetching.

### Property Discovery Flow

1. **Define filters**: Specify country, channel, quality thresholds when creating property list
2. **Resolve list**: Call `get_property_list` with `resolve=true` to get matching properties
3. **Review candidates**: Evaluate returned properties for fit
4. **Add to campaign**: Include property list reference in media buy

## Response Structure

All AdCP Governance responses follow a consistent structure:

### Core Response Fields

* **message**: Human-readable summary of the operation result
* **context\_id**: Session continuity identifier for follow-up requests
* **data**: Task-specific payload (varies by task)

### Protocol Transport

* **MCP**: Returns complete response as flat JSON object
* **A2A**: Returns as structured artifacts with message in text part, data in data part
* **Data Consistency**: Both protocols contain identical AdCP data structures

## Error Handling

### Error Codes

* `PROPERTY_NOT_FOUND`: Property identifier not recognized
* `PROPERTY_NOT_MONITORED`: Governance agent doesn't cover this property
* `POLICY_NOT_FOUND`: Referenced policy doesn't exist
* `LIST_ACCESS_DENIED`: Cannot access property list (auth failed)
* `LIST_NOT_FOUND`: Property list reference invalid
* `METHODOLOGY_NOT_SUPPORTED`: Requested methodology version unavailable
* `PARTIAL_RESULTS`: Some properties couldn't be evaluated

### Partial Success

For bulk operations, the response may include partial results:

```json theme={null}
{
  "message": "Evaluated 847 of 850 properties. 3 properties not in coverage.",
  "context_id": "ctx-gov-123",
  "scores": [...],
  "errors": [
    {
      "code": "PROPERTY_NOT_MONITORED",
      "property": { "identifiers": [{ "type": "domain", "value": "unknown.com" }] },
      "message": "Property not in monitoring coverage"
    }
  ]
}
```

## Implementation Notes

### Caching Architecture

Governance decisions are highly cacheable:

#### Orchestrator-Side Caching

* **Score cache**: Store scores with TTL from `valid_until` field
* **Decision cache**: Pre-compute pass/fail for campaigns
* **List cache**: Cache property lists from `property_list_ref`

#### Agent-Side Caching

* **Profile cache**: Maintain pre-computed property profiles
* **Methodology cache**: Cache scoring algorithm results

### Performance Requirements

| Operation                     | Target Latency |
| ----------------------------- | -------------- |
| Single property score         | \< 100ms       |
| Bulk scoring (100 properties) | \< 2s          |
| Filter decision (cached)      | \< 5ms         |
| Property discovery            | \< 5s          |

### Multi-Agent Strategies

Orchestrators may consult multiple governance agents:

1. **Primary + Validation**: Use primary agent, validate with secondary
2. **Specialization**: Route by property type to specialist agents
3. **Consensus**: Require multiple agents to agree
4. **Competitive**: Track agent accuracy, weight by performance

## Agent Discovery

There are two complementary discovery mechanisms:

### Publisher-Side Discovery via adagents.json

Publishers declare which governance agents have data about their properties using the `property_features` field in `adagents.json`:

```json theme={null}
{
  "property_features": [
    {
      "url": "https://api.scope3.com",
      "name": "Scope3",
      "features": ["carbon_score", "sustainability_grade"],
      "publisher_id": "pub_12345"
    },
    {
      "url": "https://api.onetrust.com",
      "name": "OneTrust",
      "features": ["gdpr_compliant", "tcf_registered", "ccpa_compliant"]
    }
  ]
}
```

This solves the discovery problem: buyers don't need to query every possible governance agent. Instead, they read `property_features` from the publisher's adagents.json to find which agents have relevant data.

See the [adagents.json Tech Spec](/docs/governance/property/adagents#governance-agent-discovery) for the complete discovery workflow.

### Agent-Side Discovery via agent-card.json

Governance agents expose capabilities via `.well-known/agent-card.json`:

```json theme={null}
{
  "name": "Example Compliance Provider",
  "url": "https://compliance.example.com",
  "capabilities": {
    "tasks": [
      "get_adcp_capabilities",
      "create_property_list",
      "get_property_list",
      "update_property_list",
      "delete_property_list",
      "list_property_lists",
      "validate_property_delivery"
    ],
    "protocols": ["MCP", "A2A"],
    "schema_version": "v1"
  },
  "methodology": {
    "documentation_url": "https://compliance.example.com/methodology",
    "scoring_frameworks": ["data_integrity_index", "brand_safety_score"],
    "coverage": {
      "property_types": ["website", "mobile_app", "ctv_app"],
      "jurisdictions": ["GDPR", "CCPA", "COPPA"]
    }
  }
}
```

### Detailed Capability Discovery

Use `get_adcp_capabilities` for detailed capability discovery:

```json theme={null}
{
  "tool": "get_adcp_capabilities",
  "arguments": {}
}
```

Returns the specific features the agent can evaluate (consent\_quality, carbon\_score, brand\_risk, etc.).

## Marketplace Architecture

The Property Protocol enables a marketplace of specialized data agents:

```
┌─────────────────────────────────────────────────────────────────────────┐
│                         SELLER AGENT (DSP/SSP)                          │
│  "Give me the compliant property list for this campaign"                │
└───────────────────────────────┬─────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                    BUYER AGENT (implements Property Protocol)           │
│  - Exposes: get_adcp_capabilities, get_property_list, webhooks         │
│  - Source of truth for final compliant list                             │
│  - Intersects results from specialized agents                           │
└───────────────────────────┬─────────────────────────────────────────────┘
                            │
        ┌───────────────────┼───────────────────┐
        ▼                   ▼                   ▼
┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│ Consent Agent │   │ Scope3 Agent  │   │ Brand Safety  │
│ (Compliant)   │   │               │   │    Agent      │
├───────────────┤   ├───────────────┤   ├───────────────┤
│ Features:     │   │ Features:     │   │ Features:     │
│ consent_qual  │   │ carbon_score  │   │ content_cat   │
│ tcf_version   │   │ climate_risk  │   │ brand_risk    │
│ coppa_cert    │   │ green_host    │   │ sentiment     │
├───────────────┤   ├───────────────┤   ├───────────────┤
│ Subscription  │   │ Subscription  │   │ Subscription  │
└───────────────┘   └───────────────┘   └───────────────┘
```

### Key Principles

1. **Buyer agent is source of truth**: The buyer agent aggregates data from multiple specialized governance agents
2. **Seller sees one interface**: Sellers interact only with the buyer agent using standard Property Protocol
3. **Subscription model**: Each specialized agent is a paid service with its own features and coverage
4. **Webhook-driven updates**: Specialized agents notify the buyer agent when property evaluations change

### Multi-Agent Orchestration

A buyer agent can distribute a master property list to multiple specialized agents:

```python theme={null}
# Buyer agent creates variants on each specialized agent
consent_list = consent_agent.create_property_list(
    name="Q1 Campaign - Consent",
    base_properties=master_list,
    brand=brand
)
# Configure webhook for updates
consent_agent.update_property_list(
    list_id=consent_list.list_id,
    webhook_url="https://buyer.example.com/webhooks/consent"
)

scope3_list = scope3_agent.create_property_list(
    name="Q1 Campaign - Sustainability",
    base_properties=master_list,
    brand=brand
)
scope3_agent.update_property_list(
    list_id=scope3_list.list_id,
    webhook_url="https://buyer.example.com/webhooks/scope3"
)

# Buyer agent intersects filtered results
def on_list_changed(event):
    consent_props = consent_agent.get_property_list(consent_list.list_id, resolve=True)
    scope3_props = scope3_agent.get_property_list(scope3_list.list_id, resolve=True)

    # Intersection = properties that pass ALL governance agents
    compliant_props = intersect(consent_props, scope3_props)

    # Update buyer agent's exposed list
    update_compliant_list(compliant_props)
```

### Brand

複雑なフィルターを指定する代わりに、バイヤーはブランド参照を提供します:

```json theme={null}
{
  "brand": {
    "domain": "toybrand.com"
  }
}
```

各ガバナンスエージェントはブランドのアイデンティティを解決し、専門領域に応じてルールを適用します:

* **Consent agent**: 子ども向けブランドに対して COPPA 要件を適用
* **Brand safety agent**: 適切なコンテンツにフィルタリング、暴力/アダルトを除外
* **Sustainability agent**: グリーンメディア要件を適用

バイヤーは具体的なルールを知る必要がなく、自分が誰かを宣言すれば、エージェントが何を適用するかを判断します。

## Integration with Media Buy Protocol

### Property Lists in Media Buys

The Media Buy Protocol accepts property list references:

```json theme={null}
{
  "task": "create_media_buy",
  "arguments": {
    "packages": [{
      "property_list_ref": {
        "agent_url": "https://governance.example.com",
        "list_id": "approved_q1_campaign",
        "auth_token": "..."
      }
    }]
  }
}
```

### Policy Compliance

Media buys can reference governance policies via property list references:

```json theme={null}
{
  "compliance_requirements": {
    "property_list_ref": {
      "agent_url": "https://compliance.example.com",
      "list_id": "pl_q1_compliant",
      "auth_token": "eyJhbGciOiJIUzI1NiIs..."
    }
  }
}
```

## Best Practices

1. **Cache aggressively**: Property scores change slowly; cache for hours/days
2. **Bulk where possible**: Use batch operations for planning, not per-property calls
3. **Pre-compute decisions**: Build pass/fail lookups before bid-time
4. **Monitor coverage**: Track which properties agents don't cover
5. **Log methodology versions**: For audit trails, record which scoring version was used
6. **Handle partial results**: Not all properties will be scorable; plan for gaps

## Next Steps

* See the [adagents.json Tech Spec](/docs/governance/property/adagents) for property declaration and authorization
* See the [get\_adcp\_capabilities task reference](/docs/protocol/get_adcp_capabilities) for capability discovery
* See the [Property List Management](/docs/governance/property/tasks/property_lists) for CRUD operations and webhooks
* See the [validate\_property\_delivery task reference](/docs/governance/property/tasks/validate_property_delivery) for post-campaign compliance validation