build_creative は、バイヤーがビルドに添付する入力を受け入れます: 選択されたビルドケイパビリティ、レンダー構成、そして時とともにバイヤーが生成に尊重させたいコンテキストへのポインター。このページは、それらの入力が共有するコントラクトを定義し、各新しいポインターがガバナンスを再議論するのではなくそれを継承するようにします。重要な唯一の区別は、入力が、エージェントが検証しゲートする 強制ケイパビリティ入力 か、生成を情報提供するが AdCP 層でハードブロックしない 助言コンテキストポインター かです。
境界は意図的で、プロトコルの残りに一致します: ケイパビリティは宣言され、ゲートされず、デフォルトは強制ではなく露出です。入力は、それがエージェントがエンドツーエンドで所有する型付きコントラクト — 有料レンダーを駆動するレンダー構成 — のときのみゲートします。他のすべてはステアリングします。
バイヤー添付入力の 2 クラス
強制ケイパビリティ入力 — transformer_id + config
transformer_id は、ビルドを実行するアカウントスコープの transformer（list_transformers 経由で発見）を選択します。呼び出しごとに 1 transformer。target_format_id / target_format_ids は transformer の output_format_ids のサブセットでなければなりません（MUST）。レンダー構成は config に入ります。
config は、transformer の params[] の各 param の field でキーされた型付きバッグです。それはゲートし、正しくゲートします: build_creative に従い、クリエイティブエージェントは、それらを黙って無視するのではなく 未知のキーと範囲外の値をフィールド帰属エラーで拒否しなければなりません（MUST） — config は有料レンダーを駆動します。宣言された param でないベンダー固有のノブは、ここではなく ext に入ります。合法なキーは transformer ごとに動的なので、スキーマはオブジェクトをオープンに残します。したがって厳格な検証は規範的なエージェント義務です。
これは AdCP 層でビルドをハードブロックする唯一のバイヤー添付入力で、それは正しいものです: config はクリエイティブエージェントが所有し、アカウントごとに価格設定されるコントラクトで、誤キーされた値は誤ったレンダーに課金するでしょう。エージェントはこの表面を露出するため creative.supports_transformers を宣言し、transformer と build_variant は登録された x-entity タイプです。
助言コンテキストポインター — signal_ref、evaluator、権利 / プロベナンス
助言ポインターは、生成が尊重すべきバイヤーコンテキスト — オーディエンスシグナル、評価者の好み、権利またはプロベナンス参照 — を運びます。それらは情報提供またはステアリングします。AdCP 層で生成をハードブロックしてはなりません（MUST NOT）。ポインターが名指すもののために強制が存在する場合、それは build_creative ではなくそれを所有する層に存在します:
- 権利 / プロベナンス — バイヤーのポインターではなく認証情報層（合成時の
generation_credentials、ライブ失効のrights_constraint.verification_url）によって強制。 - シグナル（#5240） — 強制が存在する場合、トラフィッキング互換性チェックに存在。
- 評価者（#5241） — 探索 & ランクガイダンス、リーフ上で
recommended/rankとして表示。ゲートではない。
sync_creatives status が「UI ヒントとポーリングスケジューリングシグナル — 支出承認ゲートではない」のと同じように、助言値に下流の支出またはパッケージアクティベーションをゲートしてはなりません（MUST NOT）。keep_mode はリクエスト側の同じ形状です — 助言のみ、返されるか課金されるものを変えません。
共有形状
すべてのバイヤー添付入力 — 強制または助言 — は同じ 3 部形状を継承します。これは今日 transformer に規範的で、将来のポインターが再利用するパターンです:-
アカウントスコープディスカバリー。 オプションは推測されず発見されます。
list_transformersはアカウントスコープ、ブリーフフィルター可能、ページ化され、アカウントの構成されたオプション値（例えばそのアカウントにプロビジョンされたボイス）を列挙するexpand_paramsモードを持ちます。別のオプションエンドポイントはありません — 列挙は 1 つのディスカバリータスクのモードです。将来のポインターのカタログは同じ方法で発見されます。 -
アカウントごとの価格設定。 ケイパビリティは、アカウントごとに解決され、結果でリーフごとにエコーされ、
report_usage経由で照合されるpricing_options（vendor-pricing-option.jsonを再利用）を運びます。どの価格オプションにも一致せずアンスコープデフォルトを持たない出力はUNPRICEABLE_OUTPUTを表示します。 -
安定したリーフアンカーを持つ結果エンベロープ。
build_creativeは、各生成されたリーフを自身のbuild_variant_id—preview_id（プレビュー）、サーブされたvariant_id（配信）、呼び出しレベルのbuild_creative_idと異なる名前空間 — とともに返します。リネージ、リファインメント親子関係、build→delivery 学習結合はすべてこのリーフ id でキーされ、各リーフは自身の価格設定レシートを運びます。保持されたリーフがトラフィックされるとき、そのbuild_variant_idは通常、耐久性のあるcreative_idになります。get_creative_deliveryは次にcreative_idを通じて結果を生成されたリーフに結合します。これは、評価者のスコアやシグナルのターゲティングがそれらのポインターが到達したときに添付するアンカーです。レスポンス形状コントラクトとリーフごとのフィールド仕組みはbuild_creativeタスクリファレンスに存在します。
権利はポインターで助言的。強制は認証情報
ビルドに添付された権利または プロベナンス 参照は、助言 / 監査ポインターです。それは AdCP 層でビルドを認可せず、クリエイティブエージェントはそれに対して権利トークンを検証する義務を負いません。transformer のvoice_synthesis_ref[].rights_id はこれを直接言います:
これはプロベナンスメタデータのみで、build_creative 権利トークンではありません。権利の強制は既に出荷され、認証情報層に存在します — バイヤーのポインターではなく:
generation_credentialsは合成時にプロバイダー強制されます。権利エージェントはプロバイダーと調整してスコープされた認証情報を発行します。プロバイダーは生成時にrights_keyを検証し、ゲートキーパーです。認証情報はacquire_rightsの acquired 分岐で必須です。rights_constraint.verification_urlはライブ失効チャネルです: 下流参加者（SSP、検証ベンダー）は、サーブ前に付与がアクティブであることを確認するためそれにヒットします — アクティブなら HTTP 200、失効なら 404。（approval_statusはマニフェスト時のスナップショットで、ライブ値ではありません。）creative-manifestrights[]は情報的メタデータとしてクリエイティブとともに移動します: 「v1 では、権利制約は情報的メタデータです — バイヤー/オーケストレーターがこれらの条件に対してクリエイティブライフサイクルを管理します。」
verify_agent.agent_url は、セラーの公開された creative_policy.accepted_verifiers[] の 1 つの 正準化された一致 でなければなりません（MUST）。リスト外の URL は PROVENANCE_VERIFIER_NOT_ACCEPTED で拒否されます。その拒否は、任意のアウトバウンド呼び出しの前にセラーが自身の allowlist を強制することです — バイヤーのポインターがビルドをゲートすることではありません。バイヤーの添付結果は補足的です。検証を要求するセラーは、それらを信頼するのではなく自身の検出を実行します。
確定した立場対 #5261。 バイヤー添付
rights_tokens[] をハードクリエイティブエージェントゲートとして扱う提案は、このページに対して解決されました。バイヤーポインターでのハードゲートは、合成層で既に出荷される generation_credentials 強制プラスサーブ層での verification_url ライブ失効を再発明します。ポインターは助言的なまま。強制は認証情報層に留まります。唯一の実際のギャップは構造的で、欠けているゲートではありません: voice_synthesis は provider / voice_id / settings を運びますが、今日 rights_id 逆参照はありません。その逆参照の追加は前方項目です — それは助言/監査証跡を拡張し、ビルド時ゲートを導入しません。実験的助言ポインター
以下の助言ポインターはこのコントラクトの 2 番目のクラスに属し、相互運用が固まる間実験的なままです。それらは上の共有形状を継承します: 該当する場合アカウントスコープディスカバリー、該当する場合アカウントごとの価格設定、同じ結果エンベロープ。それらは強制クラスのビルド時ゲートを継承しません — それはconfig のようなクリエイティブエージェントが所有する型付きコントラクトに予約されています。
- シグナル駆動クリエイティブファンアウト（#5240、RFC）。 バイヤーは
build_creativeのsignal_conditions: SignalTargeting[]にわたってファンアウトし、条件ごとに 1 クリエイティブグループを生成し、各々がそれが FOR であるsignal_conditionでタグ付けされます。AdCP 層で助言的。トラフィッキング互換性（sun クリエイティブは rain ターゲットパッケージにサーブしてはならない、MUST NOT）はSIGNAL_TARGETING_INCOMPATIBLE経由でセールス側で強制されます。#5240 は 既存のシグナルドメインSignalTargeting/signal-ref.jsonを再利用 します — 新しいクリエイティブコンテキストsignal_refは作られません — したがってクリエイティブの条件とセールス側パッケージターゲティングは 1 つのsignal_refアイデンティティを共有します。
-
evaluator/evaluator_id（#5241、実験的）。 バイヤーが添付するクリエイティブ評価者/オラクルで、エージェントがbest_of_n軸で代替を探索しランク付けでき、リーフにrecommended/rankを表示します。助言的 — 好みシグナルで、セラー強制ゲートではありません。フィーチャー語彙と結果エンベロープのみがオンワイヤーで発見されます: 評価者フィーチャーディスカバリーはget_adcp_capabilities.governance.creative_featuresを再利用し、評価者結果はget_creative_featuresと同じcreative-feature-result[]語彙を使います。実験的表面で使われるevaluator_idは、事前プロビジョンされたアカウント手配のハウスプリセットで、creative-feature カタログからの ID でもマーケットプレイス/プロバイダーアイデンティティでもありません。 信頼境界は他のバイヤー添付ポインターと同じです: ペイロードは評価者を名指しまたは較正します。評価者認証情報や呼び出し元供給の信頼素材を運びません。外部評価者呼び出しは、リクエスト署名/JWKS、mTLS、または事前プロビジョンされた静的認証情報を使って、生成エージェントの評価者へのトランスポート接続で認証します。evaluator、context、extは API キー、bearer トークン、クライアントシークレット、Authorization値、JWK、JWKS 文書、JWKS URI を含んではなりません（MUST NOT）。認証情報または信頼素材ペイロードフィールドはCREDENTIAL_IN_ARGSとして拒否されるべきです。
評価者ソースモデル
evaluator は 3 つの分離可能な層を持ちます:
- Intent はバイヤーが判断させたいものです。
feature_requirement[]、rank_by、creative-feature 語彙を通じて表現されます。これらはゲート/ランクセマンティクスを定義し、評価者がどこから来たかではありません。 - Source は評価を実行するものです。クリーンなソース解決モデルはエージェント形状の評価者エンドポイントまたはアダプターです。現在の実験的表面では、それは生成エージェントが呼ぶことを許可されたバイヤー供給の
agent_urlとして直接、セラーサポートの評価者エージェント/アダプターのアカウント手配evaluator_idエイリアスとして、または予測パフォーマンススタイルフィーチャーを較正するインラインexemplarsとして現れます。 - Discovery / marketplace はバイヤーが評価者プロバイダーを見つける方法です。その層は、セラーが実際に解決できるハンドルやアダプターをアドバタイズしていない限り、AdCP コアの外側です。
その分割は、ディスカバリーをマーケットプレイスにせずに現在の動機付けケースをカバーします: 外部ブランド要件 API は
agent_url / allowlist 検証者パスを使い、汎用 brand.json アライメントは allowlist されたエージェントまたはセラーサポートアカウントエイリアスで表現でき、良い / 悪いアーティファクトからの履歴パフォーマンスは exemplars を使います。
これは、並行 id カタログではなくエージェント形状評価者ソースにプロトコル境界を中心化します。将来の list_evaluators は、商業マーケットプレイス / プロバイダーディスカバリーではなく、セラーサポートの評価者エージェント/アダプターにスコープされるのが最善です。evaluator_id は、具体的な相互運用ケースがそのエージェント形状参照で表現できない場合のみ、耐久性のあるプリミティブとして残る必要があります。
アーティファクト事例ではなく配信履歴から訓練されるコンバージョン結果評価者には、4 番目のソース形式が必要かもしれません。それは list_evaluators / 評価者ディスカバリーフォローアップのオープンな設計問題のままで、この明確化はそれを凍結しません。