プランにポリシーバージョンをピン留めできるか?
いいえ —policy_ids[] は今日バージョン修飾子を運びません。 キャンペーンプランは ID のみでレジストリポリシーを参照します:
check_governance 呼び出しで、ガバナンスエージェントは各 ID をレジストリに対して解決し、現在のバージョンが何であれ それを使います。プランレベルのバージョンピンフィールドはありません。同じプランの 2 つのチェック間でレジストリポリシーがバージョンバンプする場合、2 番目のチェックは新しいバージョンに対して評価します。
バイの期間中に決定的なポリシーテキストが必要な場合、レジストリポリシーをプランの custom_policies[] にコピーします — 下の Pinning by inline copy を参照。監査証跡はすべてのチェックで policies_evaluated[] を記録するため、履歴バージョンは /api/policies/history 経由でチェックごとに回復可能です。
これは他のアドテックプロトコル（TCF v2 の TC 文字列、OpenRTB GPP）が取る同じ姿勢です — バージョンはリクエスト作成時ではなく評価時に解決します。解決時最新が正しい 99% のケースで、バイヤーをバージョン依存管理ビジネスから外し続けます。
Pinning by inline copy
決定的なポリシーテキストが必要なとき — 規制当局の事前クリアランス、凍結されたブランドセーフティ契約、初日のポリシーに対して評価されなければならない複数月のブランドキャンペーン — 利用可能なパターンは、プラン作成時に 異なるpolicy_id の下でレジストリポリシーを custom_policies[] にコピーすることです:
policy_id を使ってください。 バイヤーが custom_policies で正準 ID alcohol_advertising を再利用する場合、ガバナンスエージェントの動作は仕様で未定義です — policy-entry スキーマ の追加のみルールは、その ID についてレジストリテキストを権威的としてピン留めします。alcohol_advertising_pinned_2026Q4（またはあなたの内部バージョニング規約）のようなピン留め ID はコンフリクトを回避します。
プランリビジョンは今や凍結されたテキストを運びます。インラインポリシーの version フィールドは情報的です — テキストが評価されるものです — が、監査人がインラインコピーを特定のレジストリリリースに相関できるようフォレンジックな追跡可能性のため設定する価値があります。
ライフサイクル。 インラインコピーは、バイヤーがプランの各再同期で custom_policies にエントリーを保つ限り保持されます。ガバナンスエージェントの追加のみ revisionHistory は監査のため以前のプランリビジョンをアーカイブしますが、ライブ評価は常に最新の sync_plans ペイロードにあるものを使います — したがって再同期でインラインポリシーを落とすバイヤーは次のチェックでピンを失います。
トレードオフ。 ピン留めされたポリシーはレジストリ訂正を拾いません。alcohol_advertising v2.2.0 が明確化を出荷する場合、ピン留めされたプランは誰かが手動で新しいテキストで custom_policies を再同期するまで v2.1.0 に対して評価し続けます。それが安定性の代償です。
インラインポリシーはレジストリに対して追加のみ
インラインcustom_policies[] は policy-entry スキーマ からのハードな不変条件を運びます: それらはレジストリソースのポリシーの上に制限を 追加 することのみできます。インラインポリシーは、レジストリポリシーの enforcement レベルを緩和したり、レジストリポリシーが義務付けるカテゴリーを免除したり、そうでなければレジストリベースラインを弱めたりしてはなりません（MUST NOT）。任意のレジストリポリシーと交差しないバイヤー作成のインラインポリシーは制約されません — レジストリポリシーとの関係のみが統制されます。
具体的には、policy_ids: ["us_coppa"] と custom_policies エントリーの両方を持つプランを評価するガバナンスエージェントは、us_coppa をピン留めまたは拡張できます（例: リネームされた ID の下のブランド固有事例セット）が、「このキャンペーンでは COPPA を無視」と言うインラインポリシーを追加できません。監査エントリーで policies_evaluated: ["us_coppa"] を見る相手方は、したがってレジストリバージョンの us_coppa が宣言された must レベルで適用されたことを信頼できます — バイヤーは黙ってそれをダウングレードしませんでした。
これを検証したい相手方は、プランリビジョンをリクエストし plan_hash を再計算できます（キャンペーンガバナンス仕様）。プランバインディングは、追加のみ不変条件を単に宣言されたものではなく検証可能にする暗号表面です。エージェント側の強制はダウングレードが起こることを防ぐものです。ハッシュは事後に決定を証明可能にするものです。
キャンペーン中のレジストリバージョンバンプの処理
プランがアクティブな間にレジストリポリシーがバージョンバンプするとき:
完了したバイのバージョン安定性を気にするバイヤーは何もする必要はありません — 監査証跡が評価されたものを捕捉します。アクティブな飛行中の バイの安定性を気にするバイヤーはインラインコピーパターンを使うべきです。
段階的採用のための effective_date
「最初は最小限の制限」パターンは、プランごとの設定ではなくレジストリの文書化された動作です。ガバナンスエージェントは、ポリシー ID を参照するすべてのプランにわたって effective_date を自動的に尊重します:
- Day 0 — コミュニティがドラフトポリシーに合意。将来 60 日以上の
effective_dateでレジストリに公開。 - Day 0–60 — ポリシー ID を参照する任意のプランを評価するすべてのガバナンスエージェントが情報的発見を発行。バイヤーとセラーは何がフラグされたはずかを正確に見る。バイはブロックされない。
- Day 60 —
effective_dateが経過。同じ評価が今やポリシーの宣言されたenforcementレベルでブロック。任意のプランで設定変更不要。 - Day 60+ — 段階的採用ウィンドウのバイヤーは、在庫とクリエイティブを調整する 2 か月のテレメトリーを持っていた。遅い開始者はハードなカットオーバーを得る。
effective_date は段階的採用の時間軸です。スコープベースの段階化 — チャネル、管轄、policy_categories サブセットによるフェーズ — はレジストリレベルで行われる別の動きです: まず狭い管轄または狭いカテゴリーのポリシーを公開し、次により広いものを公開。2 つの軸は合成します。単一のポリシーがスコープ狭窄と時間段階化ウィンドウに同時に存在できます。
サンセット動作
レジストリポリシーがそのsunset_date に到達すると、ガバナンスエージェントは後続のチェックでそれの評価を停止します。policies_evaluated[] にポリシーを記録した既存の監査エントリーは変わりません — 証跡はいつ何が評価されたかについて真実を伝えます。バイヤーからのアクションは不要です。サンセットされたポリシーはすべてのアクティブプランから自動的に脱落します。
サンセットされたポリシーが後継に置き換えられる場合（例: ある規制が別のものに取って代わる）、レジストリコントリビューターは両方を公開します: sunset_date が設定された古いエントリー、effective_date が設定された新しいエントリー。バイヤーは次のプランリビジョンで新しいエントリーを参照するよう policy_ids[] を更新します — 古い ID はそのサンセット日まで評価し続け、その後静かに停止します。
よくある質問
キャンペーン中に規制が変わるとき飛行中のバイに何が起こるか? キャンペーン中のレジストリバージョンバンプの処理 の下のテーブルが答えです。短縮版: コミットされたバイはコミットされたまま。次のチェックが現在のものを解決。custom_policies 経由のピン留めが特定のテキストを凍結する方法です。
新しい objective を追加するときプランは再評価するか? プランリビジョン（監査ログエントリーの plan_version、プランが再同期するたびに記録）はそれ自体で解決されたポリシーテキストをリフレッシュしません — 次の check_governance は依然として構成されたとおりレジストリにヒットします。リビジョンでポリシーテキストをリフレッシュするには、新しいプランリビジョンで policy_ids[]（または custom_policies のインラインコピー）を変更します。
どのバージョンが適用されたかを相手方にどう証明するか? 3 つの層: (1) セラーの governance_context トークンが特定のチェックを相関、(2) そのチェックの監査ログエントリーが policies_evaluated[] と plan_hash を運ぶ、(3) レジストリの /api/policies/history エンドポイントが任意の policy_id の完全なリビジョンシーケンスを返すため、監査人はどのバージョンが履歴タイムスタンプでアクティブだったかをリプレイできます。
管轄ごとのオーバーライド。 グローバル標準と管轄固有の締め付けの両方を宣言（例: policy_ids: ["alcohol_advertising", "alcohol_advertising_norway"]）。ガバナンスエージェントは両方を評価。追加のみルールは 2 つのうちより制限的なものが勝つことを意味します。
ブランド固有拡張。 共有レジストリに属さないルール（競合排除、ブランドボイスガイドライン、内部コンプライアンスフレームワーク）には custom_policies[] を使います。policy_ids[] と並んでそれらを参照します。
関連
- ポリシーレジストリ — レジストリ概念、ポリシー構造、シードされたポリシー、制限属性
- キャンペーンガバナンス仕様 — プランバインディング、
plan_hash、ガバナンスコンテキストライフサイクル - 監査証跡: 内部対共有可能ビュー — 評価履歴を相手方に表示する方法
sync_plans—policy_ids、policy_categories、custom_policies- Annex III と Art 22 の義務 — 人間レビューがいつ必要か