@adcp/sdk 14.0.0-rc.38 → 14.0.0-rc.40

package/compliance/cache/3.1.0-beta.7/specialisms/signal-owned/index.yaml

@@ -1,317 +0,0 @@
-id: signal_owned
-version: "1.0.0"
-title: "Owned signal agent"
-protocol: signals
-category: signal_owned
-summary: "Signal agent serving first-party or proprietary audience data without external catalog verification."
-track: signals
-required_tools:
-  - get_signals
-
-narrative: |
-  You operate a first-party data platform — a retailer CDP, publisher contextual data
-  provider, or proprietary audience platform. Your signals are agent-native: they come
-  from your own data, not from third-party catalogs.
-
-  Buyers trust your agent directly. There's no external adagents.json to verify against —
-  provenance is the agent itself. This simplifies the flow: discovery and activation,
-  without the verification step that marketplace agents require.
-
-  Owned signal agents often have richer signal types. A retailer might expose purchase
-  frequency as a numeric signal (0-30 visits/month) or loyalty tier as categorical
-  (platinum/gold/silver/bronze). A publisher might expose content category, subscriber
-  tenure, or engagement scores.
-
-  This storyboard walks through discovery and both activation patterns.
-
-  Pricing is hard-required here for the same reason as signal marketplaces: signals
-  are rate-carded goods. Buyers cannot activate without a pricing_option_id to anchor
-  billing. Agents distributing first-party signals without commercial terms belong on
-  a different specialism, not this one — the v2 `list_authorized_properties`
-  task is retired; portfolio advertising now lives on `get_adcp_capabilities`.
-
-agent:
-  interaction_model: owned_signals
-  capabilities: []
-  examples:
-    - "Retailer CDPs (e.g., loyalty and purchase data)"
-    - "Publisher contextual platforms (e.g., content category, subscriber data)"
-    - "First-party audience platforms (e.g., CRM-derived segments)"
-
-caller:
-  role: buyer_agent
-  example: "Scope3 (DSP)"
-
-prerequisites:
-  description: |
-    The buyer has a campaign brief with targeting objectives. The test kit provides
-    sample owned signal definitions with various value types (binary, categorical,
-    numeric) and pricing models.
-  test_kit: "test-kits/nova-motors.yaml"
-
-phases:
-  - id: capability_discovery
-    title: "Capability discovery"
-    narrative: |
-      The buyer calls get_adcp_capabilities to confirm the agent supports signals before discovering or activating audience data.
-
-    steps:
-      - id: get_capabilities
-        title: "Check agent capabilities"
-        narrative: |
-          Verify that the agent declares the expected protocol support before
-          proceeding with domain-specific operations.
-        task: get_adcp_capabilities
-        schema_ref: "protocol/get-adcp-capabilities-request.json"
-        response_schema_ref: "protocol/get-adcp-capabilities-response.json"
-        doc_ref: "/protocol/get_adcp_capabilities"
-        comply_scenario: capability_discovery
-        stateful: false
-        expected: |
-          Return capabilities declaring signals in supported_protocols, confirming the agent serves audience signals.
-        sample_request:
-          context:
-            correlation_id: "signal_owned--get_capabilities"
-        validations:
-          - check: response_schema
-            description: "Response matches get-adcp-capabilities-response.json schema"
-          - check: field_present
-            path: "supported_protocols"
-            description: "Agent declares supported protocols"
-
-          - check: field_present
-            path: "context"
-            description: "Response echoes back the context object"
-          - check: field_value
-            path: "context.correlation_id"
-            value: "signal_owned--get_capabilities"
-            description: "Context correlation_id returned unchanged"
-  - id: discovery
-    title: "Signal discovery"
-    narrative: |
-      The buyer describes targeting objectives and your agent returns matching signals
-      from your proprietary data. Unlike marketplace agents, these signals have
-      signal_type "owned" — provenance is the agent itself.
-
-      Owned signals often include richer value types. A retailer can expose loyalty
-      tiers as categorical signals and purchase frequency as numeric signals, giving
-      buyers more precise targeting than binary include/exclude.
-
-    steps:
-      - id: search_owned_signals
-        title: "Discover owned signals"
-        narrative: |
-          The buyer searches for audience segments using a natural language description.
-          Your agent returns signals from your proprietary data — loyalty tiers, purchase
-          history, engagement scores, contextual categories.
-        task: get_signals
-        schema_ref: "signals/get-signals-request.json"
-        response_schema_ref: "signals/get-signals-response.json"
-        doc_ref: "/signals/tasks/get_signals"
-        comply_scenario: signals_flow
-        stateful: false
-        expected: |
-          Return matching signals from your proprietary data. Each signal must include:
-          - signal_agent_segment_id for activation
-          - signal_id with source: "agent_native"
-          - name, description, and value_type
-          - coverage_forecast when detailed availability is disclosed; deprecated coverage_percentage may be present as a legacy scalar fallback
-          - pricing_options
-          - signal_type: "owned"
-
-          For categorical signals, include the allowed_values.
-          For numeric signals, include the range (min/max).
-
-        sample_request:
-          account:
-            brand:
-              domain: "novamotors.example"
-            operator: "pinnacle-agency.example"
-          signal_spec: "High-value customers likely to purchase electronics, with loyalty program data"
-
-          context:
-            correlation_id: "signal_owned--search_owned_signals"
-        validations:
-          - check: response_schema
-            description: "Response matches get-signals-response.json schema"
-          - check: field_present
-            path: "signals[0].signal_agent_segment_id"
-            description: "Each signal has a signal_agent_segment_id"
-          - check: field_present
-            path: "signals[0].pricing_options"
-            description: "Each signal has pricing options"
-
-          - check: field_present
-            path: "context"
-            description: "Response echoes back the context object"
-          - check: field_value
-            path: "context.correlation_id"
-            value: "signal_owned--search_owned_signals"
-            description: "Context correlation_id returned unchanged"
-          - check: field_present
-            path: "signals[0].signal_id.source"
-            description: "Signal ID includes source discriminator"
-      - id: filter_by_criteria
-        title: "Filter signals by criteria"
-        narrative: |
-          The buyer narrows the search using filters — maximum CPM, specific signal
-          types, or coverage thresholds. This tests that your agent handles filter
-          parameters correctly and returns only matching signals.
-        task: get_signals
-        schema_ref: "signals/get-signals-request.json"
-        response_schema_ref: "signals/get-signals-response.json"
-        doc_ref: "/signals/tasks/get_signals"
-        comply_scenario: signals_flow
-        stateful: false
-        expected: |
-          Return only signals matching the filter criteria. If no signals match,
-          return an empty signals array — not an error.
-
-        sample_request:
-          account:
-            brand:
-              domain: "novamotors.example"
-            operator: "pinnacle-agency.example"
-          signal_spec: "Purchase behavior signals"
-          filters:
-            max_cpm: 5.00
-
-          context:
-            correlation_id: "signal_owned--filter_by_criteria"
-        validations:
-          - check: response_schema
-            description: "Response matches schema"
-          - check: field_present
-            path: "signals"
-            description: "Response contains a signals array"
-
-          - check: field_present
-            path: "context"
-            description: "Response echoes back the context object"
-          - check: field_value
-            path: "context.correlation_id"
-            value: "signal_owned--filter_by_criteria"
-            description: "Context correlation_id returned unchanged"
-  - id: platform_activation
-    title: "Activate on a DSP"
-    narrative: |
-      The buyer activates a signal directly on a DSP. Your agent pushes the segment
-      to the platform and returns a segment_id the buyer uses for campaign targeting.
-
-      Use platform destinations when the buyer manages DSP campaigns directly.
-
-    steps:
-      - id: activate_on_platform
-        title: "Activate owned signal on a DSP"
-        narrative: |
-          The buyer selects a signal and activates it on a DSP. For owned signals,
-          this means your platform pushes first-party segment data to the DSP. The
-          buyer gets back a segment_id for targeting.
-        task: activate_signal
-        schema_ref: "signals/activate-signal-request.json"
-        response_schema_ref: "signals/activate-signal-response.json"
-        doc_ref: "/signals/tasks/activate_signal"
-        comply_scenario: signals_flow
-        stateful: true
-        expected: |
-          Return a deployment with:
-          - type: "platform"
-          - is_live status (may be async)
-          - activation_key with type: "segment_id" when live
-          - estimated_activation_duration_minutes if not immediately live
-
-        sample_request:
-          account:
-            brand:
-              domain: "novamotors.example"
-            operator: "pinnacle-agency.example"
-          signal_agent_segment_id: "prism_high_ltv"
-          pricing_option_id: "po_prism_flat_monthly"
-          destinations:
-            - type: "platform"
-              platform: "the-trade-desk"
-              account: "agency-123-ttd"
-          idempotency_key: "$generate:uuid_v4#signal_owned_activate_platform"
-          context:
-            correlation_id: "signal_owned--activate_on_platform"
-          ext:
-            test_platform:
-              test_run: true
-        validations:
-          - check: response_schema
-            description: "Response matches activate-signal-response.json schema"
-          - check: field_present
-            path: "deployments[0].type"
-            description: "Deployment includes type"
-
-          - check: field_present
-            path: "context"
-            description: "Response echoes back the context object"
-          - check: field_value
-            path: "context.correlation_id"
-            value: "signal_owned--activate_on_platform"
-            description: "Context correlation_id returned unchanged"
-  - id: agent_activation
-    title: "Activate on a sales agent"
-    narrative: |
-      The buyer activates a signal on a sales agent. The SA records the activation
-      and handles downstream DSP coordination — the buyer doesn't need to know which
-      platform the SA uses.
-
-      This is the right pattern when buying media through a sales agent.
-
-    steps:
-      - id: activate_on_agent
-        title: "Activate owned signal on a sales agent"
-        narrative: |
-          The buyer activates a signal with the SA's URL as the destination. The
-          activation is typically synchronous. The SA records it internally and
-          applies the targeting when the buyer later calls create_media_buy.
-        task: activate_signal
-        schema_ref: "signals/activate-signal-request.json"
-        response_schema_ref: "signals/activate-signal-response.json"
-        doc_ref: "/signals/tasks/activate_signal"
-        comply_scenario: signals_flow
-        stateful: true
-        expected: |
-          Return a deployment with:
-          - type: "agent"
-          - agent_url matching the SA
-          - is_live: true (sync activation)
-          - activation_key with type: "key_value"
-          - deployed_at timestamp
-
-        sample_request:
-          account:
-            brand:
-              domain: "novamotors.example"
-            operator: "pinnacle-agency.example"
-          signal_agent_segment_id: "prism_cart_abandoner"
-          pricing_option_id: "po_prism_abandoner_cpm"
-          destinations:
-            - type: "agent"
-              agent_url: "https://wonderstruck.salesagents.example"
-          idempotency_key: "$generate:uuid_v4#signal_owned_activate_agent"
-          context:
-            correlation_id: "signal_owned--activate_on_agent"
-          ext:
-            test_platform:
-              test_run: true
-        validations:
-          - check: response_schema
-            description: "Response matches activate-signal-response.json schema"
-          - check: field_present
-            path: "deployments[0].activation_key"
-            description: "Deployment includes activation key"
-          - check: field_value
-            path: "deployments[0].type"
-            value: "agent"
-            description: "Deployment type is 'agent'"
-
-          - check: field_present
-            path: "context"
-            description: "Response echoes back the context object"
-          - check: field_value
-            path: "context.correlation_id"
-            value: "signal_owned--activate_on_agent"
-            description: "Context correlation_id returned unchanged"

package/compliance/cache/3.1.0-beta.7/specialisms/sponsored-intelligence/index.yaml

@@ -1,59 +0,0 @@
-id: sponsored_intelligence
-version: "0.1.0"
-title: "Sponsored intelligence"
-protocol: sponsored-intelligence
-status: preview
-category: sponsored_intelligence
-summary: "Specialism claim for agents that expose conversational sponsored experiences via the SI session lifecycle. Preview while the underlying SI tools remain `x-status: experimental`; SDK dispatch parity with other specialism IDs."
-track: si
-
-narrative: |
-  Sponsored intelligence (SI) is the conversational ad surface inside AI assistants,
-  AI search, and generative experiences. An SI agent exposes four lifecycle tools —
-  `si_get_offering`, `si_initiate_session`, `si_send_message`, `si_terminate_session` —
-  that together drive a single sponsored conversation from discovery to handoff.
-
-  This specialism is the wire-level claim adopters make so SDKs can dispatch on a
-  specialism ID with parity to every other agent shape (`signal-marketplace`,
-  `creative-template`, `governance-spend-authority`, etc.). Without it, SI agents have
-  to be wired through escape-hatch handler bags rather than first-class platform
-  interfaces — purely because there was no enum value to key dispatch off of.
-
-  The storyboard for this specialism is a placeholder while the underlying SI tools
-  remain `x-status: experimental`. Conformance for SI agents is currently exercised by
-  the `sponsored-intelligence` protocol baseline (which already covers the full session
-  lifecycle); claiming this specialism today is graded as `{ status: "preview",
-  passed: null }` per the preview-status contract in
-  /docs/building/verification/compliance-catalog.
-
-  This specialism promotes to `stable` (with required_tools and a graded storyboard)
-  when the SI tools graduate from experimental. Sub-specialism splits may emerge as
-  the SI surface stabilizes — likely along axes like identity model (anonymous vs.
-  authenticated host-user), commerce capability (conversation-only vs. UI-component
-  vs. transactional handoff), or host surface (assistant vs. AI search vs. embedded).
-  The shape isn't committed; this narrative anticipates differentiation, it doesn't
-  specify it.
-
-agent:
-  interaction_model: si_platform
-  capabilities:
-    - sponsored_intelligence
-  examples:
-    - "AI assistants with ad support"
-    - "AI search products with sponsored experiences"
-    - "Conversational commerce agents reachable via SI handoff"
-
-caller:
-  role: buyer_agent
-  example: "Nova Motors (advertiser)"
-
-prerequisites:
-  description: |
-    No specialism-specific prerequisites today. The protocol baseline at
-    /compliance/{version}/protocols/sponsored-intelligence/ exercises the full
-    discover → initiate → message → terminate flow against the shared Nova Motors
-    test kit; preview claims of this specialism inherit those scenarios for
-    runner discoverability without producing a graded verdict.
-  test_kit: "test-kits/nova-motors.yaml"
-
-phases: []

package/compliance/cache/3.1.0-beta.7/test-kits/acme-outdoor-live.yaml

@@ -1,78 +0,0 @@
-# Acme Outdoor — Live-Mode Principal Test Kit
-#
-# Entity definition: fictional-entities.yaml → advertisers[acme_outdoor]
-#
-# Live-mode counterpart to acme-outdoor.yaml. Used exclusively by the
-# comply-controller-mode-gate storyboard to supply a non-sandbox principal:
-# the seller's gate must resolve the calling account, detect mode: live, and
-# return ControllerError.error: FORBIDDEN before dispatching any scenario.
-#
-# IMPORTANT: sandbox: false here signals that this principal represents a
-# live/production account for the purpose of controller gating tests. It does
-# NOT mean this kit is used in production grading — the kit is only loaded by
-# the comply_controller_mode_gate storyboard, which requires: [controller]
-# and is dev/staging-only by design.
-
-id: acme_outdoor_live
-name: "Acme Outdoor (Live Mode)"
-description: "Fictional outdoor gear brand — live-mode principal for comply_test_controller denial storyboard"
-sandbox: false
-
-# Authentication fixture for the comply-controller-mode-gate storyboard.
-# The api_key here represents a live-mode (non-sandbox) credential. When the
-# runner sends requests using this key, a conformant seller resolves the
-# account, determines mode: live, and refuses comply_test_controller dispatch
-# with FORBIDDEN.
-#
-# The demo-acme-outdoor-live- prefix signals this is a test harness key whose
-# account resolves as live-mode on conformant implementations.
-auth:
-  api_key: "demo-acme-outdoor-live-v1"
-  probe_task: list_creatives
-
-brand:
-  house:
-    domain: "acmeoutdoor.example"
-    name: "Acme Outdoor"
-  brand_id: "acme_outdoor"
-  names:
-    - en: "Acme Outdoor"
-  description: "Premium outdoor gear for every adventure. From trail to summit, we make gear that performs."
-  industry: "retail"
-  keller_type: "master"
-  logos:
-    - url: "https://test-assets.adcontextprotocol.org/acme-outdoor/logo-primary.png"
-      orientation: "horizontal"
-      background: "light-bg"
-      variant: "primary"
-      width: 400
-      height: 100
-  colors:
-    primary: "#1B5E20"
-    secondary: "#FF6F00"
-    accent: "#FDD835"
-    background: "#FAFAFA"
-    text: "#212121"
-  fonts:
-    heading:
-      family: "Montserrat"
-      weight: 700
-      url: "https://fonts.googleapis.com/css2?family=Montserrat:wght@700"
-    body:
-      family: "Open Sans"
-      weight: 400
-      url: "https://fonts.googleapis.com/css2?family=Open+Sans"
-  tone:
-    voice: "Confident and adventurous, but never pretentious. We talk to people who do things, not people who buy things."
-    attributes:
-      - "active"
-      - "direct"
-      - "warm"
-    dos:
-      - "Use action verbs"
-      - "Reference real outdoor activities"
-      - "Keep it short"
-    donts:
-      - "Use superlatives without evidence"
-      - "Talk down to the reader"
-      - "Use corporate jargon"

package/compliance/cache/3.1.0-beta.7/test-kits/acme-outdoor.yaml

@@ -1,223 +0,0 @@
-# Acme Outdoor — Sample Advertiser Test Kit
-#
-# Entity definition: fictional-entities.yaml → advertisers[acme_outdoor]
-#
-# Provides the "ingredients" needed to test creative agent storyboards:
-# a brand identity, sample assets at common dimensions, and sample text.
-#
-# This brand is registered as a sandbox brand in AgenticAdvertising.org (AAO).
-# Agents resolve acmeoutdoor.example via the standard AAO brand resolution path.
-# AAO returns the brand.json below but excludes sandbox brands from production
-# brand discovery results.
-
-id: acme_outdoor
-name: "Acme Outdoor"
-description: "Fictional outdoor gear brand for storyboard testing"
-sandbox: true
-
-# Set to true when the agent under test declares at least one audio format in
-# list_creative_formats. Enables the audio_build phase in the creative_template
-# storyboard. Leave false for display-only template agents.
-supports_audio_formats: false
-
-# Authentication fixture for the universal security_baseline storyboard
-# (universal/security.yaml). Declares:
-#   - api_key: the demo Bearer the runner sends on the positive api-key
-#     probe. The conformance handle is the `demo-<kit>-` prefix — agents
-#     SHOULD accept any Bearer matching that prefix (not this literal
-#     value) so the suffix can rotate across spec versions without
-#     breaking previously-conformant agents.
-#   - probe_task: the protected, auth-required read the runner calls under
-#     `auth: none` and with a random-invalid key. Default is list_creatives;
-#     declare explicitly so the api_key phase runs instead of being skipped
-#     via `skip_if: "!test_kit.auth.api_key"`.
-auth:
-  api_key: "demo-acme-outdoor-v1"
-  probe_task: list_creatives
-
-brand:
-  house:
-    domain: "acmeoutdoor.example"
-    name: "Acme Outdoor"
-  brand_id: "acme_outdoor"
-  names:
-    - en: "Acme Outdoor"
-  description: "Premium outdoor gear for every adventure. From trail to summit, we make gear that performs."
-  industry: "retail"
-  keller_type: "master"
-  logos:
-    - url: "https://test-assets.adcontextprotocol.org/acme-outdoor/logo-primary.png"
-      orientation: "horizontal"
-      background: "light-bg"
-      variant: "primary"
-      width: 400
-      height: 100
-    - url: "https://test-assets.adcontextprotocol.org/acme-outdoor/logo-icon.png"
-      orientation: "square"
-      background: "transparent-bg"
-      variant: "icon"
-      width: 200
-      height: 200
-  colors:
-    primary: "#1B5E20"
-    secondary: "#FF6F00"
-    accent: "#FDD835"
-    background: "#FAFAFA"
-    text: "#212121"
-  fonts:
-    heading:
-      family: "Montserrat"
-      weight: 700
-      url: "https://fonts.googleapis.com/css2?family=Montserrat:wght@700"
-    body:
-      family: "Open Sans"
-      weight: 400
-      url: "https://fonts.googleapis.com/css2?family=Open+Sans"
-  tone:
-    voice: "Confident and adventurous, but never pretentious. We talk to people who do things, not people who buy things."
-    attributes:
-      - "active"
-      - "direct"
-      - "warm"
-    dos:
-      - "Use action verbs"
-      - "Reference real outdoor activities"
-      - "Keep it short"
-    donts:
-      - "Use superlatives without evidence"
-      - "Talk down to the reader"
-      - "Use corporate jargon"
-
-# Sample assets at common ad dimensions.
-# These are placeholder URLs — in production, these would point to actual hosted test images.
-assets:
-  images:
-    - id: "hero_300x250"
-      url: "https://test-assets.adcontextprotocol.org/acme-outdoor/hero-300x250.jpg"
-      width: 300
-      height: 250
-      mime_type: "image/jpeg"
-      description: "Medium rectangle hero — hiker on mountain trail"
-
-    - id: "hero_728x90"
-      url: "https://test-assets.adcontextprotocol.org/acme-outdoor/hero-728x90.jpg"
-      width: 728
-      height: 90
-      mime_type: "image/jpeg"
-      description: "Leaderboard hero — panoramic mountain vista"
-
-    - id: "hero_320x50"
-      url: "https://test-assets.adcontextprotocol.org/acme-outdoor/hero-320x50.jpg"
-      width: 320
-      height: 50
-      mime_type: "image/jpeg"
-      description: "Mobile banner hero — trail gear close-up"
-
-    - id: "hero_160x600"
-      url: "https://test-assets.adcontextprotocol.org/acme-outdoor/hero-160x600.jpg"
-      width: 160
-      height: 600
-      mime_type: "image/jpeg"
-      description: "Wide skyscraper hero — vertical trail scene"
-
-    - id: "hero_master"
-      url: "https://test-assets.adcontextprotocol.org/acme-outdoor/hero-master.jpg"
-      width: 1200
-      height: 628
-      mime_type: "image/jpeg"
-      description: "Master hero image — high-res source for any size"
-
-  text:
-    headlines:
-      - "Summer Sale — 40% Off All Gear"
-      - "Built for the Trail"
-      - "Adventure Starts Here"
-    descriptions:
-      - "Premium outdoor gear tested on the world's toughest trails. Shop the summer collection."
-      - "From daypacks to expedition tents, gear that performs when it matters."
-    cta:
-      - "Shop Now"
-      - "Explore the Collection"
-      - "Find Your Gear"
-
-  # Reference content for the creative_template audio_build phase.
-  # These values are hardcoded in the storyboard sample_request; this block
-  # documents the canonical Acme Outdoor audio creative inputs for adopters
-  # authoring audio format specs or runner integrations.
-  audio:
-    script: "Built for the trail. Acme Outdoor — premium gear for every adventure."
-    voice_hint: "narrator-warm"
-
-  click_url: "https://acmeoutdoor.example/summer-sale"
-
-# Inventory list fixtures for property_list / collection_list targeting tests.
-#
-# These reference lists a fictional governance/inventory agent would publish.
-# They let storyboards exercise the full PropertyListReference / CollectionListReference
-# contract without needing a live list server: scenarios point at list_id values
-# and the seller's test engine returns canned contents.
-#
-# Both matching and non-matching sets are provided so a single test fixture
-# covers targeting (buy should include listed inventory) and no-match behaviour
-# (buy references a list that resolves to zero matches in this seller's catalog).
-inventory_targets:
-  # --- Matching sets (Acme Outdoor's intended audience) ---
-  matching_properties:
-    agent_url: "https://governance.pinnacle-agency.example"
-    list_id: "acme_outdoor_allowlist_v1"
-    description: "Outdoor lifestyle properties relevant to Acme Outdoor campaigns."
-    # Expected contents when the list is fetched via get_property_list.
-    expected_identifiers:
-      - type: domain
-        value: "outdoormagazine.example"
-      - type: domain
-        value: "hikingtrails.example"
-      - type: domain
-        value: "campinggear.example"
-      - type: domain
-        value: "mountaineering.example"
-
-  matching_collections:
-    agent_url: "https://governance.pinnacle-agency.example"
-    list_id: "acme_outdoor_collections_v1"
-    description: "Outdoor programming the buyer wants to run alongside."
-    # Expected collection entries when fetched via get_collection_list.
-    expected_collections:
-      - collection_rid: "rid:outdoor:trail_life"
-        name: "Trail Life"
-        kind: "series"
-        genre: "outdoor"
-        distribution_ids:
-          - type: imdb_id
-            value: "tt9100001"
-      - collection_rid: "rid:outdoor:summit_stories"
-        name: "Summit Stories"
-        kind: "series"
-        genre: "outdoor"
-        distribution_ids:
-          - type: imdb_id
-            value: "tt9100002"
-
-  # --- No-match sets (nothing in this seller's catalog matches) ---
-  no_match_properties:
-    agent_url: "https://governance.pinnacle-agency.example"
-    list_id: "acme_outdoor_no_match_v1"
-    description: "Properties outside this seller's inventory — should yield zero matches."
-    expected_identifiers:
-      - type: domain
-        value: "never-sold-here.example"
-      - type: domain
-        value: "also-not-indexed.example"
-
-  no_match_collections:
-    agent_url: "https://governance.pinnacle-agency.example"
-    list_id: "acme_outdoor_no_match_collections_v1"
-    description: "Collections not carried by this seller — should yield zero matches."
-    expected_collections:
-      - collection_rid: "rid:food:bistro_kitchen"
-        name: "Bistro Kitchen"
-        kind: "series"
-        genre: "food"
-        distribution_ids:
-          - type: imdb_id
-            value: "tt9200001"