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

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

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/product.json",
+  "$id": "/schemas/3.1.24/core/product.json",
   "title": "Product",
   "description": "Represents available advertising inventory",
   "type": "object",
@@ -24,7 +24,7 @@
       "items": {
         "allOf": [
           {
-            "$ref": "/schemas/3.1.18/core/publisher-property-selector.json"
+            "$ref": "/schemas/3.1.24/core/publisher-property-selector.json"
           },
           {
             "not": {
@@ -41,7 +41,7 @@
       "type": "array",
       "description": "Advertising channels this product is sold as. Products inherit from their properties' supported_channels but may narrow the scope. For example, a product covering YouTube properties might be sold as ['ctv'] even though those properties support ['olv', 'social', 'ctv'].",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/channels.json"
+        "$ref": "/schemas/3.1.24/enums/channels.json"
       },
       "uniqueItems": true
     },
@@ -49,7 +49,7 @@
       "type": "array",
       "description": "Legacy named-format path: array of supported creative format IDs (structured format_id objects with agent_url and id). Products MUST carry `format_ids`, `format_options`, or BOTH; at least one is required. Named formats predate 3.1 and remain supported through the deprecation calendar (2027-Q4 floor / 2029-Q1 ceiling).\n\n**Dual emission**: A product MAY carry both `format_ids` and `format_options` simultaneously during the migration window. This is the recommended seller pattern — author once, SDK projects to both wire shapes via the [canonical mapping registry](/schemas/registries/v1-canonical-mapping.json), every buyer reads what it knows. When both are present, the two MUST refer to the SAME underlying format declaration (the `format_options[i]` narrows the canonical that the named format in `format_ids[i]` resolves to via the registry / explicit `canonical` field). SDKs that derive both shapes from one source guarantee this invariant; SDKs that don't MUST treat divergence as a build error and refuse to emit. **Buyer rule**: when both are present, prefer `format_options`; treat `format_ids` as fallback for legacy-format buyers. **Non-projectable formats**: when a named format has no clean 3.1+ format-option projection (no registry entry, no explicit `canonical` declaration on the named format, no structural match), SDKs MUST NOT emit `format_options` for that product — only `format_ids` ships, and the product remains legacy-format-only until the seller adds an explicit `canonical` field or files a registry entry.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/format-id.json"
+        "$ref": "/schemas/3.1.24/core/format-id.json"
       }
     },
     "format_options": {
@@ -57,14 +57,14 @@
       "minItems": 1,
       "description": "3.1+ format-option path: one or more inline format declarations the product accepts. Each element narrows a canonical format with parameters, slots, and platform_extensions. The 90% case is a single-element array (one canonical narrowed for the product). Multi-element use cases: a product that accepts EITHER a third-party-hosted creative (for example, externally served `html5`) OR an internal `display_tag`; a video product that accepts a hosted `video_hosted` upload OR a `video_vast` tag. Buyers pick which option they're shipping at `sync_creatives` time by aligning their manifest to the matching declaration's `format_kind` and slots.\n\nProducts MUST carry `format_ids`, `format_options`, or BOTH; at least one is required. See `format_ids` description for the dual-emission contract (same underlying declaration when both are present; SDK derives one from the other; buyers prefer `format_options` when both are present).\n\nWhen `placements[]` also declare `format_ids` or `format_options`, product-level formats are the upper bound for the sellable product. Placement-level formats narrow the product-wide accepted set for that placement; they MUST NOT introduce a format the product does not accept. Buyers compute the effective accepted set for a placement as the intersection of product-level and placement-level declarations. For format options, match publisher-declared options by `{ publisher_domain, format_option_id }`, match product-local options by `format_option_id` when `publisher_domain` is omitted, and otherwise match declarations with the same `format_kind` whose placement parameters narrow the product declaration. If a placement has no format declaration, it inherits the product-level formats.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/product-format-declaration.json"
+        "$ref": "/schemas/3.1.24/core/product-format-declaration.json"
       }
     },
     "placements": {
       "type": "array",
       "description": "Optional array of specific public placements within this product. Placement IDs are scoped by publisher domain. Product placements declare `kind` to distinguish publisher-referenced placements (`publisher_ref`) from seller-defined inline placements (`seller_inline`). Publisher-referenced placements carry `publisher_domain` plus `placement_id` and may omit `name` because buyers resolve the name from the publisher's adagents.json placement declarations. Seller-inline placements carry buyer-facing `name` directly; when `publisher_domain` is omitted, buyers MAY interpret the placement ID relative to the seller agent's own publisher domain only during the legacy single-publisher transition. Community-maintained fallback files are resolver/source metadata, not a distinct placement kind. Each placement MUST declare `mode: 'targetable'` (buyer may select the placement by PlacementRef, for example in creative assignments) or `mode: 'included'` (part of the public product composition but not buyer-selectable). Placement-level format declarations narrow the product-level creative contract and MUST NOT broaden it. Seller-private delivery objects, source/origin details, and ad-server mappings MUST NOT be exposed here.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/placement.json"
+        "$ref": "/schemas/3.1.24/core/placement.json"
       },
       "minItems": 1
     },
@@ -72,7 +72,7 @@
       "type": "array",
       "description": "Declared video placement types that may be included in this product, using IAB Tech Lab/OpenRTB 2.6 video.plcmt definitions with AdCP-native names. Use on OLV, CTV, and other video products when buyers need to distinguish instream, accompanying-content, interstitial, and standalone/no-content inventory. Aggregate products and ad-network products MAY declare multiple values. When `placements[]` also carry `video_placement_types`, this product-level array SHOULD be the union of the placement-level declarations the seller may deliver under the product. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "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
@@ -81,7 +81,7 @@
       "type": "array",
       "description": "Declared audio distribution types that may be included in this product, using IAB Tech Lab/OpenRTB 2.6 audio.feed definitions with AdCP-native names. Use on radio, streaming-audio, podcast, gaming, and other audio products when buyers need to distinguish music streaming services, FM/AM broadcast, podcasts, catch-up radio, web radio, video-game audio, and text-to-speech inventory without changing the buyer-facing channel or adagents.json property type. Aggregate products and ad-network products MAY declare multiple values. When `placements[]` also carry `audio_distribution_types`, this product-level array SHOULD be the union of the placement-level declarations the seller may deliver under the product. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "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
@@ -90,7 +90,7 @@
       "type": "array",
       "description": "Declared sponsored-placement types that may be included in this product, distinguishing where catalog-driven retail-media placements render on the retailer surface (sponsored search, sponsored display, or sponsored native). Use on retail-media products when buyers need to distinguish search-keyed, display, and native in-grid sponsored inventory. Aggregate products and ad-network products MAY declare multiple values. When `placements[]` also carry `sponsored_placement_types`, this product-level array SHOULD be the union of the placement-level declarations the seller may deliver under the product. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "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
@@ -99,32 +99,32 @@
       "type": "array",
       "description": "Declared social-placement surfaces that may be included in this product, distinguishing the in-app surface where social placements render (feed, stories, short_video, explore, or search). Use on social products when buyers need to distinguish feed, story, short-video, and discovery surfaces. Aggregate products and ad-network products MAY declare multiple values. When `placements[]` also carry `social_placement_surfaces`, this product-level array SHOULD be the union of the placement-level declarations the seller may deliver under the product. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "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
     },
     "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": "Whether this product offers exclusive access to its inventory. Defaults to 'none' when absent. Most relevant for guaranteed products tied to specific collections or placements."
     },
     "pricing_options": {
       "type": "array",
       "description": "Available pricing models for this product",
       "items": {
-        "$ref": "/schemas/3.1.18/core/pricing-option.json"
+        "$ref": "/schemas/3.1.24/core/pricing-option.json"
       },
       "minItems": 1
     },
     "forecast": {
-      "$ref": "/schemas/3.1.18/core/delivery-forecast.json",
+      "$ref": "/schemas/3.1.24/core/delivery-forecast.json",
       "description": "Forecasted delivery metrics for this product. Gives buyers an estimate of expected performance before requesting a proposal."
     },
     "outcome_measurement": {
-      "$ref": "/schemas/3.1.18/core/outcome-measurement.json",
+      "$ref": "/schemas/3.1.24/core/outcome-measurement.json",
       "description": "**Deprecated as of this minor.** Outcome capabilities (incremental sales lift, brand lift, foot traffic, etc.) are now declared via `reporting_capabilities.available_metrics` (the same path used for impressions, conversions, ROAS) with `qualifier.attribution_methodology` and `qualifier.attribution_window` carrying the methodology and window on commit. New implementations SHOULD use the unified pattern; this field is retained for one-minor backwards compatibility and removed at the next major. See `outcome-measurement.json` description for migration guidance."
     },
     "delivery_measurement": {
@@ -135,7 +135,7 @@
           "type": "array",
           "description": "Measurement vendors used for this product, as structured `BrandRef` identities. Multiple entries when multiple vendors play different roles (e.g., the ad server plus a separate viewability vendor like IAS or DV; or a retail-media seller plus a third-party retail measurement vendor like Circana or NielsenIQ). Each vendor's `brand.json` `agents[type='measurement']` is the discovery anchor; metric definitions live on the agent's `get_adcp_capabilities.measurement.metrics[]` block. Distinct from `performance_standards[].vendor` which carries vendor identity for *committed* metrics with thresholds — this field carries vendor identity for the overall measurement story, including non-committed-but-reported metrics.",
           "items": {
-            "$ref": "/schemas/3.1.18/core/brand-ref.json"
+            "$ref": "/schemas/3.1.24/core/brand-ref.json"
           },
           "minItems": 1
         },
@@ -150,35 +150,35 @@
       }
     },
     "measurement_terms": {
-      "$ref": "/schemas/3.1.18/core/measurement-terms.json",
+      "$ref": "/schemas/3.1.24/core/measurement-terms.json",
       "description": "Seller's default billing measurement and makegood terms. Declares who counts the billing metric and what remedies apply when thresholds are breached. Buyers may propose different terms at media buy creation — sellers accept, reject (TERMS_REJECTED), or adjust per their policy."
     },
     "performance_standards": {
       "type": "array",
       "description": "Seller's default performance standards for this product: viewability, IVT, completion rate, brand safety, attention score. Buyers may propose different standards at media buy creation. When absent, no structured performance standards apply.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/performance-standard.json"
+        "$ref": "/schemas/3.1.24/core/performance-standard.json"
       },
       "minItems": 1
     },
     "cancellation_policy": {
-      "$ref": "/schemas/3.1.18/core/cancellation-policy.json",
+      "$ref": "/schemas/3.1.24/core/cancellation-policy.json",
       "description": "Cancellation terms for this product. Declares the minimum notice period required before cancellation takes effect and any penalties for insufficient notice. Relevant for guaranteed delivery products. Buyers accept these terms by creating a media buy against the product."
     },
     "allowed_actions": {
       "type": "array",
       "description": "Actions buyers may perform on buys created against this product, scoped to statuses and modes. Advisory template — the authoritative per-buy capability is `available_actions[]` on the buy response, which resolves modes against current buy state, account tier, and negotiated terms. Buyers SHOULD use this for pre-flight product selection (\"which products let me self-serve cancel within 72hr?\") and read `available_actions[]` for runtime decisions. The array is uniquely keyed by `action` — sellers MUST NOT emit two entries with the same `action` value. Absence means the seller has not declared a structured action surface for this product — buyers fall back to `valid_actions[]` on buy responses for the flat string vocabulary.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/product-allowed-action.json"
+        "$ref": "/schemas/3.1.24/core/product-allowed-action.json"
       },
       "minItems": 1,
       "uniqueItems": true
     },
     "reporting_capabilities": {
-      "$ref": "/schemas/3.1.18/core/reporting-capabilities.json"
+      "$ref": "/schemas/3.1.24/core/reporting-capabilities.json"
     },
     "creative_policy": {
-      "$ref": "/schemas/3.1.18/core/creative-policy.json"
+      "$ref": "/schemas/3.1.24/core/creative-policy.json"
     },
     "is_custom": {
       "type": "boolean",
@@ -194,14 +194,14 @@
       "description": "Deprecated. Legacy/non-selectable metadata for data-provider signals already bundled into or associated with this product. This field does not provide buyer-selectable options, prices, or seller activation handles. Use included_signals for non-selectable product signal metadata, or signal_targeting_options for selectable package-level signal groups.",
       "deprecated": true,
       "items": {
-        "$ref": "/schemas/3.1.18/core/data-provider-signal-selector.json"
+        "$ref": "/schemas/3.1.24/core/data-provider-signal-selector.json"
       }
     },
     "included_signals": {
       "type": "array",
       "description": "Non-selectable signal metadata for signals already included in, bundled with, or planned into this product. These signals describe what the product is; buyers do not select them in packages[].targeting_overlay.signal_targeting_groups and this field does not imply package-level signal targeting. Use signal_ref scope 'data_provider' or 'signal_source' to reference externally defined signals without redefining their name or value_type. Use signal_ref scope 'product' with name and value_type when the included signal is defined only by this product.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/signal-listing.json"
+        "$ref": "/schemas/3.1.24/core/signal-listing.json"
       },
       "minItems": 1
     },
@@ -209,12 +209,12 @@
       "type": "array",
       "description": "Inline seller-offered signals that may be applied to packages for this product at create_media_buy time. Each entry references a named signal definition with signal_ref scope 'product' for a product-local signal option, scope 'data_provider' for an external signal definition published in adagents.json signals[] that the seller is authorized to apply, or scope 'signal_source' for a source-native signal. Product-local options define name and value_type inline; data-provider and signal-source options may omit those fields when the referenced definition or source is authoritative. Use this field when the selectable menu is product-specific, has product-specific pricing or activation handles, is the relevant subset for a brief/refine result, or should be rendered without an additional get_signals call. Wholesale products may omit this field and rely on get_signals for the selectable signal feed. Buyers select eligible signals through packages[].targeting_overlay.signal_targeting_groups when signal_targeting_rules allow; fixed/default entries are applied by the seller and echoed on the package state. Sellers MUST set signal_targeting_allowed to true whenever this field is present. Bundled, non-selectable signal metadata belongs in included_signals; legacy data_provider_signals may appear only for backwards compatibility.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/product-signal-targeting-option.json"
+        "$ref": "/schemas/3.1.24/core/product-signal-targeting-option.json"
       },
       "minItems": 1
     },
     "signal_targeting_rules": {
-      "$ref": "/schemas/3.1.18/core/signal-targeting-rules.json",
+      "$ref": "/schemas/3.1.24/core/signal-targeting-rules.json",
       "description": "Composition rules for selecting signals on this product. The selectable signal menu may come from inline signal_targeting_options or from get_signals when a wholesale product omits inline options. This is product-scoped because products may be backed by different ad servers with different Boolean targeting support and group limits."
     },
     "signal_targeting_allowed": {
@@ -226,7 +226,7 @@
       "type": "array",
       "description": "Catalog types this product supports for catalog-driven campaigns. A sponsored product listing declares [\"product\"], a job board declares [\"job\", \"offering\"]. Buyers match synced catalogs to products via this field.",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/catalog-type.json"
+        "$ref": "/schemas/3.1.24/enums/catalog-type.json"
       },
       "uniqueItems": true,
       "minItems": 1
@@ -260,7 +260,7 @@
           "type": "array",
           "description": "Reach units this product can optimize for. Required when supported_metrics includes 'reach'. Buyers must set reach_unit to a value in this list on reach optimization goals — sellers reject unsupported values.",
           "items": {
-            "$ref": "/schemas/3.1.18/enums/reach-unit.json"
+            "$ref": "/schemas/3.1.24/enums/reach-unit.json"
           },
           "minItems": 1
         },
@@ -290,7 +290,7 @@
       "additionalProperties": true
     },
     "vendor_metric_optimization": {
-      "$ref": "/schemas/3.1.18/core/vendor-metric-optimization.json",
+      "$ref": "/schemas/3.1.24/core/vendor-metric-optimization.json",
       "description": "Vendor-attested metric optimization capabilities for this product. Presence indicates the product supports `optimization_goals` with `kind: 'vendor_metric'` — the seller's bidding stack can steer delivery toward a specific vendor's measurement (e.g., DV/IAS/Adelaide attention, Scope3 emissions, Kantar brand lift, retail-media partner metrics). Distinct from `metric_optimization` (seller-native metrics with no vendor binding) and from `reporting_capabilities.vendor_metrics` (which declares what the product can *report* rather than what it can *optimize against*). A product may report a vendor metric without being able to optimize for it. Buyers MUST verify the goal's `(vendor, metric_id)` is in `supported_metrics` AND that the package's `committed_metrics[]` includes a matching `{ scope: 'vendor', vendor, metric_id }` entry — optimization without committed reporting is unverifiable and is rejected at the wire level."
     },
     "max_optimization_goals": {
@@ -299,7 +299,7 @@
       "description": "Maximum number of optimization_goals this product accepts on a package. When absent, no limit is declared. Most social platforms accept only 1 goal — buyers sending arrays longer than this value should expect the seller to use only the highest-priority (lowest priority number) goal."
     },
     "measurement_readiness": {
-      "$ref": "/schemas/3.1.18/core/measurement-readiness.json",
+      "$ref": "/schemas/3.1.24/core/measurement-readiness.json",
       "description": "Assessment of whether the buyer's event source setup is sufficient for this product to optimize effectively. Only present when the seller can evaluate the buyer's account context. Buyers should check this before creating media buys with event-based optimization goals."
     },
     "conversion_tracking": {
@@ -310,7 +310,7 @@
           "type": "array",
           "description": "Action sources relevant to this product (e.g. a retail media product might have 'in_store' and 'website', while a display product might only have 'website')",
           "items": {
-            "$ref": "/schemas/3.1.18/enums/action-source.json"
+            "$ref": "/schemas/3.1.24/enums/action-source.json"
           },
           "minItems": 1
         },
@@ -382,7 +382,7 @@
       "description": "Optional standard visual card for displaying this product in user interfaces (catalog browsers, dashboards, agent UIs). Distinct from `format` — product_card describes the UI rendering of the product itself, not the ad creative the product accepts. Typed inline; no format_id indirection. Receivers render the card directly from these fields.",
       "properties": {
         "image": {
-          "$ref": "/schemas/3.1.18/core/assets/image-asset.json",
+          "$ref": "/schemas/3.1.24/core/assets/image-asset.json",
           "description": "Hero image for the card. Recommended ~300x400 (4:3 portrait) for the standard card layout; receivers may scale."
         },
         "title": {
@@ -413,14 +413,14 @@
       "description": "Optional detailed card with hero + carousel + structured specifications, for rich product presentation (media-kit-style pages, full product detail views). Distinct from `format` — describes the UI rendering of the product itself, not the ad creative the product accepts. Typed inline; no format_id indirection.",
       "properties": {
         "hero_image": {
-          "$ref": "/schemas/3.1.18/core/assets/image-asset.json",
+          "$ref": "/schemas/3.1.24/core/assets/image-asset.json",
           "description": "Primary hero image at the top of the detailed view."
         },
         "carousel_images": {
           "type": "array",
           "description": "Additional images for a swipeable carousel below the hero.",
           "items": {
-            "$ref": "/schemas/3.1.18/core/assets/image-asset.json"
+            "$ref": "/schemas/3.1.24/core/assets/image-asset.json"
           }
         },
         "title": {
@@ -468,7 +468,7 @@
       "type": "array",
       "description": "Collections available in this product. Each entry references collections declared in an adagents.json by domain and collection ID. Buyers resolve full collection objects from the referenced adagents.json.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/collection-selector.json"
+        "$ref": "/schemas/3.1.24/core/collection-selector.json"
       },
       "minItems": 1
     },
@@ -481,7 +481,7 @@
       "type": "array",
       "description": "Specific installments included in this product. Each installment references its parent collection via collection_id when the product spans multiple collections. When absent with collections present, the product covers the collections broadly (run-of-collection).",
       "items": {
-        "$ref": "/schemas/3.1.18/core/installment.json"
+        "$ref": "/schemas/3.1.24/core/installment.json"
       }
     },
     "enforced_policies": {
@@ -509,7 +509,7 @@
           "type": "array",
           "description": "What the publisher can accept back from context match.",
           "items": {
-            "$ref": "/schemas/3.1.18/enums/response-type.json"
+            "$ref": "/schemas/3.1.24/enums/response-type.json"
           },
           "minItems": 1,
           "default": [
@@ -555,7 +555,7 @@
                 "type": "array",
                 "description": "Identity types this regional provider can resolve. The router filters providers whose uid_types includes the request's uid_type. Required when identity_match is true.",
                 "items": {
-                  "$ref": "/schemas/3.1.18/enums/uid-type.json"
+                  "$ref": "/schemas/3.1.24/enums/uid-type.json"
                 },
                 "minItems": 1
               }
@@ -611,14 +611,14 @@
           "maxLength": 2000
         },
         "ext": {
-          "$ref": "/schemas/3.1.18/core/ext.json"
+          "$ref": "/schemas/3.1.24/core/ext.json"
         }
       },
       "minProperties": 1,
       "additionalProperties": true
     },
     "ext": {
-      "$ref": "/schemas/3.1.18/core/ext.json"
+      "$ref": "/schemas/3.1.24/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/core/property-id.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/property-id.json",
+  "$id": "/schemas/3.1.24/core/property-id.json",
   "title": "Property ID",
   "description": "Identifier for a publisher property. Must be lowercase alphanumeric with underscores only.",
   "type": "string",

package/dist/lib/schemas-data/3.1/core/property-list-ref.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/property-list-ref.json",
+  "$id": "/schemas/3.1.24/core/property-list-ref.json",
   "title": "Property List Reference",
   "description": "Reference to an externally managed property list. Enables passing large property sets (50,000+) without embedding them in requests. The receiving agent fetches and caches the list independently.",
   "type": "object",

package/dist/lib/schemas-data/3.1/core/property-tag.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/property-tag.json",
+  "$id": "/schemas/3.1.24/core/property-tag.json",
   "title": "Property Tag",
   "description": "Tag for categorizing publisher properties. Must be lowercase alphanumeric with underscores only.",
   "type": "string",

package/dist/lib/schemas-data/3.1/core/property.json

@@ -1,16 +1,16 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/property.json",
+  "$id": "/schemas/3.1.24/core/property.json",
   "title": "Property",
   "description": "An advertising property that can be validated via adagents.json",
   "type": "object",
   "properties": {
     "property_id": {
-      "$ref": "/schemas/3.1.18/core/property-id.json",
+      "$ref": "/schemas/3.1.24/core/property-id.json",
       "description": "Unique identifier for this property (optional). Enables referencing properties by ID instead of repeating full objects."
     },
     "property_type": {
-      "$ref": "/schemas/3.1.18/enums/property-type.json",
+      "$ref": "/schemas/3.1.24/enums/property-type.json",
       "description": "Type of advertising property"
     },
     "name": {
@@ -24,7 +24,7 @@
         "type": "object",
         "properties": {
           "type": {
-            "$ref": "/schemas/3.1.18/enums/identifier-types.json",
+            "$ref": "/schemas/3.1.24/enums/identifier-types.json",
             "description": "Type of identifier for this property"
           },
           "value": {
@@ -44,7 +44,7 @@
       "type": "array",
       "description": "Tags for categorization and grouping (e.g., network membership, content categories)",
       "items": {
-        "$ref": "/schemas/3.1.18/core/property-tag.json"
+        "$ref": "/schemas/3.1.24/core/property-tag.json"
       },
       "uniqueItems": true
     },
@@ -52,7 +52,7 @@
       "type": "array",
       "description": "Advertising channels this property supports (e.g., ['display', 'olv', 'social']). Publishers declare which channels their inventory aligns with. Properties may support multiple channels. See the Media Channel Taxonomy for definitions.",
       "items": {
-        "$ref": "/schemas/3.1.18/enums/channels.json"
+        "$ref": "/schemas/3.1.24/enums/channels.json"
       },
       "uniqueItems": true
     },

package/dist/lib/schemas-data/3.1/core/proposal.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/proposal.json",
+  "$id": "/schemas/3.1.24/core/proposal.json",
   "title": "Proposal",
   "description": "A proposed media plan with budget allocations across products. Represents the publisher's strategic recommendation for how to structure a campaign based on the brief. Proposals are actionable: committed proposals can be executed directly via create_media_buy by providing the proposal_id; draft proposals must first be finalized via get_products refine action 'finalize'.",
   "type": "object",
@@ -24,12 +24,12 @@
       "type": "array",
       "description": "Budget allocations across products. Allocation percentages MUST sum to 100. Publishers are responsible for ensuring the sum equals 100; buyers SHOULD validate this before execution.",
       "items": {
-        "$ref": "/schemas/3.1.18/core/product-allocation.json"
+        "$ref": "/schemas/3.1.24/core/product-allocation.json"
       },
       "minItems": 1
     },
     "proposal_status": {
-      "$ref": "/schemas/3.1.18/enums/proposal-status.json",
+      "$ref": "/schemas/3.1.24/enums/proposal-status.json",
       "description": "Lifecycle status of this proposal and the per-proposal source of truth for whether finalization is required before create_media_buy. When absent, the proposal is ready to buy (backward compatible). 'draft' means indicative pricing — finalize via refine before purchasing. 'committed' means firm pricing with inventory reserved until expires_at and executable via create_media_buy."
     },
     "expires_at": {
@@ -38,7 +38,7 @@
       "description": "When this proposal expires and can no longer be executed. For draft proposals, indicates when indicative pricing becomes stale. For committed proposals, indicates when the inventory hold lapses — the buyer must call create_media_buy before this time."
     },
     "insertion_order": {
-      "$ref": "/schemas/3.1.18/core/insertion-order.json",
+      "$ref": "/schemas/3.1.24/core/insertion-order.json",
       "description": "Formal insertion order attached to a committed proposal. Present when the seller requires a signed agreement before the media buy can proceed. The buyer references the io_id in io_acceptance on create_media_buy."
     },
     "total_budget_guidance": {
@@ -73,11 +73,11 @@
       "maxLength": 2000
     },
     "forecast": {
-      "$ref": "/schemas/3.1.18/core/delivery-forecast.json",
+      "$ref": "/schemas/3.1.24/core/delivery-forecast.json",
       "description": "Aggregate forecasted delivery metrics for the entire proposal. When both proposal-level and allocation-level forecasts are present, the proposal-level forecast is authoritative for total delivery estimation."
     },
     "ext": {
-      "$ref": "/schemas/3.1.18/core/ext.json"
+      "$ref": "/schemas/3.1.24/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/core/protocol-envelope.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/protocol-envelope.json",
+  "$id": "/schemas/3.1.24/core/protocol-envelope.json",
   "title": "Protocol Envelope",
   "description": "Canonical envelope field-set for AdCP task responses, normalized across transports. Defines the protocol-layer fields (status, context_id, context, task_id, timestamp, replayed, adcp_error, push_notification_config, governance_context) and the conceptual `payload` grouping for task-specific response data. The serialization rules — whether envelope fields appear as siblings of payload fields, as a nested `payload` object, or via transport-native containers — are transport-specific and normative per transport (see Transport serialization below). The `status` field is REQUIRED on every task response envelope, including synchronous metadata responses (e.g., `get_adcp_capabilities`) where the value is `completed`. Agents shipping responses without a top-level `status` are non-conformant regardless of whether the task body schema would otherwise validate.",
   "type": "object",
@@ -10,7 +10,7 @@
       "description": "Session/conversation identifier for tracking related operations across multiple task invocations. Managed by the protocol layer to maintain conversational context. Distinct from `context` (per-request opaque echo, see below)."
     },
     "context": {
-      "$ref": "/schemas/3.1.18/core/context.json",
+      "$ref": "/schemas/3.1.24/core/context.json",
       "description": "Per-request opaque caller-supplied correlation object echoed unchanged in the response. Used for buyer-side tracking (UI session IDs, trace IDs, custom metadata) that the agent MUST preserve byte-for-byte without parsing. Distinct from `context_id` (server-managed session identifier) — `context` is caller-owned echo, `context_id` is server-owned session scope. Both MAY appear on the same response.\n\n**Relationship to per-task body-level `context` declarations.** Many task request/response schemas (147 as of 3.1) already declare a body-level `context` field that `$ref`s `/schemas/core/context.json` at the body root. Under the flat-on-the-wire MCP serialization (see `notes` below), envelope-level `context` and body-level `context` occupy the same key on the response root — they are NOT separate fields, they MUST share the same value, and they MUST both `$ref` `core/context.json`. The envelope declaration is **authoritative** for the schema definition; per-task body declarations are mirrors retained for tooling reasons (SDK codegen completeness, per-task validation against the response schema in isolation). Future versions MAY drop body-level `context` declarations from per-task schemas; conformance does not require either declaration to be present, only that the wire value `$ref`s `core/context.json`."
     },
     "task_id": {
@@ -19,7 +19,7 @@
       "x-entity": "task"
     },
     "status": {
-      "$ref": "/schemas/3.1.18/enums/task-status.json",
+      "$ref": "/schemas/3.1.24/enums/task-status.json",
       "description": "Current task execution state. Indicates whether the task is completed, in progress (working), submitted for async processing, failed, or requires user input. REQUIRED on every task response envelope. Synchronous tasks (including read-only metadata calls like `get_adcp_capabilities`) MUST emit `status: \"completed\"`; async tasks emit `submitted`, `working`, `input-required`, etc. per their lifecycle. Agents MUST NOT emit the legacy task_status or response_status fields alongside this field — the status field is the single authoritative task state."
     },
     "message": {
@@ -33,15 +33,15 @@
     },
     "replayed": {
       "type": "boolean",
-      "description": "Set to true when this response was returned from the idempotency cache rather than from a fresh execution. Set to false (or omitted) when the request was executed fresh. Buyers use this to distinguish cached replays from new executions — matters for billing reconciliation, audit logs, state-machine routing (cached state-tracking fields are historical snapshots, not current state — re-read via the resource's read endpoint), and any downstream system that assumes exactly-once event semantics. From 3.1 onward, `replayed` MAY appear on responses to any request that resolved via the idempotency cache, including read tools — universal `idempotency_key` (see security.mdx §Idempotency) means the cache holds read responses too.",
+      "description": "Set to true when this response was returned from the idempotency cache rather than from a fresh execution. Set to false (or omitted) when the request was executed fresh. Buyers use this to distinguish cached replays from new executions — matters for billing reconciliation, audit logs, state-machine routing (cached state-tracking fields are historical snapshots, not current state — re-read via the resource's read endpoint), and any downstream system that assumes exactly-once event semantics. `replayed` appears only when the request actually resolved through the idempotency cache. Pure reads may ignore an optional `idempotency_key`; when a seller voluntarily caches keyed reads, those responses use the same replay indicator and full cache contract.",
       "default": false
     },
     "adcp_error": {
-      "$ref": "/schemas/3.1.18/core/error.json",
+      "$ref": "/schemas/3.1.24/core/error.json",
       "description": "Transport-envelope error signal for fatal task failures. Per the two-layer model in `error-handling.mdx#envelope-vs-payload-errors-the-two-layer-model`, a fatal task failure SHOULD populate both this envelope-level field AND the payload's `errors[]` array — the envelope carries a typed, extractable error so MCP/A2A clients can dispatch without re-parsing the payload, while the payload's structured `errors[]` remains the canonical normative shape. Non-fatal warnings populate ONLY `payload.errors[]` with `severity: warning` — the envelope MUST NOT carry `adcp_error` for non-failures."
     },
     "push_notification_config": {
-      "$ref": "/schemas/3.1.18/core/push-notification-config.json",
+      "$ref": "/schemas/3.1.24/core/push-notification-config.json",
       "description": "Push notification configuration for async task updates (A2A and REST protocols). Echoed from the request to confirm webhook settings. Specifies URL, authentication scheme (Bearer or HMAC-SHA256), and credentials. MCP uses progress notifications instead of webhooks."
     },
     "governance_context": {

package/dist/lib/schemas-data/3.1/core/provenance.json

@@ -1,12 +1,12 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/provenance.json",
+  "$id": "/schemas/3.1.24/core/provenance.json",
   "title": "Provenance",
   "description": "Declares how content was produced, whether AI was involved, and what disclosure obligations apply. Attaches to creative manifests, individual assets, or content-standards artifacts. When present at multiple levels, the most specific provenance object replaces the inherited one entirely (no field-level merging). Provenance is a claim by the declaring party — receiving parties should verify claims independently via their own detection tools.",
   "type": "object",
   "properties": {
     "digital_source_type": {
-      "$ref": "/schemas/3.1.18/enums/digital-source-type.json",
+      "$ref": "/schemas/3.1.24/enums/digital-source-type.json",
       "description": "IPTC-aligned classification of AI involvement in producing this content"
     },
     "ai_tool": {
@@ -115,7 +115,7 @@
         "type": "object",
         "properties": {
           "method": {
-            "$ref": "/schemas/3.1.18/enums/embedded-provenance-method.json",
+            "$ref": "/schemas/3.1.24/enums/embedded-provenance-method.json",
             "description": "How provenance data is carried within the content"
           },
           "standard": {
@@ -167,7 +167,7 @@
         "type": "object",
         "properties": {
           "media_type": {
-            "$ref": "/schemas/3.1.18/enums/watermark-media-type.json",
+            "$ref": "/schemas/3.1.24/enums/watermark-media-type.json",
             "description": "Media category of the watermarked content"
           },
           "provider": {
@@ -195,7 +195,7 @@
             "additionalProperties": false
           },
           "c2pa_action": {
-            "$ref": "/schemas/3.1.18/enums/c2pa-watermark-action.json",
+            "$ref": "/schemas/3.1.24/enums/c2pa-watermark-action.json",
             "description": "C2PA action classification for this watermark"
           },
           "embedded_at": {
@@ -247,7 +247,7 @@
                 "minProperties": 1,
                 "properties": {
                   "persistence": {
-                    "$ref": "/schemas/3.1.18/enums/disclosure-persistence.json",
+                    "$ref": "/schemas/3.1.24/enums/disclosure-persistence.json",
                     "description": "How long the disclosure must persist during content playback or display"
                   },
                   "min_duration_ms": {
@@ -259,13 +259,13 @@
                     "type": "array",
                     "description": "Preferred disclosure positions in priority order. The first position a format supports should be used.",
                     "items": {
-                      "$ref": "/schemas/3.1.18/enums/disclosure-position.json"
+                      "$ref": "/schemas/3.1.24/enums/disclosure-position.json"
                     },
                     "minItems": 1,
                     "uniqueItems": true
                   },
                   "ext": {
-                    "$ref": "/schemas/3.1.18/core/ext.json"
+                    "$ref": "/schemas/3.1.24/core/ext.json"
                   }
                 },
                 "additionalProperties": true
@@ -331,7 +331,7 @@
       }
     },
     "ext": {
-      "$ref": "/schemas/3.1.18/core/ext.json"
+      "$ref": "/schemas/3.1.24/core/ext.json"
     }
   },
   "additionalProperties": true

package/dist/lib/schemas-data/3.1/core/publisher-property-selector.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.18/core/publisher-property-selector.json",
+  "$id": "/schemas/3.1.24/core/publisher-property-selector.json",
   "title": "Publisher Property Selector",
   "description": "Selects properties from a publisher's adagents.json. Used for both product definitions and agent authorization. Supports three selection patterns: all properties, specific IDs, or by tags. Each selector targets one publisher via `publisher_domain` (string) or a fan-out across many publishers that share the same selector via `publisher_domains` (array). Exactly one of `publisher_domain` or `publisher_domains` MUST be present. When `publisher_domains` is used, the selector is logically equivalent to repeating the same entry once per listed domain.",
   "discriminator": {
@@ -79,7 +79,7 @@
           "type": "array",
           "description": "Specific property IDs from the publisher's adagents.json",
           "items": {
-            "$ref": "/schemas/3.1.18/core/property-id.json"
+            "$ref": "/schemas/3.1.24/core/property-id.json"
           },
           "minItems": 1
         }
@@ -119,7 +119,7 @@
           "type": "array",
           "description": "Property tags resolved against each addressed publisher's adagents.json, OR against the parent file's top-level `properties[]` when those properties carry a `publisher_domain` matching the selector. Selector covers all properties carrying any of these tags.",
           "items": {
-            "$ref": "/schemas/3.1.18/core/property-tag.json"
+            "$ref": "/schemas/3.1.24/core/property-tag.json"
           },
           "minItems": 1
         }