宣言からグレードされるシナリオへ
エージェントがget_adcp_capabilities で専門分野を宣言すると、ランナーは:
/compliance/{version}/specialisms/{id}/の専門分野マニフェストをフェッチ。- マニフェストの
requires_scenariosリスト — ランナーがグレードしなければならないシナリオ ID の順序付きセット — を読む。 - 各シナリオについて、シナリオが
requires_capabilityゲートを宣言するかを確認。 - ゲートが存在する場合、シナリオを実行するかスキップするかを決めるため、
get_adcp_capabilitiesレスポンスから名前付きパスを読む。
ランナー証拠対検証ポリシー
ストーリーボードランナーは、エージェントがバッジを獲得するか特定のバイヤーを満たすかを決めません。証拠を生成します: 実行されたアサーション、失敗、選択されたがスキップされたステップ、選択されなかったステップ、スキップ理由、使われたエンドポイント/実行モード。検証ポリシーがその証拠を消費し、どのギャップが名前付きの結果に許容可能かを決めます。
これがランナー分類が重要な理由です。「これはサンドボックス専用実行なので選択されなかった」はスイート選択の事実で、セラーケイパビリティギャップではありません。「セラーが任意機能を主張しなかったのでスキップ」はバッジに許容可能でも、その機能を要求するバイヤーには許容不可能かもしれません。「宣言された必須ツールが欠けているのでスキップ」はセラー実装問題です。
要件プロファイル
「何を通過する必要があるか？」に答えるには、満たそうとしているプロファイルから始めます:
バイヤー要件プロファイルは公開バッジより厳格でありえます。例えば、公開 Sandbox プロファイルは
media_buy.supports_proposals: false のときケイパビリティゲートのプロポーザルストーリーボードがスキップされるのを受け入れられます。プロポーザルワークフローを要求するバイヤーは同じスキップをブロッカーとして扱えます。逆に、comply_test_controller を省略する本番エンドポイントは Sandbox バッジに許容可能でも、決定的統合テストをするバイヤーはそれを公開する別の dev/staging エンドポイントを求めるかもしれません。
ストーリーボードランナーはそれらのバイヤー決定をエンコードすべきではありません。検証ポリシーやバイヤープロファイルが一貫して評価できる型付き証拠を発すべきです。
専門分野マニフェスト
各専門分野のrequires_scenarios フィールドは、ランナーがグレードするシナリオをリストします。例 — sales-guaranteed マニフェストは 8 つの必須シナリオを宣言します:
sales-guaranteed エージェントに無条件で実行されます。8 つ目 — proposal_finalize — はケイパビリティゲートを運びます。
ケイパビリティゲート
シナリオまたはフェーズはrequires_capability ブロックを宣言できます。ランナーは get_adcp_capabilities レスポンスから名前付きパスを読み、期待される値に対して確認します。チェックが失敗（ケイパビリティが欠如または false）すると、シナリオまたはフェーズはスキップされ — skip ブロックが reason: not_applicable でランナー出力に現れ — steps_failed に寄与しません。
get_adcp_capabilities レスポンスに対して評価されます — ランナーが universal capability_discovery ストーリーボード中に行うのと同じ呼び出し。
フェーズレベルのゲートは同じ形状を使い、ブロックを宣言するフェーズのみをスコープします。Universal ストーリーボードはこれをプロトコル固有のフェーズファミリーに使います。例えば、決定的テストは、エージェントが sponsored_intelligence を宣言しないとき SI セッションフェーズをスキップし、エージェントが宣言するメディアバイまたはクリエイティブフェーズは依然実行します。
実践例
シナリオ: Priya の StreamHaus プラットフォームがsales-guaranteed を主張し media_buy.supports_proposals: true を宣言。
proposal_finalize を含む 8 つすべての requires_scenarios が実行される。Priya のプラットフォームは完全なプロポーザルライフサイクル — プロポーザル付きブリーフ、refine、finalize、create_media_buy 経由の実行 — でグレードされる。
シナリオ: StreamHaus Direct はオークションベースの PG プラットフォーム — プロポーザル抽象なし。
sales-guaranteed を主張し media_buy.supports_proposals: false を宣言。
proposal_finalize はスキップされる。ランナー出力の skip ブロックが権威あるシグナル:
skip ブロックが存在するとき、ステップはグレードされず steps_failed にカウントされません。skip.detail 文字列が特定の原因（ケイパビリティゲート、欠けている専門分野宣言、欠けているツール）を識別します。
欠如 = false。
supports_proposals フィールドはケイパビリティスキーマで "default": false を持ちます。レスポンスから省略することは false を宣言するのと等価です — ランナーはケイパビリティゲートのプロポーザルシナリオをスキップします。グレーディングにオプトインするには true を明示的に宣言してください。このフラグはグレーディングゲートのみです。バイヤーエージェントはそれを特定のプロポーザルが実行可能かを決めるのに使うべきではありません。セラーがプロポーザルを返す場合、proposal_status が真実の源泉です: draft は create の前に finalize を要求、committed は expires_at の前に実行可能、欠如したステータスはレガシーの ready-to-buy。一目でのグレーディング判定
実行の全体的なコンプライアンス判定は
steps_failed によって決定されます。スキップされたステップ（skip ブロック存在）と未選択アイテム（run_summary.not_selected[] エントリ）はそのカウンターに寄与しませんが、異なることを意味します。steps_not_selected は、ランナーがこの実行からそれらのシナリオを意図的に除外したことを言います。steps_skipped は、ランナーがそれらのシナリオを選択したが実行できなかったことを言います。任意ケイパビリティ選択を欠けている必須サーフェスから区別するには skipped_by_reason と skip.detail を使います。
したがってサンドボックス専用実行は、除外された作業のみが選択モード外のとき、こう見えるべきです:
steps_skipped の下に現れる場合、それらは選択されてからスキップされた。それは異なるシグナルで skipped_by_reason が必要です。
合格対部分カバレッジ
ランナーサマリーは 失敗 を カバレッジ から区別します:
この区別は本番パスのサンドボックス実行に重要です。セラーは、サンドボックスフラグ付きトラフィックの下で実際の本番エンドポイントに対してストーリーボードスイートを実行し ゼロ失敗 を得ながら、本番エンドポイントが正しく
comply_test_controller を公開しないため依然として partial サマリーを見られます。その結果はこう言います: 「バイヤー可視のサンドボックスパスはランナーがグレードできたすべてのアサーションを通過したが、コントローラーシードのライフサイクルシナリオはスキップされた」。それはサンドボックス準備の有用な証拠ですが、完全な決定的専門分野カバレッジと同じではありません。
完全なカバレッジには、コントローラーを公開する dev または staging エンドポイントに対して同じ宣言スコープを実行するか、必要な状態を事前シードしランナーがシードされた状態のカバレッジをアサートするよう設定します。本番のみのセラーには、バイヤーが何がグレードされ何がされなかったかを正確に見られるよう、スキップされたカバレッジリストをゼロ失敗結果と並んで公開します。
各部品がどこに存在するか
完全な専門分野からシナリオへのインデックスは Compliance Catalog にあります。すべてのスキップ理由と判定形状を定義するランナー出力コントラクトは
static/compliance/source/universal/runner-output-contract.yaml にあります。
関連
- 適合性仕様 — 3 層義務モデルと規範的ストーリーボードインデックス
- Compliance Catalog — プロトコル、専門分野、universal ストーリーボードの完全タクソノミー
- エージェントを検証する —
@adcp/sdkでスイートをローカルで実行