@adcp/sdk 13.0.1 → 13.0.3

package/dist/lib/schemas-data/3.1/core/optimization-goal.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/optimization-goal.json",
+  "$id": "/schemas/3.1.20/core/optimization-goal.json",
   "title": "Optimization Goal",
   "description": "A single optimization target for a package. Packages accept an array of optimization_goals. When multiple goals are present, priority determines which the seller focuses on — 1 is highest priority (primary goal); higher numbers are secondary. When priorities are present but no goal is priority 1, the goal with the lowest priority value is primary (e.g., priorities of 2 and 3 mean 2 is primary). Duplicate priority values result in undefined seller behavior.",
   "discriminator": {
@@ -35,7 +35,7 @@
         "reach_unit": {
           "allOf": [
             {
-              "$ref": "/schemas/3.1.15/enums/reach-unit.json"
+              "$ref": "/schemas/3.1.20/enums/reach-unit.json"
             }
           ],
           "description": "Unit for reach measurement. Required when metric is 'reach'. Must be a value declared in the product's metric_optimization.supported_reach_units."
@@ -57,7 +57,7 @@
             "window": {
               "allOf": [
                 {
-                  "$ref": "/schemas/3.1.15/core/duration.json"
+                  "$ref": "/schemas/3.1.20/core/duration.json"
                 }
               ],
               "description": "Time window over which frequency is measured (e.g. {\"interval\": 7, \"unit\": \"days\"} or {\"interval\": 1, \"unit\": \"campaign\"} for the full flight). Weekly windows are typical for brand campaigns; daily windows suit high-cadence direct response."
@@ -165,7 +165,7 @@
                 "description": "Event source to include (must be configured on this account via sync_event_sources)"
               },
               "event_type": {
-                "$ref": "/schemas/3.1.15/enums/event-type.json",
+                "$ref": "/schemas/3.1.20/enums/event-type.json",
                 "description": "Event type to include from this source (e.g., purchase, lead, app_install, refund)"
               },
               "custom_event_name": {
@@ -255,7 +255,7 @@
         "attribution_window": {
           "allOf": [
             {
-              "$ref": "/schemas/3.1.15/core/attribution-window.json"
+              "$ref": "/schemas/3.1.20/core/attribution-window.json"
             }
           ],
           "description": "Attribution window for this optimization goal — references the canonical `attribution-window` shape (post_click, post_view, model). Values must match an option declared in the seller's `conversion_tracking.attribution_windows` capability. Sellers MUST reject windows not in their declared capabilities. When the entire field is omitted, the seller uses their default window."
@@ -281,11 +281,11 @@
           "const": "vendor_metric"
         },
         "vendor": {
-          "$ref": "/schemas/3.1.15/core/brand-ref.json",
+          "$ref": "/schemas/3.1.20/core/brand-ref.json",
           "description": "Vendor that defines and computes this metric. Same shape as `vendor_metric_values.vendor`, `reporting_capabilities.vendor_metrics[].vendor`, and `vendor_metric_optimization.supported_metrics[].vendor` — symmetric across discovery, capability, commitment, optimization, and reporting surfaces."
         },
         "metric_id": {
-          "$ref": "/schemas/3.1.15/core/vendor-metric-id.json",
+          "$ref": "/schemas/3.1.20/core/vendor-metric-id.json",
           "description": "Identifier for the metric within the vendor's vocabulary (e.g., `attention_score`, `attention_seconds`, `gco2e_per_impression`, `awareness_lift`). MUST be present in the vendor's published `measurement.metrics[]` catalog and in the product's `vendor_metric_optimization.supported_metrics[]`."
         },
         "target": {

package/dist/lib/schemas-data/3.1/core/outcome-measurement.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/outcome-measurement.json",
+  "$id": "/schemas/3.1.20/core/outcome-measurement.json",
   "title": "Outcome Measurement (Deprecated)",
   "description": "**Deprecated as of this minor.** Predates the unified measurement-vocabulary pattern. Outcome metrics (incremental_sales_lift, brand_lift, foot_traffic, conversion_lift, brand_search_lift, attributed sales) are now expressible through the same primitives as the rest of the measurement surface:\n\n- **Outcome metric capability** → declared via `reporting_capabilities.available_metrics` on the product. Closed enum entries: `incremental_sales_lift`, `brand_lift`, `foot_traffic`, `conversion_lift`, `brand_search_lift`. Existing entries `conversions`, `conversion_value`, `roas`, `cost_per_acquisition`, `units_sold`, `new_to_brand_rate`, `new_to_brand_units`, `leads` already covered most outcome-metric needs.\n- **Attributed sales** (the retail-media value prop) → `conversion_value` with `qualifier.attribution_methodology: 'deterministic_purchase'`. **Walmart Connect's `attributedSalesIn14Days`** maps to `conversion_value` + `qualifier.attribution_methodology: 'deterministic_purchase'` + `qualifier.attribution_window: {interval: 14, unit: 'days'}`. Same pattern for Amazon DSP attributed sales, Kroger Precision attributed sales, Criteo Retail Media attributed sales — the protocol does not invent a separate `attributed_sales` metric ID because the qualifier handles the methodology split.\n- **Brand lift** → `brand_lift` metric_id PLUS `qualifier.lift_dimension` (closed enum: awareness, consideration, favorability, purchase_intent, ad_recall). Brand-lift vendors (Kantar, Upwave, Cint, DV) report each dimension separately; the qualifier ensures rows aren't combined.\n- **Attribution methodology** → `qualifier.attribution_methodology` (`deterministic_purchase`, `probabilistic`, `panel_based`, `modeled`).\n- **Attribution window** → `qualifier.attribution_window` (structured duration `{interval, unit}`, never a shorthand string).\n- **Vendor identity** (typically the seller for retail-media closed loop) → vendor-scope `committed_metrics` entries with the BrandRef anchored on the seller's measurement-agent capability (or absent when the seller is the implicit vendor). For third-party retail measurement (Circana, NielsenIQ, IRI for retail MMM; Kantar/Upwave for brand lift on retail-media inventory), use `performance_standards.vendor` to pin the third-party identity.\n- **Reporting frequency / format** → planned for a follow-up `reporting_capabilities` extension; existing `outcome_measurement.reporting` field continues to work for one minor.\n\nThis schema is retained for one-minor backwards compatibility on `product.outcome_measurement`. Removed at the next major. New implementations SHOULD declare outcome capabilities via `reporting_capabilities.available_metrics` and consumers reconcile via `committed_metrics`/`metric_aggregates` with the appropriate qualifier.",
   "type": "object",
@@ -25,7 +25,7 @@
     "window": {
       "allOf": [
         {
-          "$ref": "/schemas/3.1.15/core/duration.json"
+          "$ref": "/schemas/3.1.20/core/duration.json"
         }
       ],
       "description": "Attribution window as a structured duration (e.g., {\"interval\": 30, \"unit\": \"days\"})."

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

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/overlay.json",
+  "$id": "/schemas/3.1.20/core/overlay.json",
   "title": "Overlay",
   "description": "A publisher-controlled element that renders on top of buyer creative content within the ad placement. Creative agents should avoid placing critical content (CTAs, logos, key copy) within overlay bounds.",
   "type": "object",

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

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/package-signal-targeting-group.json",
+  "$id": "/schemas/3.1.20/core/package-signal-targeting-group.json",
   "title": "Package Signal Targeting Group",
   "description": "A basic Boolean group of package-level signal targeting entries. 'any' means the user must match at least one signal in the group. 'none' means the user must match none of the signals in the group. Use groups for portable include/exclude composition such as (A OR B) AND NOT (C OR D).",
   "type": "object",
@@ -17,7 +17,7 @@
       "type": "array",
       "description": "Signal targeting entries evaluated by this group. Each entry uses the package signal targeting shape, including signal_ref, value expression, and optional pricing, execution-handle, or activation fields.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/package-signal-targeting.json"
+        "$ref": "/schemas/3.1.20/core/package-signal-targeting.json"
       },
       "minItems": 1
     }

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

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/package-signal-targeting-groups.json",
+  "$id": "/schemas/3.1.20/core/package-signal-targeting-groups.json",
   "title": "Package Signal Targeting Groups",
   "description": "Top-level basic Boolean composition for package signal targeting. The groups-level operator is required; v1 supports operator 'all', meaning every child group must be satisfied. This represents the portable baseline: (any of include group 1) AND (any of include group 2) AND NOT (any of exclude group N).",
   "type": "object",
@@ -16,7 +16,7 @@
       "type": "array",
       "description": "Signal targeting groups to evaluate. Use operator 'any' for include groups and 'none' for exclusion groups.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/package-signal-targeting-group.json"
+        "$ref": "/schemas/3.1.20/core/package-signal-targeting-group.json"
       },
       "minItems": 1
     }

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

@@ -1,12 +1,12 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/package-signal-targeting.json",
+  "$id": "/schemas/3.1.20/core/package-signal-targeting.json",
   "title": "Package Signal Targeting",
   "description": "Buy-time selection of one seller-offered signal inside a package signal targeting group. The signal_ref uses scope 'product' for a product-local signal option, scope 'data_provider' for a signal defined in a data provider's published adagents.json signals[], or scope 'signal_source' for a source-native signal that is not published in adagents.json signals[]. The selected product's inline Product.signal_targeting_options, get_signals feed when inline options are omitted, and signal_targeting_rules define buy-time eligibility. Inclusion and exclusion are controlled by the parent group operator: use operator 'any' to include users matching the signal expression and operator 'none' to exclude users matching the signal expression. For binary signals, value MUST be true; do not use value=false for exclusion inside signal_targeting_groups. Use audience_include/audience_exclude only for buyer-managed first-party audiences registered through sync_audiences.",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.15/core/signal-targeting-expression.json"
+      "$ref": "/schemas/3.1.20/core/signal-targeting-expression.json"
     }
   ],
   "properties": {
@@ -21,7 +21,7 @@
       "x-entity": "signal_activation_id"
     },
     "activation_key": {
-      "$ref": "/schemas/3.1.15/core/activation-key.json",
+      "$ref": "/schemas/3.1.20/core/activation-key.json",
       "description": "Destination-specific activation key returned by get_signals or activate_signal. Usually omitted for seller-offered signals selected directly through the same seller; include only when the selected signal was separately activated and the seller requires the activation key to correlate the package selection."
     }
   },

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

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/package.json",
+  "$id": "/schemas/3.1.20/core/package.json",
   "title": "Package",
   "description": "A specific product within a media buy (line item)",
   "type": "object",
@@ -21,7 +21,7 @@
       "minimum": 0
     },
     "pacing": {
-      "$ref": "/schemas/3.1.15/enums/pacing.json"
+      "$ref": "/schemas/3.1.20/enums/pacing.json"
     },
     "pricing_option_id": {
       "type": "string",
@@ -35,7 +35,7 @@
     },
     "price_breakdown": {
       "description": "Breakdown of the effective price for this package. On fixed-price packages, echoes the pricing option's breakdown. On auction packages, shows the clearing price breakdown including any commission or settlement terms.",
-      "$ref": "/schemas/3.1.15/pricing-options/price-breakdown.json"
+      "$ref": "/schemas/3.1.20/pricing-options/price-breakdown.json"
     },
     "impressions": {
       "type": "number",
@@ -46,26 +46,26 @@
       "type": "array",
       "description": "Catalogs this package promotes. Each catalog MUST have a distinct type (e.g., one product catalog, one store catalog). This constraint is enforced at the application level — sellers MUST reject requests containing multiple catalogs of the same type with a validation_error. Echoed from the create_media_buy request.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/catalog.json"
+        "$ref": "/schemas/3.1.20/core/catalog.json"
       }
     },
     "format_ids": {
       "type": "array",
       "description": "Legacy named-format IDs supplied for this package on create_media_buy. Sellers SHOULD echo this field whenever the request included it, including dual-emission cases where `format_option_refs` was the winning selector, so read surfaces preserve the original wire contract. Omitted means the request did not carry legacy format_ids unless the seller cannot reconstruct legacy requests created before this field was persisted.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/format-id.json"
+        "$ref": "/schemas/3.1.20/core/format-id.json"
       }
     },
     "format_option_refs": {
       "type": "array",
       "description": "Structured 3.1+ format option references supplied for this package on create_media_buy. Sellers SHOULD echo this field whenever the request included it. Publisher-catalog-backed options are identified by `{ scope: \"publisher\", publisher_domain, format_option_id }`; product-local options are identified by `{ scope: \"product\", format_option_id }` and resolve only against this package's target product. Omitted means the request did not carry format_option_refs unless the seller cannot reconstruct legacy requests created before this field was persisted.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/format-option-ref.json"
+        "$ref": "/schemas/3.1.20/core/format-option-ref.json"
       },
       "minItems": 1
     },
     "format_kind": {
-      "$ref": "/schemas/3.1.15/core/canonical-format-kind.json",
+      "$ref": "/schemas/3.1.20/core/canonical-format-kind.json",
       "description": "Direct canonical selector supplied for this package on create_media_buy. Sellers SHOULD echo this field whenever the request included it, including informational-echo cases where `format_ids` was the winning selector, so read surfaces preserve the original wire contract."
     },
     "params": {
@@ -74,17 +74,17 @@
       "additionalProperties": true
     },
     "targeting_overlay": {
-      "$ref": "/schemas/3.1.15/core/targeting.json"
+      "$ref": "/schemas/3.1.20/core/targeting.json"
     },
     "measurement_terms": {
-      "$ref": "/schemas/3.1.15/core/measurement-terms.json",
+      "$ref": "/schemas/3.1.20/core/measurement-terms.json",
       "description": "Agreed billing measurement and makegood terms for this package. Reflects what was negotiated — may differ from the buyer's proposal or the product's defaults. When present, these terms are binding for the package's duration."
     },
     "performance_standards": {
       "type": "array",
       "description": "Agreed performance standards for this package. When any entry specifies a vendor, creatives assigned to this package MUST include corresponding tracker_script or tracker_pixel assets from that vendor.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/performance-standard.json"
+        "$ref": "/schemas/3.1.20/core/performance-standard.json"
       },
       "minItems": 1
     },
@@ -92,7 +92,7 @@
       "type": "array",
       "description": "The binding reporting contract for this package — what the seller has agreed to populate in delivery reports. Each entry carries an explicit `committed_at` timestamp, so the array also serves as the contract amendment ledger: day-1 commitments share `committed_at = create_media_buy.confirmed_at`; mid-flight additions carry their own timestamps. When `create_media_buy.confirmed_at` is null for a provisional buy, sellers MUST omit `committed_metrics` until commitment. The first response that sets `confirmed_at` MAY include the initial committed-metrics set, and each such entry's `committed_at` MUST equal `confirmed_at`. The `missing_metrics` field on `get_media_buy_delivery` reconciles against this list, filtering to entries where `committed_at < reporting_period.end` (a metric committed mid-flight is only audited from its commitment timestamp forward). Sellers stamp the day-1 set on the `create_media_buy` response; mid-flight additions are appended via `update_media_buy` (append-only — sellers MUST reject attempts to modify or remove existing entries with `validation_error`, suggested code: `IMMUTABLE_FIELD`). Optional in v1; absence means the seller does not provide an audit-grade contract and `missing_metrics` falls back to the product's live `available_metrics` (a known audit gap — buyers SHOULD treat absence as 'no audit-grade contract' rather than 'clean delivery'). Each entry uses an explicit `scope` discriminator: `standard` for entries from the closed `available-metric.json` enum, `vendor` for vendor-defined metrics anchored on a BrandRef. The unified shape is symmetric with `missing_metrics` and `aggregated_totals.metric_aggregates` — same atomic unit `(scope, metric_id, qualifier)` across contract, diff, and delivery, so reconciliation collapses to a row-level join on the tuple. Replaces the parallel-array design that shipped briefly in #3510.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/committed-metric.json"
+        "$ref": "/schemas/3.1.20/core/committed-metric.json"
       },
       "minItems": 1,
       "examples": [
@@ -135,21 +135,21 @@
       "type": "array",
       "description": "Creative assets assigned to this package",
       "items": {
-        "$ref": "/schemas/3.1.15/core/creative-assignment.json"
+        "$ref": "/schemas/3.1.20/core/creative-assignment.json"
       }
     },
     "format_ids_to_provide": {
       "type": "array",
       "description": "Format IDs that creative assets will be provided for this package",
       "items": {
-        "$ref": "/schemas/3.1.15/core/format-id.json"
+        "$ref": "/schemas/3.1.20/core/format-id.json"
       }
     },
     "optimization_goals": {
       "type": "array",
       "description": "Optimization targets for this package. The seller optimizes delivery toward these goals in priority order. Common pattern: event goals (purchase, install) as primary targets at priority 1; metric goals (clicks, views) as secondary proxy signals at priority 2+.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/optimization-goal.json"
+        "$ref": "/schemas/3.1.20/core/optimization-goal.json"
       },
       "minItems": 1
     },
@@ -190,7 +190,7 @@
           "description": "ISO 8601 timestamp when this package was canceled."
         },
         "canceled_by": {
-          "$ref": "/schemas/3.1.15/enums/canceled-by.json",
+          "$ref": "/schemas/3.1.20/enums/canceled-by.json",
           "description": "Which party initiated the package cancellation."
         },
         "reason": {
@@ -217,11 +217,11 @@
       "description": "ISO 8601 timestamp for creative upload or change deadline for this package. After this deadline, creative changes are rejected. When absent, the media buy's creative_deadline applies."
     },
     "context": {
-      "$ref": "/schemas/3.1.15/core/context.json",
+      "$ref": "/schemas/3.1.20/core/context.json",
       "description": "Opaque package-level correlation data echoed unchanged in responses, webhooks, and read surfaces. Buyers targeting mixed seller populations SHOULD include a per-package correlation value here, commonly context.buyer_ref, so responses from legacy sellers that do not echo product_id can still be mapped back to the requested product or line item. Sellers MUST preserve this object unchanged and MUST NOT parse it for business logic."
     },
     "ext": {
-      "$ref": "/schemas/3.1.15/core/ext.json"
+      "$ref": "/schemas/3.1.20/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/core/pagination-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/pagination-request.json",
+  "$id": "/schemas/3.1.20/core/pagination-request.json",
   "title": "Pagination Request",
   "description": "Standard cursor-based pagination parameters for list operations",
   "type": "object",

package/dist/lib/schemas-data/3.1/core/pagination-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/pagination-response.json",
+  "$id": "/schemas/3.1.20/core/pagination-response.json",
   "title": "Pagination Response",
   "description": "Standard cursor-based pagination metadata for list responses",
   "type": "object",

package/dist/lib/schemas-data/3.1/core/performance-feedback.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/performance-feedback.json",
+  "$id": "/schemas/3.1.20/core/performance-feedback.json",
   "title": "Performance Feedback",
   "description": "Represents performance feedback data for a media buy or package",
   "type": "object",
@@ -48,7 +48,7 @@
       "minimum": 0
     },
     "metric_type": {
-      "$ref": "/schemas/3.1.15/enums/metric-type.json",
+      "$ref": "/schemas/3.1.20/enums/metric-type.json",
       "description": "**Deprecated as of this minor.** The legacy free-form metric enum that mixes metrics, verification, and attribution into one list. New implementations SHOULD use `metric` (the discriminated `(scope, metric_id, qualifier)` row shape) and populate `metric_type` with a best-effort string for one-minor backwards compatibility. When both `metric` and `metric_type` are present, consumers MUST use `metric` for dispatch. Removed at the next major. See [docs/measurement/taxonomy](https://docs.adcontextprotocol.org/docs/measurement/taxonomy) for why the layered shape replaces the flat enum."
     },
     "metric": {
@@ -66,7 +66,7 @@
               "description": "Standard metric from the closed `available-metric.json` enum."
             },
             "metric_id": {
-              "$ref": "/schemas/3.1.15/enums/available-metric.json",
+              "$ref": "/schemas/3.1.20/enums/available-metric.json",
               "description": "Identifier for the standard metric."
             },
             "qualifier": {
@@ -74,19 +74,19 @@
               "description": "Disambiguator — same shape as `committed_metrics.qualifier`. Carry `viewability_standard` for MRC vs GroupM viewability feedback; `completion_source` for seller- vs vendor-attested completion feedback; `attribution_methodology` and `attribution_window` for outcome-metric feedback (the buyer pinning a specific methodology or window when the feedback is methodology-sensitive). Closed (`additionalProperties: false`); new keys ship explicitly in subsequent minors.",
               "properties": {
                 "viewability_standard": {
-                  "$ref": "/schemas/3.1.15/enums/viewability-standard.json"
+                  "$ref": "/schemas/3.1.20/enums/viewability-standard.json"
                 },
                 "completion_source": {
-                  "$ref": "/schemas/3.1.15/enums/completion-source.json"
+                  "$ref": "/schemas/3.1.20/enums/completion-source.json"
                 },
                 "attribution_methodology": {
-                  "$ref": "/schemas/3.1.15/enums/attribution-methodology.json"
+                  "$ref": "/schemas/3.1.20/enums/attribution-methodology.json"
                 },
                 "attribution_window": {
-                  "$ref": "/schemas/3.1.15/core/duration.json"
+                  "$ref": "/schemas/3.1.20/core/duration.json"
                 },
                 "lift_dimension": {
-                  "$ref": "/schemas/3.1.15/enums/lift-dimension.json"
+                  "$ref": "/schemas/3.1.20/enums/lift-dimension.json"
                 }
               },
               "additionalProperties": false
@@ -106,11 +106,11 @@
               "description": "Vendor-defined metric, identified by the tuple `(vendor, metric_id)`."
             },
             "vendor": {
-              "$ref": "/schemas/3.1.15/core/brand-ref.json",
+              "$ref": "/schemas/3.1.20/core/brand-ref.json",
               "description": "Vendor that defines and computes this metric. Same identity discipline as `vendor_metric_value.vendor` and `committed_metrics` vendor-scope entries. Distinct from the row-level `vendor` field at the top of `performance-feedback`, which identifies the *source* of the feedback (the party producing it); this nested vendor identifies the *vendor that defines the metric* (which may or may not be the same party). Typically the same when third-party verification reports its own metric; can differ when a buyer's MMM tool reports on a separately-defined vendor metric."
             },
             "metric_id": {
-              "$ref": "/schemas/3.1.15/core/vendor-metric-id.json",
+              "$ref": "/schemas/3.1.20/core/vendor-metric-id.json",
               "description": "Identifier for the metric within the vendor's vocabulary."
             }
           },
@@ -124,11 +124,11 @@
       ]
     },
     "feedback_source": {
-      "$ref": "/schemas/3.1.15/enums/feedback-source.json",
+      "$ref": "/schemas/3.1.20/enums/feedback-source.json",
       "description": "Source of the performance data"
     },
     "vendor": {
-      "$ref": "/schemas/3.1.15/core/brand-ref.json",
+      "$ref": "/schemas/3.1.20/core/brand-ref.json",
       "description": "Vendor that produced this feedback. SHOULD be populated when `feedback_source` is `third_party_measurement` or `verification_partner` AND a single attesting vendor exists — without it, the row is unattributed and consumers can't verify authorization, resolve metric definitions, or route disputes. OMIT for blended outputs where no single vendor owns the result: MMM mixes (Nielsen MMM, Analytic Partners, in-house mix models combining multiple vendor inputs), multi-touch attribution outputs that join across vendors, and clean-room outputs (LiveRamp, Habu, AWS Clean Rooms) where the clean room is not the measurement source. For these cases, leave `vendor` absent and use the response's narrative payload to describe provenance. Optional for `buyer_attribution` and `platform_analytics` (those sources are implicit from context). The vendor's `brand.json` `agents[type='measurement']` is the discovery anchor; metric definitions live on the agent's `get_adcp_capabilities.measurement.metrics[]` block. Same identity discipline as `vendor_metric_value.vendor` and `performance-standard.vendor`."
     },
     "status": {

package/dist/lib/schemas-data/3.1/core/performance-standard.json

@@ -1,12 +1,12 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/performance-standard.json",
+  "$id": "/schemas/3.1.20/core/performance-standard.json",
   "title": "Performance Standard",
   "description": "A rate threshold for a performance metric, measured by a specified vendor. The threshold is a floor or ceiling depending on the metric: viewability, completion_rate, brand_safety, and attention_score are floors (must exceed); ivt is a ceiling (must not exceed).",
   "type": "object",
   "properties": {
     "metric": {
-      "$ref": "/schemas/3.1.15/enums/performance-standard-metric.json",
+      "$ref": "/schemas/3.1.20/enums/performance-standard-metric.json",
       "description": "The performance metric this standard applies to."
     },
     "threshold": {
@@ -16,11 +16,11 @@
       "description": "Rate threshold as a decimal (e.g., 0.70 for 70%). Whether this is a floor or ceiling depends on the metric: for viewability, completion_rate, brand_safety, attention_score the actual rate must be >= threshold; for ivt the actual rate must be <= threshold."
     },
     "standard": {
-      "$ref": "/schemas/3.1.15/enums/viewability-standard.json",
+      "$ref": "/schemas/3.1.20/enums/viewability-standard.json",
       "description": "Measurement standard. Required when metric is 'viewability' (MRC and GroupM define materially different thresholds). Omit for other metrics."
     },
     "vendor": {
-      "$ref": "/schemas/3.1.15/core/brand-ref.json",
+      "$ref": "/schemas/3.1.20/core/brand-ref.json",
       "description": "Vendor measuring this metric (e.g., { domain: 'doubleverify.com' }). The vendor's brand.json agents array (type: 'measurement') is the discovery point for their measurement agent. When specified on a confirmed package, creatives MUST include tracker_script or tracker_pixel assets from this vendor."
     }
   },

package/dist/lib/schemas-data/3.1/core/placement-definition.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/placement-definition.json",
+  "$id": "/schemas/3.1.20/core/placement-definition.json",
   "title": "Placement Definition",
   "description": "Canonical placement definition published in a publisher's adagents.json. Defines stable placement IDs that products can reuse and that authorization rules can reference. When a product reuses a registered placement_id, it is referring to this same semantic placement, not inventing a new one with the same ID.",
   "type": "object",
@@ -29,7 +29,7 @@
       "type": "array",
       "description": "Property IDs in this adagents.json where this placement can appear.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/property-id.json"
+        "$ref": "/schemas/3.1.20/core/property-id.json"
       },
       "minItems": 1
     },
@@ -37,7 +37,7 @@
       "type": "array",
       "description": "Property tags in this adagents.json where this placement can appear. Useful for network-wide positions such as 'pre_roll' or 'homepage_native_feed'.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/property-tag.json"
+        "$ref": "/schemas/3.1.20/core/property-tag.json"
       },
       "minItems": 1
     },
@@ -53,7 +53,7 @@
       "type": "array",
       "description": "Advertising channels where this placement can run. Products that reference the placement may narrow this set but should not broaden it.",
       "items": {
-        "$ref": "/schemas/3.1.15/enums/channels.json"
+        "$ref": "/schemas/3.1.20/enums/channels.json"
       },
       "uniqueItems": true,
       "minItems": 1
@@ -79,7 +79,7 @@
             "additionalProperties": true
           },
           {
-            "$ref": "/schemas/3.1.15/core/product-format-declaration.json",
+            "$ref": "/schemas/3.1.20/core/product-format-declaration.json",
             "title": "Inline declaration",
             "description": "Inline 3.1+ canonical format-option declaration. Use when the placement narrows a format in a way that's not worth a top-level catalog entry."
           }
@@ -91,7 +91,7 @@
       "type": "array",
       "description": "Declared video placement types for this publisher placement, using IAB Tech Lab/OpenRTB 2.6 video.plcmt definitions with AdCP-native names. Most concrete placements SHOULD declare a single value; aggregate placements MAY declare multiple values. Product-level placement declarations may narrow this set but SHOULD NOT broaden it. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "items": {
-        "$ref": "/schemas/3.1.15/enums/video-placement-type.json"
+        "$ref": "/schemas/3.1.20/enums/video-placement-type.json"
       },
       "uniqueItems": true,
       "minItems": 1
@@ -100,7 +100,7 @@
       "type": "array",
       "description": "Declared audio distribution types for this publisher placement, using IAB Tech Lab/OpenRTB 2.6 audio.feed definitions with AdCP-native names. Most concrete placements SHOULD declare a single value; aggregate placements MAY declare multiple values. Product-level placement declarations may narrow this set but SHOULD NOT broaden it. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "items": {
-        "$ref": "/schemas/3.1.15/enums/audio-distribution-type.json"
+        "$ref": "/schemas/3.1.20/enums/audio-distribution-type.json"
       },
       "uniqueItems": true,
       "minItems": 1
@@ -109,7 +109,7 @@
       "type": "array",
       "description": "Declared sponsored-placement types for this publisher placement, distinguishing where the catalog-driven retail-media placement renders on the retailer surface. Most concrete placements SHOULD declare a single value; aggregate placements MAY declare multiple values. Product-level placement declarations may narrow this set but SHOULD NOT broaden it. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "items": {
-        "$ref": "/schemas/3.1.15/enums/sponsored-placement-type.json"
+        "$ref": "/schemas/3.1.20/enums/sponsored-placement-type.json"
       },
       "uniqueItems": true,
       "minItems": 1
@@ -118,13 +118,13 @@
       "type": "array",
       "description": "Declared social-placement surfaces for this publisher placement, distinguishing the in-app surface where the social placement renders. Most concrete placements SHOULD declare a single value; aggregate placements MAY declare multiple values. Product-level placement declarations may narrow this set but SHOULD NOT broaden it. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "items": {
-        "$ref": "/schemas/3.1.15/enums/social-placement-surface.json"
+        "$ref": "/schemas/3.1.20/enums/social-placement-surface.json"
       },
       "uniqueItems": true,
       "minItems": 1
     },
     "ext": {
-      "$ref": "/schemas/3.1.15/core/ext.json"
+      "$ref": "/schemas/3.1.20/core/ext.json"
     }
   },
   "required": [

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

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/placement-ref.json",
+  "$id": "/schemas/3.1.20/core/placement-ref.json",
   "title": "Placement Reference",
   "description": "Reference to a placement by publisher domain and placement ID. Placement IDs are publisher-scoped, matching the placement catalog in that publisher's adagents.json. When `publisher_domain` is omitted on legacy inputs, receivers MAY interpret the placement ID relative to the seller agent's own publisher domain; new senders SHOULD include `publisher_domain`.",
   "type": "object",

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

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.15/core/placement.json",
+  "$id": "/schemas/3.1.20/core/placement.json",
   "title": "Placement",
   "description": "Represents a specific public ad placement within a product's inventory. Placement IDs are scoped by publisher domain, matching placement definitions in that publisher's adagents.json. `kind` is the structural discriminator: `publisher_ref` means this product placement is a reference to `{publisher_domain, placement_id}`; `seller_inline` means the seller is defining public buyer-facing placement metadata inline. The schema accepts either `name` or `publisher_domain` because publisher-referenced placements can omit `name` only when the publisher declaration supplies it; seller-inline placements carry `name` directly. Whether a reference was resolved from publisher-hosted adagents.json or a community-maintained fallback is resolver metadata, not placement structure. Buyers reference placements in creative assignments with structured PlacementRef objects (`publisher_domain` + `placement_id`) when a product spans multiple publishers or the namespace is otherwise ambiguous. Reusing a registered placement preserves the registry's semantic identity; product-level placement objects may narrow format_ids/format_options or add operational detail, but SHOULD NOT redefine the placement's meaning incompatibly.",
   "type": "object",
@@ -51,7 +51,7 @@
       "type": "array",
       "description": "Format IDs supported by this specific placement. Can include: (1) concrete format_ids (fixed dimensions), (2) template format_ids without parameters (accepts any dimensions/duration), or (3) parameterized format_ids (specific dimension/duration constraints). When present on a product placement, this field narrows the product-level `format_ids` contract for this placement and MUST NOT introduce formats the product does not accept.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/format-id.json"
+        "$ref": "/schemas/3.1.20/core/format-id.json"
       },
       "minItems": 1
     },
@@ -59,7 +59,7 @@
       "type": "array",
       "description": "3.1+ canonical format-option declarations supported by this specific product placement. When present, this field narrows the product-level `format_options` contract for this placement and MUST NOT introduce formats the product does not accept. Buyers compute the effective accepted formats for a placement as the intersection of product-level and placement-level declarations; placements without a format declaration inherit the product-level formats.",
       "items": {
-        "$ref": "/schemas/3.1.15/core/product-format-declaration.json"
+        "$ref": "/schemas/3.1.20/core/product-format-declaration.json"
       },
       "minItems": 1
     },
@@ -67,7 +67,7 @@
       "type": "array",
       "description": "Declared video placement types for this product placement, using IAB Tech Lab/OpenRTB 2.6 video.plcmt definitions with AdCP-native names. Most concrete placements SHOULD declare a single value; aggregate placements MAY declare multiple values. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "items": {
-        "$ref": "/schemas/3.1.15/enums/video-placement-type.json"
+        "$ref": "/schemas/3.1.20/enums/video-placement-type.json"
       },
       "uniqueItems": true,
       "minItems": 1
@@ -76,7 +76,7 @@
       "type": "array",
       "description": "Declared audio distribution types for this product placement, using IAB Tech Lab/OpenRTB 2.6 audio.feed definitions with AdCP-native names. Most concrete placements SHOULD declare a single value; aggregate placements MAY declare multiple values. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "items": {
-        "$ref": "/schemas/3.1.15/enums/audio-distribution-type.json"
+        "$ref": "/schemas/3.1.20/enums/audio-distribution-type.json"
       },
       "uniqueItems": true,
       "minItems": 1
@@ -85,7 +85,7 @@
       "type": "array",
       "description": "Declared sponsored-placement types for this product placement, distinguishing where the catalog-driven retail-media placement renders on the retailer surface. Most concrete placements SHOULD declare a single value; aggregate placements MAY declare multiple values. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "items": {
-        "$ref": "/schemas/3.1.15/enums/sponsored-placement-type.json"
+        "$ref": "/schemas/3.1.20/enums/sponsored-placement-type.json"
       },
       "uniqueItems": true,
       "minItems": 1
@@ -94,7 +94,7 @@
       "type": "array",
       "description": "Declared social-placement surfaces for this product placement, distinguishing the in-app surface where the social placement renders. Most concrete placements SHOULD declare a single value; aggregate placements MAY declare multiple values. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
       "items": {
-        "$ref": "/schemas/3.1.15/enums/social-placement-surface.json"
+        "$ref": "/schemas/3.1.20/enums/social-placement-surface.json"
       },
       "uniqueItems": true,
       "minItems": 1