Skip to main content
バイヤーがオーディエンスの子供構成を 15% で上限設定するとき、しきい値自体はなぜかを説明しません。数字は機械的です。理由（UK HFSS）は別の場所に存在します。帰属なしでは、6 か月後にプロパティリストを読む監査人は、人間の解釈なしに「なぜこのリストは高子供構成プロパティを除外するのか?」に答えられません。 ポリシー帰属はそのギャップを閉じます。プロデューサーはメカニズムレベルのフィルターと測定を policy_id でタグ付けし認可ポリシーを記録します。ガバナンス発見は拒否を発行するとき同じ policy_id をエコーするため、トレースはエンドツーエンドで走ります。

​
3 つの表面、1 つのパターン

3 つのフィールドすべてがオプションです。最初の 2 つは 3.0 GA で予約されました。3.1 でそれらを投入することは厳格な 3.0 検証者にとって非破壊的です。3 番目は 3.0 以来 validation-result に存在します。

​
policy_id をいつ投入するか

フィルターまたは測定が特定の認可ポリシーのために存在する — そしてプロデューサーがそのポリシーのエンコーディングとして特定のメカニズムを選んだ — とき policy_id を投入します。 ポリシーが単に一般的に適用されるとき policy_id を投入 しません。プランレベルのポリシー適用性は、プラン自体で policy_ids[] 経由で宣言されます（sync_plans を通じてバイヤーのガバナンスエージェントに送られる）。フィルターレベルフィールドはメカニズムの著作者であり、一括適用性ではありません。

​
プランレベル対フィルターレベル

これらは異なる仕事です: 3 番目の行のみがフィルターレベル policy_id を運びます。最初の 2 行は既により高い抽象化レベルで意図を捕捉しています — 2 番目のケースではレジストリフィーチャー ID 自体がポリシー参照です。

​
ガバナンス発見経由のラウンドトリップ

帰属ループは filter → ガバナンスエージェント → finding → audit と走ります。バイヤーのプランで動作するエージェントは check_governance を呼びます。phase に応じて、これは 意図チェック（オーケストレーター側、コミット前）または 実行チェック（セラー側、計画された配信のバインド前）のいずれかです。両パスは同じ形状の発見を生成します。
動作するエージェント（フェーズに応じてオーケストレーターまたはセラー）は通過点です — それは発見を生成しません。バイヤーのガバナンスエージェントがプロデューサーで、バイヤーのフィルターに直接アクセスできます（同じ信頼境界）ので、基盤となる要件を読むことで発見に policy_id を投入できます。

​
プロデューサーのコントラクト

feature-requirement を作成するバイヤー（またはバイヤーのコンプライアンスツール）:
  • 要件がバイヤーが選んだ特定のポリシーしきい値をエンコードするとき policy_id を投入すべき（SHOULD）。
  • 要件が任意のポリシーと無関係な一般的フィーチャーフィルターのとき policy_id を投入すべきでない（SHOULD NOT）。
  • ポリシーレジストリまたはプランの custom_policies[] のいずれかで解決する policy_id を参照しなければならない（MUST）。
creative-feature-result を作成するクリエイティブエージェントまたはセラー:
  • フィーチャーが特定のポリシー評価の目的で測定されたとき policy_id を投入すべき（SHOULD）。
  • フィーチャーが任意のポリシーと無関係な汎用測定（カーボンスコア、ブランド一貫性）のとき policy_id を投入すべきでない（SHOULD NOT）。
発見を発行するガバナンスエージェント:
  • 基盤となる違反が policy_id を運ぶフィルターまたは測定に遡るとき、発見で policy_id をエコーすべき（SHOULD）。
  • 元のフィルターに存在しなかった policy_id を発明してはならない（MUST NOT） — 発見 policy_id は追跡可能性のためで、新しいポリシー適用性を宣言するためではない（それは policies_evaluated[] に属する）。

​
実例

​
UK HFSS — バイヤーエンコードのしきい値

バイヤーのコンプライアンスチームは UK HFSS を「オーディエンスは 15% 未満の子供でなければならない」と解釈します。彼らはその解釈をフィーチャー要件としてエンコードします:
別のチームが後で「なぜ 15? なぜ 20 ではない?」と尋ねる場合、policy_id は根拠と事例が存在する UK HFSS のレジストリエントリーを指します。

​
COPPA — セラーのレジストリフィーチャーに委譲

バイヤーは COPPA のしきい値を選びません — 評価を完全に委譲します。registry: プレフィックスはフィーチャー命名規約（property-feature-definition と ポリシーレジストリ を参照）で、フィーチャー ID registry:<policy_id> が標準化されたポリシーを直接参照します:
フィーチャー ID が ポリシー参照です。ここに policy_id: "us_coppa" を追加することは冗長で — 実際には委譲したのにバイヤーがメカニズムを作成したことを含意します。

​
クリエイティブ測定 — エージェントが理由を記録

クリエイティブエージェントがクリエイティブを HFSS コンプライアンスについて評価し記録します:
policy_id は「なぜこの評価が実行されたか?」に答えます。クリエイティブの測定履歴をレビューする誰でも、この結果を元のポリシーと相関できます。 この結果がクリエイティブレベルのガバナンスチェックを失敗すると、ガバナンスエージェントの発見は同じ policy_id をエコーします:
バイヤーは両レコード全体で policy_id を一致させることで発見を元の測定に相関できます。

​
帰属がカバーしないもの

  • バイヤーからセラーへのトップダウンポリシー宣言。 バイヤーがメカニズムをエンコードせずにセラーにポリシーの専門的処理（HIPAA ベンダー、COPPA データセット）を適用してほしいとき、それは #4629 で追跡される別の表面です。
  • オーディエンスセレクターの基準ごと帰属。 プランのオーディエンス除外はバイヤーのガバナンスエージェントによってプランレベルの policy_ids[] から導出されるべきで — バイヤーが手作成しポリシー権威でタグ付けするのではありません。オーディエンスセレクタースキーマは policy_id を運びません。
  • ターゲティングオーバーレイの基準ごと帰属。 ターゲティングフィールド（geo_countries_exclude、年齢制限、デバイスプラットフォーム）はエントリーごとの形状なしのフラット配列を使います。基準ごと帰属はスキーマ再構築を要求します。これらの制約にはプランレベル宣言を使います。

​
関連項目