@adcp/sdk 7.10.2 → 7.11.1

package/compliance/cache/3.1.0-rc.2/specialisms/signal-owned/index.yaml

@@ -0,0 +1,317 @@
+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-rc.2/specialisms/sponsored-intelligence/index.yaml

@@ -0,0 +1,59 @@
+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-rc.2/test-kits/acme-outdoor-live.yaml

@@ -0,0 +1,78 @@
+# 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-rc.2/test-kits/acme-outdoor.yaml

@@ -0,0 +1,223 @@
+# 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"