@adcp/sdk 14.0.0-rc.49 → 14.0.0-rc.50

package/dist/lib/schemas-data/3.1/core/product-filters.json

@@ -1,15 +1,15 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/product-filters.json",
+  "$id": "/schemas/3.1.24/core/product-filters.json",
   "title": "Product Filters",
   "description": "Structured filters for product discovery",
   "type": "object",
   "properties": {
     "delivery_type": {
-      "$ref": "/schemas/3.1.18/enums/delivery-type.json"
+      "$ref": "/schemas/3.1.24/enums/delivery-type.json"
     },
     "exclusivity": {
-      "$ref": "/schemas/3.1.18/enums/exclusivity.json",
+      "$ref": "/schemas/3.1.24/enums/exclusivity.json",
       "description": "Filter by exclusivity level. Returns products matching the specified exclusivity (e.g., 'exclusive' returns only sole-sponsorship products)."
     },
     "is_fixed_price": {
@@ -32,7 +32,7 @@
       "type": "array",
       "description": "Filter by specific format IDs",
       "items": {
-        "$ref": "/schemas/3.1.18/core/format-id.json"
+        "$ref": "/schemas/3.1.24/core/format-id.json"
       },
       "minItems": 1
     },
@@ -117,7 +117,7 @@
         "type": "object",
         "properties": {
           "system": {
-            "$ref": "/schemas/3.1.18/enums/metro-system.json",
+            "$ref": "/schemas/3.1.24/enums/metro-system.json",
             "description": "Metro classification system"
           },
           "code": {
@@ -137,7 +137,7 @@
       "type": "array",
       "description": "Filter by advertising channels (e.g., ['display', 'ctv', 'dooh'])",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/channels.json"
+        "$ref": "/schemas/3.1.24/enums/channels.json"
       },
       "minItems": 1
     },
@@ -145,7 +145,7 @@
       "type": "array",
       "description": "Filter video products by acceptable declared video placement types, using IAB Tech Lab/OpenRTB 2.6 video.plcmt definitions with AdCP-native names. Sellers SHOULD return only products they can satisfy with at least one requested type. Products whose only available delivery is a mixed, non-targetable bundle that includes unrequested video placement types SHOULD NOT match unless the seller can constrain delivery to the requested type during planning or purchase. This filter has set semantics for wholesale feed canonicalization.",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/video-placement-type.json"
+        "$ref": "/schemas/3.1.24/enums/video-placement-type.json"
       },
       "uniqueItems": true,
       "minItems": 1,
@@ -155,7 +155,7 @@
       "type": "array",
       "description": "Filter audio products by acceptable declared audio distribution types, using IAB Tech Lab/OpenRTB 2.6 audio.feed definitions with AdCP-native names. Sellers SHOULD return only products they can satisfy with at least one requested type. Products whose only available delivery is a mixed, non-targetable bundle that includes unrequested audio distribution types SHOULD NOT match unless the seller can constrain delivery to the requested type during planning or purchase. This filter has set semantics for wholesale feed canonicalization.",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/audio-distribution-type.json"
+        "$ref": "/schemas/3.1.24/enums/audio-distribution-type.json"
       },
       "uniqueItems": true,
       "minItems": 1,
@@ -165,7 +165,7 @@
       "type": "array",
       "description": "Filter retail-media products by acceptable declared sponsored-placement types (sponsored search, sponsored display, or sponsored native). Sellers SHOULD return only products they can satisfy with at least one requested type. Products whose only available delivery is a mixed, non-targetable bundle that includes unrequested sponsored-placement types SHOULD NOT match unless the seller can constrain delivery to the requested type during planning or purchase. This filter has set semantics for wholesale feed canonicalization.",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/sponsored-placement-type.json"
+        "$ref": "/schemas/3.1.24/enums/sponsored-placement-type.json"
       },
       "uniqueItems": true,
       "minItems": 1,
@@ -175,7 +175,7 @@
       "type": "array",
       "description": "Filter social products by acceptable declared social-placement surfaces (feed, stories, short_video, explore, or search). Sellers SHOULD return only products they can satisfy with at least one requested surface. Products whose only available delivery is a mixed, non-targetable bundle that includes unrequested surfaces SHOULD NOT match unless the seller can constrain delivery to the requested surface during planning or purchase. This filter has set semantics for wholesale feed canonicalization.",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/social-placement-surface.json"
+        "$ref": "/schemas/3.1.24/enums/social-placement-surface.json"
       },
       "uniqueItems": true,
       "minItems": 1,
@@ -226,7 +226,7 @@
           "type": "array",
           "description": "Filter to products supporting specific TMP response types (e.g., 'activation', 'creative', 'catalog_items'). Products must support at least one of the listed types.",
           "items": {
-            "$ref": "/schemas/3.1.18/enums/response-type.json"
+            "$ref": "/schemas/3.1.24/enums/response-type.json"
           },
           "minItems": 1
         }
@@ -234,7 +234,7 @@
       "additionalProperties": false
     },
     "required_features": {
-      "$ref": "/schemas/3.1.18/core/media-buy-features.json",
+      "$ref": "/schemas/3.1.24/core/media-buy-features.json",
       "description": "Filter to products from sellers supporting specific protocol features. Only features set to true are used for filtering."
     },
     "required_geo_targeting": {
@@ -244,7 +244,7 @@
         "type": "object",
         "properties": {
           "level": {
-            "$ref": "/schemas/3.1.18/enums/geo-level.json",
+            "$ref": "/schemas/3.1.24/enums/geo-level.json",
             "description": "Geographic targeting level (country, region, metro, postal_area)"
           },
           "country": {
@@ -315,7 +315,7 @@
                 {
                   "properties": {
                     "system": {
-                      "$ref": "/schemas/3.1.18/enums/metro-system.json"
+                      "$ref": "/schemas/3.1.24/enums/metro-system.json"
                     }
                   },
                   "required": [
@@ -360,12 +360,12 @@
                   }
                 },
                 {
-                  "$ref": "/schemas/3.1.18/core/postal-country-system.json"
+                  "$ref": "/schemas/3.1.24/core/postal-country-system.json"
                 },
                 {
                   "properties": {
                     "system": {
-                      "$ref": "/schemas/3.1.18/enums/legacy-postal-system.json"
+                      "$ref": "/schemas/3.1.24/enums/legacy-postal-system.json"
                     }
                   },
                   "required": [
@@ -392,7 +392,7 @@
         "type": "object",
         "allOf": [
           {
-            "$ref": "/schemas/3.1.18/core/signal-targeting.json"
+            "$ref": "/schemas/3.1.24/core/signal-targeting.json"
           }
         ],
         "properties": {
@@ -413,7 +413,7 @@
       "type": "array",
       "description": "Filter by postal area coverage for locally-bound inventory (direct mail, DOOH, local campaigns). Prefer the native country + postal system form. Deprecated legacy country-fused postal-system tokens remain accepted for compatibility. For digital inventory where products have broad coverage, use required_geo_targeting instead to filter by seller capability.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/postal-area.json"
+        "$ref": "/schemas/3.1.24/core/postal-area.json"
       },
       "minItems": 1
     },
@@ -449,7 +449,7 @@
                 "description": "Travel time limit"
               },
               "unit": {
-                "$ref": "/schemas/3.1.18/enums/travel-time-unit.json"
+                "$ref": "/schemas/3.1.24/enums/travel-time-unit.json"
               }
             },
             "required": [
@@ -459,7 +459,7 @@
             "additionalProperties": false
           },
           "transport_mode": {
-            "$ref": "/schemas/3.1.18/enums/transport-mode.json",
+            "$ref": "/schemas/3.1.24/enums/transport-mode.json",
             "description": "Transportation mode for isochrone calculation. Required when travel_time is provided."
           },
           "radius": {
@@ -472,7 +472,7 @@
                 "description": "Radius distance"
               },
               "unit": {
-                "$ref": "/schemas/3.1.18/enums/distance-unit.json",
+                "$ref": "/schemas/3.1.24/enums/distance-unit.json",
                 "description": "Distance unit"
               }
             },
@@ -578,7 +578,7 @@
       "type": "array",
       "description": "Filter to products that can meet the buyer's performance standard requirements. Each entry specifies a metric, minimum threshold, and optionally a required vendor and standard. Products that cannot meet these thresholds or do not support the specified vendors are excluded. Use this to tell the seller upfront: 'I need DoubleVerify for viewability at 70% MRC.'",
       "items": {
-        "$ref": "/schemas/3.1.18/core/performance-standard.json"
+        "$ref": "/schemas/3.1.24/core/performance-standard.json"
       },
       "minItems": 1
     },
@@ -586,7 +586,7 @@
       "type": "array",
       "description": "Filter to products whose `reporting_capabilities.available_metrics` is a superset of these metrics — i.e., products that commit to reporting all listed metrics in delivery responses. Use this for capability-level discovery (e.g., 'I need products that report `completed_views` for a CTV CPCV buy'); guarantee-level requirements with thresholds belong in `required_performance_standards` and `measurement_terms`. Sellers MUST silently exclude products that cannot meet this list (filter-not-fail; do not return an error). The product's declared `available_metrics` becomes the binding reporting contract carried into the resulting media buy — the same metric vocabulary is used to compute `missing_metrics` on `get_media_buy_delivery`.",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/available-metric.json"
+        "$ref": "/schemas/3.1.24/enums/available-metric.json"
       },
       "minItems": 1,
       "uniqueItems": true,
@@ -612,11 +612,11 @@
         "type": "object",
         "properties": {
           "vendor": {
-            "$ref": "/schemas/3.1.18/core/brand-ref.json",
+            "$ref": "/schemas/3.1.24/core/brand-ref.json",
             "description": "Pin to a specific vendor. Optional — omit to match any vendor offering this `metric_id`."
           },
           "metric_id": {
-            "$ref": "/schemas/3.1.18/core/vendor-metric-id.json",
+            "$ref": "/schemas/3.1.24/core/vendor-metric-id.json",
             "description": "Pin to an exact metric identifier within a vendor's vocabulary. Optional — omit to match any metric from the pinned vendor. Cross-vendor identifier matching only works after vendors converge on identifiers (typically post-standardization)."
           }
         },
@@ -677,7 +677,7 @@
             "description": "The keyword to target"
           },
           "match_type": {
-            "$ref": "/schemas/3.1.18/enums/match-type.json",
+            "$ref": "/schemas/3.1.24/enums/match-type.json",
             "default": "broad"
           }
         },
@@ -689,7 +689,7 @@
       "minItems": 1
     },
     "ext": {
-      "$ref": "/schemas/3.1.18/core/ext.json",
+      "$ref": "/schemas/3.1.24/core/ext.json",
       "description": "Vendor-namespaced extension parameters for seller-specific filter criteria not covered by standard fields. Keys MUST be namespaced under a vendor or platform key (e.g., ext.gam, ext.platform_x). Sellers MUST treat all values as untrusted buyer input; do not interpolate into LLM prompts, SQL queries, or system commands without sanitization. Persistent use of an extension key across multiple buyers is a signal to propose standardization."
     }
   },

package/dist/lib/schemas-data/3.1/core/product-format-declaration.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/product-format-declaration.json",
+  "$id": "/schemas/3.1.24/core/product-format-declaration.json",
   "title": "Product Format Declaration",
   "description": "Inline format declaration on a product. The `format_kind` discriminator names which canonical format the product narrows; `params` carries the canonical's parameter schema (slots, dimensions, durations, codecs, character limits, platform_extensions, etc.). Optional `format_option_id` (stable identifier for routing when a product's `format_options` contains multiple declarations sharing the same `format_kind`), optional `publisher_domain` (namespace for the format option when it comes from a publisher adagents.json catalog), `display_name` (seller-controlled human-readable label for dashboard and catalog UIs), and `applies_to_channels` (subset of the product's declared channels this declaration applies to — lets a multi-channel product carry distinct format_options per channel). Discriminated-union shape generates clean tagged unions in TypeScript and Pydantic codegen. Replaces v1's named-format pattern (where products referenced a separately-defined format file via compound `format_id`). v1 named formats remain supported through the deprecation cycle; v2 product-bound declarations are opt-in.\n\n**Closed-set semantics (normative).** `format_options[]` is the closed set of accepted formats for this product. Sellers MUST reject `create_media_buy` requests targeting any `format_kind` (or format option reference) not present in this list — typically with `UNSUPPORTED_FEATURE` or a seller-specific code; the rejection is structural, not negotiable. `seller_preference` modulates *within* the accepted set (a soft ranking hint between equally-acceptable options), it is NOT an enforcement axis. A product wanting to say 'this format is the only one that works' lists exactly that one entry in `format_options[]`; everything else falls outside the set and is rejected by the closed-set rule.\n\n**Format matching vs satisfaction (normative).** Legacy named formats MUST be normalized to canonical declarations before comparison; do not exact-match raw `(agent_url, id)` pairs once a `format_id` has been projected through `canonical`, `v1_format_ref`, or the canonical mapping registry. Equivalence matching can treat a legacy fixed-size display ID and `format_kind: \"image\"` with matching `width`/`height` as the same underlying shape. Product satisfaction is stricter and directional: when this declaration specifies fixed constraints such as `width`, `height`, `duration_ms_exact`, or `duration_ms_range`, a buyer request or creative manifest MUST declare and satisfy those constraints. A broad request with no dimensions or duration does not satisfy a fixed-size or fixed-duration product; a broad product MAY accept a more specific creative unless another product constraint excludes it. Duration precedence is `duration_ms_exact` > `duration_ms_range`. Range constraints use containment: a range-based request satisfies this declaration only when every value it permits falls within this declaration's accepted range; overlap alone is insufficient. An exact value satisfies a range when the exact value falls inside the accepted interval. For hosted audio/video, a null range endpoint is unbounded: [null, 60000] means up to 60s, and [15000, null] means at least 15s; [null, null] is invalid because at least one endpoint must be bounded.\n\n**Custom format_kind** (`format_kind: \"custom\"`): for adopter-defined shapes that don't fit the 12 canonicals (multi-placement takeover, roadblock, branded content, cross-screen sponsorship, sponsorship lockup, newsletter sponsorship, AR lens, playable, live event sponsorship). When `format_kind` is `custom`, the declaration MUST carry `format_shape` (recognized global pattern from the [format-shape vocabulary registry](/schemas/core/format-shape-vocabulary.json)) AND `format_schema` (URI+digest reference to a fetchable schema describing the actual `params` and `slots`). Buyer agents fetch the schema, validate manifests structurally, and reason about manifests without per-seller integration code. See [adcp#3666](https://github.com/adcontextprotocol/adcp/issues/3666) for the canonical promotion queue.",
   "type": "object",
@@ -28,7 +28,7 @@
     "applies_to_channels": {
       "type": "array",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/channels.json"
+        "$ref": "/schemas/3.1.24/enums/channels.json"
       },
       "uniqueItems": true,
       "description": "Optional subset of the parent product's `channels` to which this declaration applies. When omitted, the declaration applies to ALL channels declared on the product. Lets a multi-channel product (e.g., `channels: ['display', 'video']`) carry distinct format_options per channel — `format_options: [{format_kind: 'image', applies_to_channels: ['display']}, {format_kind: 'video_hosted', applies_to_channels: ['video']}]`. Buyers ship channel-appropriate manifests per `applies_to_channels`."
@@ -60,12 +60,12 @@
       "type": "array",
       "minItems": 1,
       "items": {
-        "$ref": "/schemas/3.1.18/core/format-id.json"
+        "$ref": "/schemas/3.1.24/core/format-id.json"
       },
       "description": "Authoritative v2 → v1 link, expressed as an array of one or more v1 `format_id` ({agent_url, id}) values. Each entry asserts that this canonical-formats declaration IS the same underlying format as the referenced v1 named format. Always an array (single-ref is `[{...}]`) so the multi-size case below has a clean wire shape — adopters surveyed in the SDK implementor review pushed for this over the lossy single-ref form.\n\nThe v2 declaration's `params` MUST narrow (be compatible with) each referenced v1 format's `requirements` — see the 'Narrows — formal definition' section in canonical-formats.mdx. SDKs comparing dual-emitted shapes (`Product.format_ids[]` ⊇ entries from `v1_format_ref` AND `Product.format_options[]` carrying this declaration) treat the link as the authoritative pairing and run the narrowing check between this declaration and EACH referenced v1 format file's `requirements`.\n\n**Multi-size fan-out (normative).** When the declaration carries `params.sizes: [{w,h}, ...]` (multi-size flexible slot), sellers SHOULD carry one `v1_format_ref[]` entry per size, each pointing at the per-size v1 named format in the AAO catalog. Example: a multi-size image declaration with `sizes: [300x250, 728x90, 970x250]` SHOULD carry `v1_format_ref: [{aao, display_300x250_image}, {aao, display_728x90_image}, {aao, display_970x250_image}]`. v1-only buyers then see the product on all three sizes via the `format_ids[]` dual-emission. When `v1_format_ref[]` count < `sizes[]` count, SDKs MUST emit `FORMAT_DECLARATION_V1_LOSSY_MULTI_SIZE` on the response `errors[]` (advisory, alongside the partial-coverage v1 emit — NOT in place of it). SDKs MAY (non-normative) fan out automatically by catalog lookup when `v1_format_ref[]` has length 1 and `sizes[]` has length N — opt-in, requires catalog access; sellers asserting refs is the source of truth.\n\nMutually exclusive with `canonical_formats_only: true` — a declaration can EITHER assert no v1 projection (`canonical_formats_only: true`) OR link to v1 named formats (`v1_format_ref[]`), never both. When neither is present, SDKs fall back to the resolution order in `v1-canonical-mapping.json` (seller's explicit `canonical` field on the v1 file → registry glob → structural match → fail-closed).\n\nThis is the v2-side authoritative replacement for the v1-side `canonical_parameters` field on `format.json` (which is deprecated for 3.1, removed at 4.0). Sellers SHOULD prefer authoring v2 declarations with `v1_format_ref[]` over mirroring the v2 shape onto v1 files via `canonical_parameters`; the directional link (v2 declaration → v1 identifiers) is the same fact without the parallel-shape drift surface.\n\n**AAO-hosted convention (normative).** For IAB-standard formats (image dimensions, VAST/DAAST tags, standard third-party tags, HTML5 banner bundles), sellers SHOULD point each `v1_format_ref[].agent_url` at the AAO-hosted canonical agent URL `https://creative.adcontextprotocol.org` and use the registry-published id (e.g., `display_300x250_image`, `video_vast_30s`, `audio_standard_30s`, `display_300x250_html`, `display_js`). This converges the v1-wire namespace: every seller's IAB MREC points at the same `{agent_url, id}` pair, so v1-only buyers' allowlists work uniformly. Without this convention, every publisher's 300x250 ships with a different `v1_format_ref` (theirs vs nytimes.example vs cnn.example vs …) and the v1 wire fragments into per-publisher namespaces — exactly what canonical-formats was designed to eliminate.\n\nFor platform-specific formats (Meta Reels, TikTok Spark, Snap Spotlight, etc.), each `v1_format_ref[].agent_url` SHOULD point at the platform's own agent_url when the platform has adopted AdCP and publishes its own `adagents.json` with `formats[]`. When the platform has NOT adopted AdCP, sellers SHOULD point at the AAO community-registry mirror — `https://creative.adcontextprotocol.org/translated/<platform>` + `id: <platform-format-name>` (e.g., `https://creative.adcontextprotocol.org/translated/meta` + `id: meta_reels`). This keeps the v1 namespace converged across all sellers selling that platform's inventory until the platform owns its own adagents.json.\n\n**Platform-adoption cutover (normative).** When a platform adopts AdCP and publishes its own adagents.json, sellers MUST update `v1_format_ref[].agent_url` to the platform's adopted agent_url in the same minor release as the AAO mirror entry's `superseded_by` field goes live (see `static/schemas/source/adagents.json#superseded_by`). The AAO mirror entry SHOULD continue serving for ≥1 minor release after `superseded_by` is set, returning an advisory 'superseded' marker so v1 buyer allowlists keyed on the mirror URL get an explicit signal rather than a silent break. **Identity-confusion note**: the mirror URL is *format-shape namespace*, NOT seller identity. Inventory authorization always flows from `authorized_agents[]` + publisher signing keys; a buyer matching `v1_format_ref[].agent_url` against an allowlist is matching format-shape provenance, not seller identity.\n\n**Mirror domain migration (3.1).** Earlier drafts used `https://mirror.adcontextprotocol.org/translated/<platform>`. As of this release, the convention is `https://creative.adcontextprotocol.org/translated/<platform>` — sibling content under the AAO catalog domain we already host. Adopters who hardcoded the earlier mirror URL MUST migrate to the new path; the canonical-formats.mdx migration section documents the move. No transitional redirect is currently published (the earlier subdomain was never provisioned).\n\nFor seller-bespoke formats (a publisher's `acme_homepage_takeover` that doesn't fit IAB conventions), each `v1_format_ref[].agent_url` is the seller's own agent_url and the id is seller-namespaced. These won't appear in `v1-canonical-mapping.json`'s registry; they're seller-asserted only."
     },
     "format_schema": {
-      "$ref": "/schemas/3.1.18/core/platform-extension-ref.json",
+      "$ref": "/schemas/3.1.24/core/platform-extension-ref.json",
       "description": "REQUIRED when `format_kind: \"custom\"`; otherwise MUST be absent. URI+digest reference to a fetchable schema describing this custom shape's actual `params` and `slots`. Same hosting model as `platform_extensions`: open-ecosystem publishers host the artifact at the canonical URI on their subdomain; closed-platform / walled-garden shapes resolve through the AAO mirror at `https://creative.adcontextprotocol.org/translated/...`. Buyer agents fetch by `uri@digest` (immutable per digest, aggressive caching, `Cache-Control: public, max-age=31536000, immutable`), validate `params` and `slots` against the fetched schema, and reason about manifests structurally — same mechanic as platform_extensions but at the format-structure level. Without `format_schema`, custom shapes would be opaque to buyer agents and the protocol would regress to per-seller integration code; that's why the schema is required, not optional.\n\n**Fetch contract (normative)** — `format_schema` is load-bearing for validation (unlike `platform_extensions`, which is informational on the *consumption* side). The *transport* rules below apply identically to BOTH fields — any SDK fetching a `platform-extension-ref.json` URI MUST apply this contract regardless of whether the field name is `format_schema` or `platform_extensions`. A shared SDK fetch path that drops to the weakest bar undermines `format_schema`'s hardening. The consumption distinction (load-bearing vs informational) is about *what the body means*; the transport distinction is `https`-and-allowlisted regardless.\n\n- **Transport**: `https` only. Buyers MUST reject `http://`, `file://`, `data:`, and any non-`https` scheme. The URI MUST resolve to a JSON document that is itself a valid JSON Schema (Draft 07 or 2020-12; producers MUST declare `$schema`).\n- **SSRF protection**: buyers MUST resolve the URI hostname and reject if any resolved address is in RFC 1918 private space (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`), loopback (`127.0.0.0/8`, `::1`), link-local (`169.254.0.0/16`, `fe80::/10`), CGNAT (`100.64.0.0/10`), or any RFC 6761 special-use name (`.local`, `.localhost`, `.internal`, `.test`, `.example`, `.invalid`). Cloud metadata endpoints (`169.254.169.254`, `metadata.google.internal`, `kubernetes.default.svc`) are explicitly forbidden — these are credential-leak primitives. Buyers MUST pin the connection to the resolved IP (or re-resolve and re-validate the allowlist per request) to defeat DNS rebinding.\n- **HTTP redirects**: MUST be disabled. If a follow is implemented at all, the redirect target MUST pass the same scheme + SSRF + allowlist checks; otherwise the fetch hard-fails. Open redirects on same-origin paths are otherwise a free SSRF primitive.\n- **Response size cap**: response body MUST be capped at 1 MiB. Enforce during streaming, not after full buffering. Over-cap hard-fails identically to digest mismatch.\n- **Timeout**: SDKs SHOULD apply a fetch timeout ≤5 seconds. Timeout SHOULD be treated identically to an HTTP 5xx response (transient — retry policy at the SDK's discretion; on persistent failure surface as unresolved and skip the declaration for this session).\n- **Digest verification**: SHA-256 of the response body MUST equal `digest`. **Digest mismatch is a hard fail** — the buyer MUST treat the format declaration as unresolvable and MUST NOT validate manifests against the mismatched body. A divergent digest is either a malicious substitution or producer error; either way, falling back to the un-verified body breaks the trust model. Digest format: `sha256:` prefix + 64 lowercase hex characters. Cache key is `uri@digest`; digest mismatch MUST NOT be cached as a negative result keyed on `uri` alone (defeats CDN-flap recovery), and MUST be distinguishable in telemetry from network 5xx / 404 (sustained mismatch is a substitution-attack signal, not a flap).\n- **Sandboxing of `$ref`**: fetched schemas MAY use `$ref`. Buyers MUST resolve `$ref` only to URIs that are (a) same-origin as the parent `format_schema.uri` after RFC 3986 §6 normalization (lowercase scheme + host, strip default port, normalize path dot-segments, no userinfo component), OR (b) hosted under the AAO catalog domain (`https://creative.adcontextprotocol.org/...`), OR (c) intra-document JSON Pointer refs (`#/...`) bounded to the parent document's parsed tree. Cross-origin `$ref` to arbitrary URIs MUST be rejected. `$ref: file://...` MUST be rejected unconditionally. Transitive `$ref` chains MUST be bounded at depth ≤8 AND `$ref` count ≤256 across the resolved tree (depth 8 with breadth 100 per level is 10^16 nodes — depth alone is not enough). Publishers SHOULD inline rather than $ref where possible.\n- **Schema-compile bounds (DoS protection)**: validators MUST bound CPU/memory on fetched schemas. Recommended: compiled-schema keyword count ≤10 000, `pattern` regexes evaluated with a non-backtracking engine (re2) OR under a per-pattern timeout, per-manifest validation budget ≤250 ms (exceeded budget → treat manifest as invalid, surface telemetry signal). Without these, a 'valid' schema with catastrophic regex backtracking or exponential `allOf`/`anyOf` expansion pins a CPU forever.\n- **Cache**: buyers cache fetched schemas by `uri@digest` and treat them as immutable (the same hosting contract as `platform_extensions`). On `404`, network partition, or persistent fetch failure, buyers SHOULD degrade gracefully (treat the declaration as unresolved, skip it for the current `get_products` response, surface via `errors[]` with the relevant code) rather than failing the entire session.\n- **Schema-not-valid handling**: if the fetched body parses as JSON but is not a valid JSON Schema, the buyer MUST treat the declaration as unresolvable (same as digest mismatch) and surface via `errors[]`. Validators MUST NOT attempt partial validation against an invalid schema.\n- **AAO catalog trust**: `https://creative.adcontextprotocol.org/*` is a single trust anchor in the same-origin allowlist; compromise of the catalog domain or its CA compromises every buyer agent. Catalog-served bodies MUST be digest-pinned identically to origin fetches (the digest is on the *parent* `format_schema.uri@digest`, not on the catalog response). Future hardening (signed bodies, transparency log) is tracked separately."
     }
   },
@@ -161,7 +161,7 @@
           "const": "image"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/image.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/image.json"
         }
       },
       "required": [
@@ -177,7 +177,7 @@
           "const": "html5"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/html5.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/html5.json"
         }
       },
       "required": [
@@ -193,7 +193,7 @@
           "const": "display_tag"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/display_tag.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/display_tag.json"
         }
       },
       "required": [
@@ -209,7 +209,7 @@
           "const": "image_carousel"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/image_carousel.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/image_carousel.json"
         }
       },
       "required": [
@@ -225,7 +225,7 @@
           "const": "video_hosted"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/video_hosted.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/video_hosted.json"
         }
       },
       "required": [
@@ -241,7 +241,7 @@
           "const": "video_vast"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/video_vast.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/video_vast.json"
         }
       },
       "required": [
@@ -257,7 +257,7 @@
           "const": "audio_hosted"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/audio_hosted.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/audio_hosted.json"
         }
       },
       "required": [
@@ -273,7 +273,7 @@
           "const": "audio_daast"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/audio_daast.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/audio_daast.json"
         }
       },
       "required": [
@@ -289,7 +289,7 @@
           "const": "sponsored_placement"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/sponsored_placement.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/sponsored_placement.json"
         }
       },
       "required": [
@@ -305,7 +305,7 @@
           "const": "native_in_feed"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/native_in_feed.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/native_in_feed.json"
         }
       },
       "required": [
@@ -321,7 +321,7 @@
           "const": "responsive_creative"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/responsive_creative.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/responsive_creative.json"
         }
       },
       "required": [
@@ -337,7 +337,7 @@
           "const": "agent_placement"
         },
         "params": {
-          "$ref": "/schemas/3.1.18/formats/canonical/agent_placement.json"
+          "$ref": "/schemas/3.1.24/formats/canonical/agent_placement.json"
         }
       },
       "required": [

package/dist/lib/schemas-data/3.1/core/product-signal-targeting-option.json

@@ -1,12 +1,12 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/product-signal-targeting-option.json",
+  "$id": "/schemas/3.1.24/core/product-signal-targeting-option.json",
   "title": "Product Signal Targeting Option",
   "description": "A signal the seller makes available inline for package-level signal composition on this product. Product.signal_targeting_options is used when the product needs product-scoped pricing, activation handles, defaults, grouping hints, a brief/refine-selected subset, or a curated inline menu. Wholesale products can instead omit inline options when the selectable menu is the broader get_signals feed. Product-local signals define their name and value_type inline through the shared signal-listing fields; data-provider and signal-source refs may omit those definition fields when the referenced definition or source is authoritative.",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.18/core/signal-listing.json"
+      "$ref": "/schemas/3.1.24/core/signal-listing.json"
     },
     {
       "description": "Signals that require activation need an operational handle the buyer can pass to activate_signal before package selection.",
@@ -74,7 +74,7 @@
       "type": "array",
       "description": "Signal pricing options available when this signal is selected on this product. Product-scoped pricing is authoritative for this product; if get_signals exposes a different default rate card, use this product-scoped price when composing the buy. Buyers pass the selected pricing_option_id in packages[].targeting_overlay.signal_targeting_groups.groups[].signals[].pricing_option_id. Omit when the signal is bundled into the product price or has no incremental cost.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/vendor-pricing-option.json"
+        "$ref": "/schemas/3.1.24/core/vendor-pricing-option.json"
       },
       "minItems": 1
     }