@adcp/sdk 13.0.1 → 13.0.3

package/compliance/cache/3.1.20/protocols/media-buy/scenarios/inventory_list_no_match.yaml

@@ -0,0 +1,229 @@
+id: media_buy_seller/inventory_list_no_match
+version: "1.0.1"
+title: "Seller handles a property_list reference that matches zero inventory"
+category: media_buy_seller
+summary: "Verifies a seller preserves a no-match property list on an accepted buy or returns a structured error."
+track: media_buy
+required_tools:
+  - get_products
+  - create_media_buy
+
+requires_capability:
+  path: "media_buy.features.property_list_filtering"
+  equals: true
+
+narrative: |
+  Not every buyer list matches every seller's inventory. A buyer may point at a
+  property_list of domains this seller does not carry. The seller must handle
+  that gracefully:
+
+  - Accept the buy and surface a zero-delivery expectation through reporting, OR
+  - Return an informative typed AdCP error on create_media_buy with findings the
+    buyer can act on.
+
+  What the seller must NOT do: crash, return a misleading non-zero forecast, or
+  silently drop the targeting and deliver against unintended inventory. Each of
+  those is a real failure mode we've seen in adapter integrations.
+
+  This scenario exercises the no-match path using the test kit's pre-populated
+  no_match_properties list.
+
+agent:
+  interaction_model: media_buy_seller
+  capabilities:
+    - sells_media
+    - supports_property_list_targeting
+  examples:
+    - "Sellers that validate inventory against buyer-supplied lists"
+
+caller:
+  role: buyer_agent
+  example: "Pinnacle Agency (buyer)"
+
+prerequisites:
+  description: |
+    The seller must resolve PropertyListReference against its own inventory and
+    report a truthful outcome when nothing matches.
+  test_kit: "test-kits/acme-outdoor.yaml"
+
+phases:
+  - id: discover
+    title: "Discover products"
+    steps:
+      - id: get_products_brief
+        title: "Discover products"
+        task: get_products
+        schema_ref: "media-buy/get-products-request.json"
+        response_schema_ref: "media-buy/get-products-response.json"
+        doc_ref: "/media-buy/task-reference/get_products"
+        comply_scenario: full_sales_flow
+        stateful: false
+        expected: |
+          Return products the seller carries.
+        sample_request:
+          buying_mode: "brief"
+          brief: "Outdoor lifestyle programming. Q3 flight."
+          filters:
+            is_fixed_price: true
+          account:
+            brand:
+              domain: "acmeoutdoor.example"
+            operator: "pinnacle-agency.example"
+
+          context:
+            correlation_id: "inventory_list_no_match--get_products_brief"
+        context_outputs:
+          - path: "products[0].product_id"
+            key: "product_id"
+          - path: "products[0].pricing_options[0].pricing_option_id"
+            key: "pricing_option_id"
+        validations:
+          - check: response_schema
+            description: "Response matches get-products-response.json schema"
+          - check: field_present
+            path: "products[0].pricing_options[0].fixed_price"
+            description: "The captured pricing option is fixed-price; fixed-price storyboards do not send bid_price"
+
+  - id: no_match_accept_path
+    title: "Accept and preserve the no-match property list"
+    optional: true
+    branch_set:
+      id: property_list_no_match_handled
+      semantics: any_of
+    narrative: |
+      A seller may accept the buy when it preserves the property-list targeting
+      and its downstream reporting makes the zero-delivery expectation clear.
+      This is one of the two conformant outcomes in the 3.1 contract; the peer
+      branch covers structured rejection.
+
+    steps:
+      - id: create_buy_no_match_accept
+        title: "Accept create_media_buy against an empty intersection"
+        task: create_media_buy
+        schema_ref: "media-buy/create-media-buy-request.json"
+        response_schema_ref: "media-buy/create-media-buy-response.json"
+        doc_ref: "/media-buy/task-reference/create_media_buy"
+        comply_scenario: create_media_buy
+        stateful: true
+        contributes: true
+        expected: |
+          Accept the buy with a valid media-buy artifact that retains the
+          property-list targeting. The seller remains responsible for surfacing
+          the zero-delivery expectation through its reporting behavior.
+        sample_request:
+          brand:
+            domain: "acmeoutdoor.example"
+          account:
+            brand:
+              domain: "acmeoutdoor.example"
+            operator: "pinnacle-agency.example"
+          idempotency_key: "$generate:uuid_v4#inventory_list_no_match_accept"
+          start_time: "asap"
+          end_time: "2099-09-30T23:59:59Z"
+          packages:
+            - product_id: "$context.product_id"
+              budget: 10000
+              pricing_option_id: "$context.pricing_option_id"
+              targeting_overlay:
+                property_list:
+                  agent_url: "https://governance.pinnacle-agency.example"
+                  list_id: "acme_outdoor_no_match_v1"
+          context:
+            correlation_id: "inventory_list_no_match--accept"
+        validations:
+          - check: response_schema
+            description: "Accepted response matches create-media-buy-response.json"
+          - check: field_present
+            path: "media_buy_id"
+            description: "Accepted response returns a media_buy_id"
+          - check: field_value
+            path: "packages[0].targeting_overlay.property_list.list_id"
+            value: "acme_outdoor_no_match_v1"
+            description: "Accepted response preserves the no-match property-list targeting"
+          - check: field_present
+            path: "context"
+            description: "Accepted response echoes back the context object"
+          - check: field_value
+            path: "context.correlation_id"
+            value: "inventory_list_no_match--accept"
+            description: "Context correlation_id returned unchanged"
+
+  - id: no_match_reject_path
+    title: "Reject the no-match buy with a structured error"
+    optional: true
+    branch_set:
+      id: property_list_no_match_handled
+      semantics: any_of
+    narrative: |
+      A seller may instead reject the same well-formed request. This branch makes
+      that documented 3.1 outcome reachable by marking the error as expected and
+      requiring a typed AdCP error response with preserved correlation context.
+
+    steps:
+      - id: create_buy_no_match_reject
+        title: "Reject create_media_buy against an empty intersection"
+        task: create_media_buy
+        schema_ref: "media-buy/create-media-buy-request.json"
+        response_schema_ref: "media-buy/create-media-buy-response.json"
+        doc_ref: "/media-buy/task-reference/create_media_buy"
+        comply_scenario: create_media_buy
+        expect_error: true
+        negative_path: payload_well_formed
+        stateful: true
+        contributes: true
+        expected: |
+          Reject with a well-formed AdCP error explaining that the property list
+          matches no available inventory. The 3.1 contract does not mandate one
+          specific error code for this condition.
+        sample_request:
+          brand:
+            domain: "acmeoutdoor.example"
+          account:
+            brand:
+              domain: "acmeoutdoor.example"
+            operator: "pinnacle-agency.example"
+          idempotency_key: "$generate:uuid_v4#inventory_list_no_match_reject"
+          start_time: "asap"
+          end_time: "2099-09-30T23:59:59Z"
+          packages:
+            - product_id: "$context.product_id"
+              budget: 10000
+              pricing_option_id: "$context.pricing_option_id"
+              targeting_overlay:
+                property_list:
+                  agent_url: "https://governance.pinnacle-agency.example"
+                  list_id: "acme_outdoor_no_match_v1"
+          context:
+            correlation_id: "inventory_list_no_match--reject"
+        validations:
+          - check: response_schema
+            description: "Rejected response matches create-media-buy-response.json"
+          - check: error_code
+            description: "Rejected response carries a typed AdCP error code"
+          - check: field_present
+            path: "context"
+            description: "Rejected response echoes back the context object"
+          - check: field_value
+            path: "context.correlation_id"
+            value: "inventory_list_no_match--reject"
+            description: "Context correlation_id returned unchanged"
+
+  - id: no_match_outcome_assertion
+    title: "Require one documented no-match outcome"
+    narrative: |
+      Synthetic assertion over the accept and reject branches. Either a valid
+      zero-delivery acceptance path or a structured rejection satisfies the 3.1
+      no-match contract.
+    steps:
+      - id: assert_property_list_no_match_handled
+        title: "Require handling from either branch"
+        task: assert_contribution
+        comply_scenario: create_media_buy
+        stateful: false
+        expected: |
+          At least one no-match outcome contributed
+          property_list_no_match_handled.
+        validations:
+          - check: any_of
+            allowed_values: ["property_list_no_match_handled"]
+            description: "Seller must either accept while preserving the targeting or return a structured rejection."

package/compliance/cache/{3.1.15 → 3.1.20}/protocols/media-buy/scenarios/inventory_list_targeting.yaml

@@ -1,38 +1,40 @@
 id: media_buy_seller/inventory_list_targeting
-version: "1.0.0"
-title: "Seller honors property_list and collection_list targeting on create and update"
+version: "1.0.1"
+title: "Seller honors property_list targeting on create and update"
 category: media_buy_seller
-summary: "Verifies that a seller accepts PropertyListReference and CollectionListReference in package targeting on create_media_buy AND update_media_buy, with parity between both paths."
+summary: "Verifies that a seller accepts PropertyListReference in package targeting on create_media_buy AND update_media_buy, with parity between both paths."
 track: media_buy
 required_tools:
   - get_products
   - create_media_buy
   - update_media_buy
+  - get_media_buys
+
+requires_capability:
+  path: "media_buy.features.property_list_filtering"
+  equals: true
 
 narrative: |
   AdCP 3.0 targets inventory through agent-hosted reference lists rather than inline
-  property arrays. Buyers point a package's targeting at a `PropertyListReference`
-  and/or `CollectionListReference`; the seller resolves the list against its own
-  inventory at serve time.
+  property arrays. Buyers point a package's targeting at a `PropertyListReference`;
+  the seller resolves the list against its own inventory at serve time.
 
   A common integration regression is create/update parity: a seller accepts list
   references on create_media_buy but silently drops them on update_media_buy, so a
-  buyer who edits a live buy loses their list targeting. This scenario writes both
-  list types on create, then swaps both on update, and finally reads the buy back
-  to confirm the updated references are what the seller persisted.
+  buyer who edits a live buy loses their list targeting. This scenario writes the
+  property list on create, swaps it on update, and finally reads the buy back to
+  confirm the updated reference is what the seller persisted.
 
-  The buyer references pre-populated inventory lists from the test kit — one for
-  matching properties and one for matching collections — so the seller's test
-  engine can resolve them without needing a live governance/inventory agent.
+  The buyer references a pre-populated property list from the test kit so the
+  seller's test engine can resolve it without needing a live governance agent.
 
 agent:
   interaction_model: media_buy_seller
   capabilities:
     - sells_media
     - supports_property_list_targeting
-    - supports_collection_list_targeting
   examples:
-    - "Sellers that accept PropertyListReference / CollectionListReference in package targeting"
+    - "Sellers that accept PropertyListReference in package targeting"
 
 caller:
   role: buyer_agent
@@ -40,14 +42,14 @@ caller:
 
 prerequisites:
   description: |
-    The seller must accept PropertyListReference and CollectionListReference in
-    package targeting on both create_media_buy and update_media_buy. List contents
-    come from test-kits/acme-outdoor.yaml → inventory_targets.
+    The seller must accept PropertyListReference in package targeting on both
+    create_media_buy and update_media_buy. List contents come from
+    test-kits/acme-outdoor.yaml → inventory_targets.
   test_kit: "test-kits/acme-outdoor.yaml"
 
 phases:
   - id: discover_product
-    title: "Discover a product that supports list targeting"
+    title: "Discover a product that supports property-list targeting"
     steps:
       - id: get_products_brief
         title: "Discover product"
@@ -58,8 +60,8 @@ phases:
         comply_scenario: full_sales_flow
         stateful: false
         expected: |
-          Return at least one product whose targeting supports property_list and
-          collection_list references.
+          Return at least one product whose targeting supports a property_list
+          reference.
 
         sample_request:
           buying_mode: "brief"
@@ -89,16 +91,16 @@ phases:
             path: "products[0].pricing_options[0].fixed_price"
             description: "The captured pricing option is fixed-price; fixed-price storyboards do not send bid_price"
 
-  - id: create_with_both_lists
-    title: "Create media buy with property_list AND collection_list targeting"
+  - id: create_with_property_list
+    title: "Create media buy with property_list targeting"
     narrative: |
-      The buyer references the matching-property list and the matching-collection
-      list from the test kit. The seller accepts both references, creates the buy,
-      and echoes the resolved targeting back on the package.
+      The buyer references the matching-property list from the test kit. The
+      seller accepts the reference, creates the buy, and echoes the resolved
+      targeting back on the package.
 
     steps:
       - id: create_buy_with_lists
-        title: "create_media_buy with both list references"
+        title: "create_media_buy with a property-list reference"
         task: create_media_buy
         schema_ref: "media-buy/create-media-buy-request.json"
         response_schema_ref: "media-buy/create-media-buy-response.json"
@@ -106,10 +108,9 @@ phases:
         comply_scenario: create_media_buy
         stateful: true
         expected: |
-          The seller accepts the list references without error. The response
-          includes a media_buy_id and the package retains both the property_list
-          and collection_list targeting fields so subsequent get / update calls
-          can read them back.
+          The seller accepts the list reference without error. The response
+          includes a media_buy_id and the package retains the property_list
+          targeting field so subsequent get / update calls can read it back.
 
         sample_request:
           brand:
@@ -130,10 +131,6 @@ phases:
                 property_list:
                   agent_url: "https://governance.pinnacle-agency.example"
                   list_id: "acme_outdoor_allowlist_v1"
-                collection_list:
-                  agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_collections_v1"
-
           context:
             correlation_id: "inventory_list_targeting--create_buy_with_lists"
         context_outputs:
@@ -154,9 +151,9 @@ phases:
   - id: verify_create_persisted
     title: "Verify list targeting persisted after create"
     narrative: |
-      Read the buy back to confirm the seller stored both list references — not just
-      echoed them back in the create response. This catches sellers that parse list
-      references on create but never persist them to their internal package model.
+      Read the buy back to confirm the seller stored the list reference — not just
+      echoed it back in the create response. This catches sellers that parse the
+      list reference on create but never persist it to their internal package model.
 
     steps:
       - id: get_after_create
@@ -169,7 +166,7 @@ phases:
         stateful: true
         expected: |
           Return the media buy with packages[0].targeting_overlay.property_list
-          and .collection_list populated with the list_id values sent on create.
+          populated with the list_id value sent on create.
 
         sample_request:
           account:
@@ -189,22 +186,18 @@ phases:
             path: "media_buys[0].packages[0].targeting_overlay.property_list.list_id"
             value: "acme_outdoor_allowlist_v1"
             description: "property_list.list_id persisted after create"
-          - check: field_value
-            path: "media_buys[0].packages[0].targeting_overlay.collection_list.list_id"
-            value: "acme_outdoor_collections_v1"
-            description: "collection_list.list_id persisted after create"
 
   - id: update_swap_lists
-    title: "Swap property_list and collection_list via update_media_buy"
+    title: "Swap property_list via update_media_buy"
     narrative: |
-      The buyer swaps both list references. This is the create/update parity check:
-      a seller that accepts list references on create but silently drops them on
+      The buyer swaps the list reference. This is the create/update parity check:
+      a seller that accepts the reference on create but silently drops it on
       update would fail to update the persisted targeting. We exercise update
       explicitly to catch that class of regression.
 
     steps:
       - id: update_buy_swap_lists
-        title: "update_media_buy replaces both list references"
+        title: "update_media_buy replaces the property-list reference"
         task: update_media_buy
         schema_ref: "media-buy/update-media-buy-request.json"
         response_schema_ref: "media-buy/update-media-buy-response.json"
@@ -212,8 +205,8 @@ phases:
         comply_scenario: media_buy_lifecycle
         stateful: true
         expected: |
-          The seller acknowledges the updated targeting. Both property_list and
-          collection_list are replaced (not merged) with the new list_id values.
+          The seller acknowledges the updated targeting. property_list is
+          replaced (not merged) with the new list_id value.
 
         sample_request:
           account:
@@ -227,10 +220,7 @@ phases:
               targeting_overlay:
                 property_list:
                   agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_no_match_v1"
-                collection_list:
-                  agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_no_match_collections_v1"
+                  list_id: "acme_outdoor_allowlist_v2"
 
           idempotency_key: "$generate:uuid_v4#media_buy_seller_inventory_list_targeting_update_swap_lists_update_buy_swap_lists"
           context:
@@ -250,10 +240,7 @@ phases:
               targeting_overlay:
                 property_list:
                   agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_no_match_v1"
-                collection_list:
-                  agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_no_match_collections_v1"
+                  list_id: "acme_outdoor_allowlist_v2"
             description: "Update response returns the affected package with complete post-update targeting state"
 
       - id: get_after_update
@@ -285,9 +272,5 @@ phases:
             description: "Response matches get-media-buys-response.json schema"
           - check: field_value
             path: "media_buys[0].packages[0].targeting_overlay.property_list.list_id"
-            value: "acme_outdoor_no_match_v1"
+            value: "acme_outdoor_allowlist_v2"
             description: "property_list.list_id updated after update_media_buy"
-          - check: field_value
-            path: "media_buys[0].packages[0].targeting_overlay.collection_list.list_id"
-            value: "acme_outdoor_no_match_collections_v1"
-            description: "collection_list.list_id updated after update_media_buy"

package/compliance/cache/{3.1.15.previous → 3.1.20}/protocols/media-buy/scenarios/measurement_terms_rejected.yaml

@@ -1,25 +1,20 @@
 id: media_buy_seller/measurement_terms_rejected
-version: "1.0.0"
+version: "1.0.1"
 title: "Seller rejects unworkable measurement_terms"
 category: media_buy_seller
-summary: "Buyer proposes measurement_terms the seller will not accept; seller returns TERMS_REJECTED; buyer retries with seller-compatible terms."
+summary: "Buyer proposes unworkable measurement_terms and the seller returns TERMS_REJECTED."
 track: media_buy
 required_tools:
   - get_products
   - create_media_buy
 
 narrative: |
-  measurement_terms negotiation is a round-trip. The buyer proposes a measurement vendor,
-  window, and variance tolerance on each package; the seller either accepts (returning
-  measurement_terms echoed in the response) or rejects with TERMS_REJECTED and a message
-  explaining what is unacceptable. The buyer mints a fresh idempotency_key and retries
-  create_media_buy with the adjusted payload — reusing the prior key against a different
-  body MUST be rejected with IDEMPOTENCY_CONFLICT per spec.
+  The buyer proposes a measurement vendor, window, and variance tolerance on each
+  package. This universal scenario sends intentionally unworkable terms and verifies
+  that the seller rejects them with TERMS_REJECTED and an explanatory message.
 
-  This scenario sends an intentionally aggressive first proposal (max_variance_percent: 0
-  with a window the seller does not guarantee), verifies the seller rejects with
-  TERMS_REJECTED, then retries with a relaxed proposal that falls inside the seller's
-  stated tolerance and expects a successful create_media_buy.
+  AdCP 3.1 has no capability bit for measurement-term acceptance, so the optional
+  relaxed-terms success arm is deliberately not graded on this maintenance line.
 
 agent:
   interaction_model: media_buy_seller
@@ -140,64 +135,3 @@ phases:
             path: "context.correlation_id"
             value: "measurement_terms_rejected--aggressive"
             description: "Context correlation_id returned unchanged"
-
-  - id: accept_terms
-    title: "Buyer retries with acceptable terms"
-    narrative: |
-      The buyer relaxes measurement_terms to match the seller's stated capability
-      (c7 window, 10% variance, makegood remedies) and retries. The seller accepts and
-      returns the confirmed terms echoed in the response.
-
-    steps:
-      - id: create_media_buy_relaxed_terms
-        title: "Propose seller-compatible measurement_terms"
-        task: create_media_buy
-        schema_ref: "media-buy/create-media-buy-request.json"
-        response_schema_ref: "media-buy/create-media-buy-response.json"
-        doc_ref: "/media-buy/task-reference/create_media_buy"
-        comply_scenario: create_media_buy
-        stateful: true
-        expected: |
-          The buy succeeds. The response echoes the accepted measurement_terms (possibly
-          normalized by the seller).
-
-        sample_request:
-          brand:
-            domain: "acmeoutdoor.example"
-          account:
-            brand:
-              domain: "acmeoutdoor.example"
-            operator: "pinnacle-agency.example"
-          idempotency_key: "$generate:uuid_v4#media_buy_seller_measurement_terms_rejected_accept_terms_create_media_buy_relaxed_terms"
-          start_time: "asap"
-          end_time: "2099-09-30T23:59:59Z"
-          packages:
-            - product_id: "$context.product_id"
-              budget: 25000
-              pricing_option_id: "$context.pricing_option_id"
-              measurement_terms:
-                billing_measurement:
-                  vendor:
-                    domain: "videoamp.example"
-                  measurement_window: "c7"
-                  max_variance_percent: 10
-                makegood_policy:
-                  available_remedies: ["additional_delivery", "credit"]
-
-          context:
-            correlation_id: "measurement_terms_rejected--relaxed"
-        validations:
-          - check: response_schema
-            description: "Response matches create-media-buy-response.json schema"
-          - check: field_present
-            path: "media_buy_id"
-            description: "Seller returns a media_buy_id after accepting terms"
-          - check: field_present
-            path: "context"
-            description: "Response echoes back the context object"
-          - check: field_value
-            path: "context.correlation_id"
-            value: "measurement_terms_rejected--relaxed"
-            description: "Context correlation_id returned unchanged"
-        reviewer_checks:
-          - "Reviewer MUST confirm the seller releases the idempotency claim after a TERMS_REJECTED response. Probe: send the aggressive-terms request (same key, step 1), then retry with the same key and corrected terms (this step) — the seller MUST return a fresh media_buy_id, not IDEMPOTENCY_CONFLICT. A seller that caches rejected requests would make this two-step retry pattern impossible. See security.mdx#idempotency rule 3 ('Only successful responses are cached')."

package/compliance/cache/{3.1.15.previous → 3.1.20}/protocols/media-buy/scenarios/pending_creatives_to_start.yaml

@@ -1,17 +1,16 @@
 id: media_buy_seller/pending_creatives_to_start
-version: "1.0.0"
+version: "1.0.1"
 title: "Creative sync unblocks pending_creatives → pending_start"
 category: media_buy_seller
 summary: "Verifies that a media buy created without creatives sits in pending_creatives until sync_creatives completes, then transitions to pending_start."
 track: media_buy
 
-# This scenario requires an explicit auto-approval declaration. Sellers that
-# declare `require_human`, or omit the field because approval behavior is
-# legacy-unspecified, grade not_applicable rather than false-failing on a
-# manual-review workflow.
+# This scenario requires a creative library. The 3.1 runner supports one
+# storyboard-level capability predicate, so the auto-approval predicate is
+# repeated on each phase below to preserve both applicability conditions.
 requires_capability:
-  path: media_buy.creative_approval_mode
-  equals: auto_approve
+  path: creative.has_creative_library
+  equals: true
 
 required_tools:
   - get_products
@@ -52,6 +51,9 @@ prerequisites:
 
 phases:
   - id: setup
+    requires_capability: &auto_approval_gate
+      path: media_buy.creative_approval_mode
+      equals: auto_approve
     title: "Discover products and formats"
     steps:
       - id: get_products_brief
@@ -91,6 +93,7 @@ phases:
             description: "The captured pricing option is fixed-price; fixed-price storyboards do not send bid_price"
 
   - id: create_without_creatives
+    requires_capability: *auto_approval_gate
     title: "Create media buy without creative_assignments"
     narrative: |
       The buyer intentionally omits creative_assignments. The seller must accept the
@@ -168,6 +171,7 @@ phases:
             description: "Created package echoes package-level context for legacy package correlation"
 
   - id: supply_creatives
+    requires_capability: *auto_approval_gate
     title: "Supply creatives and assign to the package"
     narrative: |
       The buyer syncs a creative with the format the product requires, then updates the
@@ -260,6 +264,7 @@ phases:
             description: "Envelope task-status is completed on synchronous update success (protocol-envelope.json required: [status])"
 
   - id: verify_transition
+    requires_capability: *auto_approval_gate
     title: "Verify the status transition"
     narrative: |
       Independently of the update_media_buy response, call get_media_buys to confirm the

package/compliance/cache/{3.1.15.previous → 3.1.20}/protocols/media-buy/scenarios/refine_products.yaml

@@ -1,5 +1,5 @@
 id: media_buy_seller/refine_products
-version: "1.0.0"
+version: "1.0.1"
 title: "Seller handles product refinement"
 category: media_buy_seller
 summary: "Verifies that a media buy seller supports buying_mode: refine with product-level and request-level changes."
@@ -7,6 +7,10 @@ track: media_buy
 required_tools:
   - get_products
 
+requires_capability:
+  path: media_buy.buying_modes
+  contains: refine
+
 narrative: |
   After a buyer receives products from a brief, they refine the results without starting
   over. The buyer calls get_products with buying_mode: refine and a refine array describing

package/compliance/cache/{3.1.15.previous → 3.1.20}/specialisms/sales-broadcast-tv/index.yaml

@@ -1,5 +1,5 @@
 id: sales_broadcast_tv
-version: "1.0.0"
+version: "1.0.1"
 title: "Broadcast linear TV seller agent"
 protocol: media-buy
 category: sales_broadcast_tv
@@ -422,6 +422,9 @@ phases:
             description: "Context correlation_id returned unchanged"
   - id: creative_sync
     title: "Creative sync"
+    requires_capability:
+      path: creative.has_creative_library
+      equals: true
     narrative: |
       Broadcast creative sync differs from digital in three ways. First, assets are
       broadcast-grade video files — no VAST wrappers, no impression trackers, no click
@@ -559,6 +562,7 @@ phases:
             description: "Context correlation_id returned unchanged"
   - id: delivery_monitoring
     title: "Delivery and reporting"
+    depends_on: [create_buy]
     narrative: |
       Broadcast delivery reporting operates on a fundamentally different timeline than
       digital. Live ratings are available within 24 hours, but the numbers that matter
@@ -680,6 +684,7 @@ phases:
             description: "Context correlation_id returned unchanged"
   - id: reconciliation
     title: "Post-flight reconciliation"
+    depends_on: [delivery_monitoring]
     narrative: |
       Broadcast reconciliation cannot happen until C7 data has matured for every air
       date in the flight. For a flight ending December 31, final C7 data for the last