@adcp/sdk 12.0.5 → 12.1.0

package/dist/lib/schemas-data/3.1/enums/asset-content-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/asset-content-type.json",
+  "$id": "/schemas/3.1.5/enums/asset-content-type.json",
   "title": "Asset Content Type",
   "description": "Types of content that can be used as creative assets. Describes what KIND of content an asset contains (image, video, code, etc.), not where it displays.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/attestation-claim.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/attestation-claim.json",
+  "$id": "/schemas/3.1.5/enums/attestation-claim.json",
   "title": "Attestation Claim",
   "description": "A claim a verified identity attestation can establish about a user. Personhood and age-threshold claims are deliberately a small, closed, issuer-agnostic set: a buyer must share semantics to act on a claim, and ZK proofs are practical only for a handful of standard thresholds. Age claims are threshold-only (\"over N\") — never a date of birth or exact age — and resolve to eligibility, never crossing the wire as an attribute. The set is additive: new thresholds may be added when a real legal threshold requires one.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/attribution-methodology.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/attribution-methodology.json",
+  "$id": "/schemas/3.1.5/enums/attribution-methodology.json",
   "title": "Attribution Methodology",
   "description": "How attribution between ad exposure and outcome events was computed. Used as a `qualifier.attribution_methodology` key on `committed_metrics`, `missing_metrics`, `metric_aggregates`, and `performance-feedback.metric` to disambiguate the same outcome metric reported under different methodologies — `conversion_value` measured deterministically (matched purchase IDs) is not the same number as `conversion_value` measured probabilistically (modeled match) and should never be summed across methodologies. The retail-media closed-loop pattern typically reports under `deterministic_purchase`; MMM and clean-room outputs typically report under `modeled` or `probabilistic`; panel-based measurement (Nielsen, comScore, Edison) reports under `panel_based`.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/attribution-model.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/attribution-model.json",
+  "$id": "/schemas/3.1.5/enums/attribution-model.json",
   "title": "Attribution Model",
   "description": "Attribution model used for conversion measurement",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/audience-source.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/audience-source.json",
+  "$id": "/schemas/3.1.5/enums/audience-source.json",
   "title": "Audience Source",
   "description": "Origin of an audience segment in delivery reporting breakdowns. Only 'synced' audiences are directly targetable via the targeting overlay; other sources are informational.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/audience-status.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/audience-status.json",
+  "$id": "/schemas/3.1.5/enums/audience-status.json",
   "title": "Audience Status",
   "description": "Matching status of a synced audience on a seller platform. Present when the sync action is created, updated, or unchanged; absent when the action is deleted or failed. See the Audience Sync specialism for transition rules.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/audio-channel-layout.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/audio-channel-layout.json",
+  "$id": "/schemas/3.1.5/enums/audio-channel-layout.json",
   "title": "Audio Channel Layout",
   "description": "Audio channel configuration for audio and video assets",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/audio-distribution-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/audio-distribution-type.json",
+  "$id": "/schemas/3.1.5/enums/audio-distribution-type.json",
   "title": "Audio Distribution Type",
   "description": "Declared audio distribution classification for radio, streaming-audio, podcast, and other audio inventory, using IAB Tech Lab/OpenRTB 2.6 audio.feed definitions with AdCP-native value names. This is seller-declared discovery metadata, not independent verification of inventory quality or delivery context.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/auth-scheme.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/auth-scheme.json",
+  "$id": "/schemas/3.1.5/enums/auth-scheme.json",
   "title": "Authentication Scheme",
   "description": "Legacy authentication schemes for the webhook auth block. Bearer: token sent in Authorization header. HMAC-SHA256: legacy shared-secret signing. Both are deprecated; new integrations SHOULD omit the authentication block and use the RFC 9421 webhook signing profile (applicable on schemas where authentication is optional). Removed in AdCP 4.0.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/available-metric.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/available-metric.json",
+  "$id": "/schemas/3.1.5/enums/available-metric.json",
   "title": "Available Metric",
   "description": "Standard delivery and performance metrics available for reporting",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/billing-party.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/billing-party.json",
+  "$id": "/schemas/3.1.5/enums/billing-party.json",
   "title": "Billing Party",
   "description": "Which party the seller invoices for an account. Determines the billing entity and invoicing flow.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/binary-verdict.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/binary-verdict.json",
+  "$id": "/schemas/3.1.5/enums/binary-verdict.json",
   "title": "Binary Verdict",
   "description": "Strictly two-outcome evaluation result used for overall record-level verdicts in content standards tasks. For per-feature breakdowns that include warning and unevaluated states, see feature-check-status.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/brand-agent-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/brand-agent-type.json",
+  "$id": "/schemas/3.1.5/enums/brand-agent-type.json",
   "title": "Brand Agent Type",
   "description": "Functional roles for agents declared in brand.json. Each type represents a distinct capability that a brand or house can expose via an agent endpoint.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/c2pa-watermark-action.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/c2pa-watermark-action.json",
+  "$id": "/schemas/3.1.5/enums/c2pa-watermark-action.json",
   "title": "C2PA Watermark Action",
   "description": "C2PA action classification for a content watermark. Distinguishes watermarks that are cryptographically linked to a C2PA manifest (bound) from watermarks that exist independently (unbound). Aligns with the c2pa.watermarked.* action family in the C2PA action taxonomy.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/canceled-by.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/canceled-by.json",
+  "$id": "/schemas/3.1.5/enums/canceled-by.json",
   "title": "Canceled By",
   "description": "Identifies which party initiated a cancellation.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/catalog-action.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/catalog-action.json",
+  "$id": "/schemas/3.1.5/enums/catalog-action.json",
   "title": "Catalog Action",
   "description": "Action taken on a catalog during sync operation",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/catalog-item-status.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/catalog-item-status.json",
+  "$id": "/schemas/3.1.5/enums/catalog-item-status.json",
   "title": "Catalog Item Status",
   "description": "Approval status of an individual item within a synced catalog. Platforms review catalog items and may approve, reject, or flag them for issues (similar to Google Merchant Center product review).",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/catalog-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/catalog-type.json",
+  "$id": "/schemas/3.1.5/enums/catalog-type.json",
   "title": "Catalog Type",
   "description": "The type of catalog feed. Determines the item schema and how the platform resolves catalog items. Multiple catalog types can be synced to the same account and referenced together in creatives.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/channels.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/channels.json",
+  "$id": "/schemas/3.1.5/enums/channels.json",
   "title": "Media Channel",
   "description": "Standardized advertising media channels describing how buyers allocate budget. Channels are planning abstractions, not technical substrates. See the Media Channel Taxonomy specification for detailed definitions.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/cloud-storage-protocol.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/cloud-storage-protocol.json",
+  "$id": "/schemas/3.1.5/enums/cloud-storage-protocol.json",
   "title": "Cloud Storage Protocol",
   "description": "Cloud storage protocols supported for offline file delivery",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/co-branding-requirement.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/co-branding-requirement.json",
+  "$id": "/schemas/3.1.5/enums/co-branding-requirement.json",
   "title": "Co-Branding Requirement",
   "description": "Co-branding policy for creatives (retailer/publisher brand inclusion)",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/collection-cadence.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/collection-cadence.json",
+  "$id": "/schemas/3.1.5/enums/collection-cadence.json",
   "title": "Collection Cadence",
   "description": "How frequently a collection releases new installments",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/collection-kind.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/collection-kind.json",
+  "$id": "/schemas/3.1.5/enums/collection-kind.json",
   "title": "Collection Kind",
   "description": "What kind of content program a collection represents. Determines how installments should be interpreted by buyer agents.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/collection-relationship.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/collection-relationship.json",
+  "$id": "/schemas/3.1.5/enums/collection-relationship.json",
   "title": "Collection Relationship",
   "description": "How two collections are related. References are scoped to the same get_products response. Symmetric types (companion, crossover) do not require both collections to declare the relationship.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/collection-status.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/collection-status.json",
+  "$id": "/schemas/3.1.5/enums/collection-status.json",
   "title": "Collection Status",
   "description": "Lifecycle status of a collection",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/completion-source.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/completion-source.json",
+  "$id": "/schemas/3.1.5/enums/completion-source.json",
   "title": "Completion Source",
   "description": "Trust-source disambiguator for `completion_rate` — *who* attested to the completion event, not *how* (methodology granularity is a separate dimension; future qualifier keys may add it if buyer demand surfaces). The two paths can yield materially different rates, particularly in SSAI environments where the player's view of completion may differ from a vendor's. Used as a `qualifier.completion_source` key on `committed_metrics`, `missing_metrics`, and `metric_aggregates` to disambiguate which trust source the row represents. Edge cases: walled gardens where the seller is also the measurement vendor (YouTube, Spotify) collapse to `seller_attested` by trust-model logic — the same party served and counted. IAB-certified first-party podcast measurement (Podtrac, Triton on their own platforms; Art19 on its own platform) likewise collapses to `seller_attested`. The same vendor's offering on a third-party platform (Podtrac on a publisher who isn't Podtrac) is `vendor_attested`. The trust axis is *not* who runs the SDK — it's who is independent of the seller's revenue interest.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/consent-basis.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/consent-basis.json",
+  "$id": "/schemas/3.1.5/enums/consent-basis.json",
   "title": "Consent Basis",
   "description": "Common GDPR lawful bases relevant to advertising. Covers the Article 6(1) bases used in programmatic advertising contexts.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/content-id-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/content-id-type.json",
+  "$id": "/schemas/3.1.5/enums/content-id-type.json",
   "title": "Content ID Type",
   "description": "Identifier type used in content_ids on conversion events to match back to catalog items. Omit when the identifier type is custom or not listed here.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/content-rating-system.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/content-rating-system.json",
+  "$id": "/schemas/3.1.5/enums/content-rating-system.json",
   "title": "Content Rating System",
   "description": "Rating systems for content advisory classifications",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/creative-action.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/creative-action.json",
+  "$id": "/schemas/3.1.5/enums/creative-action.json",
   "title": "Creative Action",
   "description": "Action taken on a creative during sync operation",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/creative-agent-capability.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/creative-agent-capability.json",
+  "$id": "/schemas/3.1.5/enums/creative-agent-capability.json",
   "title": "Creative Agent Capability",
   "description": "Capabilities supported by creative agents for format handling",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/creative-approval-status.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/creative-approval-status.json",
+  "$id": "/schemas/3.1.5/enums/creative-approval-status.json",
   "title": "Creative Approval Status",
   "description": "Approval state of a creative on a specific package",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/creative-event-reason-code.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/creative-event-reason-code.json",
+  "$id": "/schemas/3.1.5/enums/creative-event-reason-code.json",
   "title": "Creative Event Reason Code",
   "description": "Categorical reason carried on creative lifecycle webhooks (`creative.status_changed`, `creative.purged`). Distinct from `impairment-reason-code` because creative-policy reasons differ in vocabulary and remediation paths from media-buy delivery impairments — a creative may be revoked for a content-policy reason that produces no impairment on any buy, and an impairment may close without any creative-side status change. Buyers correlate the two via `creative_id` when both surfaces fire.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/creative-identifier-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/creative-identifier-type.json",
+  "$id": "/schemas/3.1.5/enums/creative-identifier-type.json",
   "title": "Creative Identifier Type",
   "description": "Industry-standard or market-specific identifier types for advertising creatives. These identifiers are managed by external registries or clearance bodies and are used across the supply chain to track and reference specific creative assets. This enum is intentionally closed: add a PR for additional shared identifier schemes rather than using an escape hatch.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/creative-quality.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/creative-quality.json",
+  "$id": "/schemas/3.1.5/enums/creative-quality.json",
   "title": "Creative Quality",
   "description": "Quality tier for creative generation, controlling the fidelity and cost tradeoff",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/creative-selection-strategy.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/creative-selection-strategy.json",
+  "$id": "/schemas/3.1.5/enums/creative-selection-strategy.json",
   "title": "Creative Selection Strategy",
   "description": "How a creative agent samples which catalog items / signal conditions to produce creatives for when max_creatives is below the eligible count (#5262). Selection ordering surfaces on the existing rank/recommended fields of build_creative's creatives[].variants[]. This is a curated set, not an open extension point — new strategies are added per the enum-membership criterion in spec-guidelines.md. Part of the experimental signal-fanout surface (x-status: experimental; feature id `creative.signal_fanout`).",
   "x-status": "experimental",

package/dist/lib/schemas-data/3.1/enums/creative-sort-field.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/creative-sort-field.json",
+  "$id": "/schemas/3.1.5/enums/creative-sort-field.json",
   "title": "Creative Sort Field",
   "description": "Fields available for sorting creative library listings",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/creative-status.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/creative-status.json",
+  "$id": "/schemas/3.1.5/enums/creative-status.json",
   "title": "Creative Status",
   "description": "Lifecycle status of a creative asset in a creative library. See the Creative Protocol specification for transition rules.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/daast-tracking-event.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/daast-tracking-event.json",
+  "$id": "/schemas/3.1.5/enums/daast-tracking-event.json",
   "title": "DAAST Tracking Event",
   "description": "Tracking events for audio ads. Aligned to the IAB DAAST 1.1 `Tracking@event` enumeration from §3.2.1.7 of the spec (creativeView, start, firstQuartile, midpoint, thirdQuartile, complete, mute, unmute, pause, rewind, resume, skip, progress) — plus `close` (referenced descriptively in DAAST 1.1 §3.2.4.2 contrasting it with `skip`), and AdCP-flattened representations of the `Impression`, `Error`, and click elements (`<Impression>`, `<Error>`, and the click children of `<AdInteractions>`) so a single declared list can cover everything a measurement vendor wants to track. `viewable` / `notViewable` / `viewUndetermined` and `measurableImpression` / `viewableImpression` are AdCP extensions for OM-SDK Audio measurability signals (DAAST 1.1 itself does not define a `<ViewableImpression>` element). DAAST 1.1 audio-incompatible video events are deliberately omitted: no `loaded`, `playerExpand` / `playerCollapse`, `fullscreen` / `exitFullscreen`, `acceptInvitation`, `adExpand` / `adCollapse`, `minimize`, `overlayViewDuration`, or `interactiveStart`.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/daast-version.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/daast-version.json",
+  "$id": "/schemas/3.1.5/enums/daast-version.json",
   "title": "DAAST Version",
   "description": "Supported DAAST (Digital Audio Ad Serving Template) specification versions",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/day-of-week.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/day-of-week.json",
+  "$id": "/schemas/3.1.5/enums/day-of-week.json",
   "title": "Day of Week",
   "description": "Days of the week for daypart targeting",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/delegation-authority.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/delegation-authority.json",
+  "$id": "/schemas/3.1.5/enums/delegation-authority.json",
   "title": "Delegation Authority",
   "description": "Authority level granted to a delegated agent operating against a campaign plan.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/delivery-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/delivery-type.json",
+  "$id": "/schemas/3.1.5/enums/delivery-type.json",
   "title": "Delivery Type",
   "description": "Type of inventory delivery",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/demographic-system.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/demographic-system.json",
+  "$id": "/schemas/3.1.5/enums/demographic-system.json",
   "title": "Demographic System",
   "description": "Audience measurement systems for demographic notation in GRP forecasts and pricing",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/derivative-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/derivative-type.json",
+  "$id": "/schemas/3.1.5/enums/derivative-type.json",
   "title": "Derivative Type",
   "description": "What kind of derivative content an installment represents relative to its source installment. The source installment_id must reference an installment within the same response.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/device-platform.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/device-platform.json",
+  "$id": "/schemas/3.1.5/enums/device-platform.json",
   "title": "Device Platform",
   "description": "Operating system platforms for device targeting. Browser values from Sec-CH-UA-Platform standard, extended for CTV.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/device-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/device-type.json",
+  "$id": "/schemas/3.1.5/enums/device-type.json",
   "title": "Device Type",
   "description": "Device form factor categories for targeting and reporting. Complements device-platform (operating system) with hardware classification. OpenRTB mapping: 1 (Mobile/Tablet General) → mobile, 2 (PC) → desktop, 4 (Phone) → mobile, 5 (Tablet) → tablet, 6 (Connected Device) → ctv, 7 (Set Top Box) → ctv. DOOH inventory uses dooh.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/digital-source-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/digital-source-type.json",
+  "$id": "/schemas/3.1.5/enums/digital-source-type.json",
   "title": "Digital Source Type",
   "description": "Classification of AI involvement in content creation, aligned with IPTC digitalsourcetype vocabulary. Used in provenance metadata to declare how a creative asset, artifact, or individual asset was produced.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/dimension-unit.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/dimension-unit.json",
+  "$id": "/schemas/3.1.5/enums/dimension-unit.json",
   "title": "Dimension Unit",
   "description": "Units of measurement for creative format dimensions",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/disclosure-persistence.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/disclosure-persistence.json",
+  "$id": "/schemas/3.1.5/enums/disclosure-persistence.json",
   "title": "Disclosure Persistence",
   "description": "How long a disclosure must persist during content playback or display. Different jurisdictions and regulations require different persistence behaviors for AI-generated content labels. When multiple sources specify persistence for the same jurisdiction (e.g., brief and provenance), the most restrictive mode applies: continuous > initial > flexible.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/disclosure-position.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/disclosure-position.json",
+  "$id": "/schemas/3.1.5/enums/disclosure-position.json",
   "title": "Disclosure Position",
   "description": "Where a required disclosure should appear within a creative. Used by creative briefs to specify disclosure placement and by formats to declare which positions they can render.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/distance-unit.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/distance-unit.json",
+  "$id": "/schemas/3.1.5/enums/distance-unit.json",
   "title": "Distance Unit",
   "description": "Units of distance measurement for radius-based catchment areas.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/distribution-identifier-type.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/distribution-identifier-type.json",
+  "$id": "/schemas/3.1.5/enums/distribution-identifier-type.json",
   "title": "Distribution Identifier Type",
   "description": "Platform-specific identifier types for collection distribution. Maps a collection to its presence on specific platforms, enabling cross-seller matching.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/embedded-provenance-method.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/embedded-provenance-method.json",
+  "$id": "/schemas/3.1.5/enums/embedded-provenance-method.json",
   "title": "Embedded Provenance Method",
   "description": "How provenance data is carried within the content stream. Distinguishes between format-level manifest embedding (where the manifest travels inside the file container) and provenance markers (where invisible markers in the content itself encode or reference a provenance record). Both survive operations that strip sidecar metadata, but provenance markers additionally survive content-level transformations such as copy-paste, reformatting, and CMS re-encoding.",
   "type": "string",

package/dist/lib/schemas-data/3.1/enums/error-code.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/error-code.json",
+  "$id": "/schemas/3.1.5/enums/error-code.json",
   "title": "Error Code",
   "description": "Standard error code vocabulary for AdCP. Codes are machine-readable so agents can apply autonomous recovery strategies based on the recovery classification. Sellers MAY return codes not listed here for platform-specific errors — the error.json code field accepts any string. Agents MUST handle unknown codes by falling back to the recovery classification.",
   "type": "string",
@@ -104,7 +104,7 @@
     "AUTH_MISSING": "No credentials were presented. Sellers MUST return this code when no `Authorization` header was included in the request. Recovery: correctable (provide credentials via the auth header and retry).",
     "AUTH_INVALID": "Credentials were presented but rejected — revoked, malformed signature, or a key no longer in the seller's keystore. Sellers MUST return this code when an `Authorization` header was present but verification failed. Recovery: terminal. Exception: agents with a valid OAuth 2.1 refresh grant MAY treat this as correctable when the rejection reason is token expiry — silently refresh and retry once; if the refresh fails or the seller explicitly signals revocation, escalate to human.",
     "AUTHORIZATION_REQUIRED": "The caller is authenticated, but the referenced object requires an additional downstream platform connection, identity, creator, or post authorization before the seller can complete the requested action. Typical use: `sync_creatives` with a `published_post` reference where the seller can resolve the post but the owning identity has not authorized paid serving, or authorization has expired/revoked and can be restored. Distinct from `AUTH_MISSING` / `AUTH_INVALID` (caller credentials) and from `PERMISSION_DENIED` (seller policy denies the caller). Sellers SHOULD include recovery details conforming to `error-details/authorization-required.json`, especially `error.details.missing_connections[]` when the caller needs to complete one of several platform connections. Legacy recovery hints such as `authorization_url`, `authorization_instructions`, or `reference_authorization` remain valid when safe to disclose. Recovery: correctable (complete or restore the required authorization, then retry).",
-    "RATE_LIMITED": "Request rate exceeded. Retry after the retry_after interval. Recovery: transient.",
+    "RATE_LIMITED": "Request rate exceeded. Sellers SHOULD populate top-level `error.retry_after` with the number of seconds to wait. Recovery: transient (wait `error.retry_after` seconds when present, then retry).",
     "SERVICE_UNAVAILABLE": "Seller service is temporarily unavailable. Retry with exponential backoff. Recovery: transient.",
     "CONFIGURATION_ERROR": "The seller's deployment is misconfigured in a way that prevents handling the request — the buyer cannot fix it, retrying will not help, and reporting to the seller's operator is the only remediation. Examples: account declared with `mode: 'mock'` but no `mock_upstream_url` populated; platform declared with `mode: 'live'` or `mode: 'sandbox'` but no `upstream_url` declared; required environment variable unset on the seller process. Distinct from `INVALID_REQUEST` (buyer-fixable; the request itself is malformed), `SERVICE_UNAVAILABLE` (transient; retry-with-backoff may succeed), `UNSUPPORTED_FEATURE` (capability mismatch — the seller does not implement the requested specialism), `ACCOUNT_SETUP_REQUIRED` (buyer-side onboarding incomplete; this code is seller-side deployment incomplete), and `GOVERNANCE_UNAVAILABLE` (governance-agent-scoped; transient). Wire placement. The deployment cannot produce a success artifact, so sellers MUST flip transport-level failure markers (HTTP 5xx, MCP `isError: true`, A2A `failed`) and populate both layers per the two-layer model in `error-handling.mdx#envelope-vs-payload-errors-the-two-layer-model`. The code itself is the discriminator; no `error.details` shape is defined for this code (mirroring the minimal-disclosure precedent of `AGENT_SUSPENDED` / `AGENT_BLOCKED`). Sellers SHOULD populate `error.message` with operator-actionable detail (which metadata key is missing, which env var is unset) and MUST NOT include credentials, connection strings, or stack traces — the message is wire-visible to the buyer. Recovery: terminal — the buyer MUST surface to the seller's operator and MUST NOT auto-retry (retries cannot resolve a misconfigured deployment until the operator intervenes).",
     "POLICY_VIOLATION": "Request violates the seller's content or advertising policies. Recovery: correctable (review policy requirements in the error details).",
@@ -134,7 +134,7 @@
     "CONFLICT": "Concurrent modification detected. The resource was modified by another request between read and write. Recovery: transient (re-read the resource and retry with current state).",
     "IDEMPOTENCY_CONFLICT": "An earlier request with the same idempotency_key was processed with a different canonical payload within the seller's replay window. Distinct from CONFLICT (concurrent write) — this indicates the client reused a key across semantically different requests. Recovery: correctable (use a fresh UUID v4 for the new request, or resend the exact original payload to get the cached response).",
     "IDEMPOTENCY_EXPIRED": "The idempotency_key was seen previously but its cached response has been evicted because it is past the seller's declared replay_ttl_seconds. Distinct from IDEMPOTENCY_CONFLICT (different payload within window) — this indicates the retry arrived too late for at-most-once guarantees. Recovery: correctable (perform a natural-key reconciliation — e.g., call get_media_buys for the relevant account/status scope and match returned media_buys[].context.internal_campaign_id — to determine whether the original request succeeded, then either accept that result or generate a fresh idempotency_key for a new attempt). If the buyer has any evidence the prior call succeeded (partial response received before crash, entry in the buyer's own DB, a webhook fired), the buyer MUST do the natural-key reconciliation BEFORE minting a new key — minting a new key in that situation is exactly how double-creation happens.",
-    "IDEMPOTENCY_IN_FLIGHT": "A prior request with the same `idempotency_key` is still being processed and has not yet produced a cached response. The second request arrived before the first completed. Sellers MAY return this code instead of blocking the second caller until the first finishes — useful when the first call invokes a slow downstream system (SSP, ad server, payment provider). Distinct from IDEMPOTENCY_CONFLICT (different canonical payload — a client bug) and from CONFLICT (concurrent modification of a different resource) — IDEMPOTENCY_IN_FLIGHT is the seller telling the buyer 'your retry was correct but your previous attempt is still running, come back shortly.' Sellers SHOULD populate `error.details.retry_after` (seconds, integer) with a wait hint based on the first request's elapsed time and expected completion. Buyers MUST treat this as transient and MUST NOT mint a fresh `idempotency_key` — minting a new key turns a safe retry into a double-execution race. Recovery: transient (wait `retry_after` seconds and retry with the same `idempotency_key`; the second attempt will either replay the now-cached response or, if still in flight, return IDEMPOTENCY_IN_FLIGHT again).",
+    "IDEMPOTENCY_IN_FLIGHT": "A prior request with the same `idempotency_key` is still being processed and has not yet produced a cached response. The second request arrived before the first completed. Sellers MAY return this code instead of blocking the second caller until the first finishes — useful when the first call invokes a slow downstream system (SSP, ad server, payment provider). Distinct from IDEMPOTENCY_CONFLICT (different canonical payload — a client bug) and from CONFLICT (concurrent modification of a different resource) — IDEMPOTENCY_IN_FLIGHT is the seller telling the buyer 'your retry was correct but your previous attempt is still running, come back shortly.' Sellers SHOULD populate top-level `error.retry_after` (seconds) with a wait hint based on the first request's elapsed time and expected completion. Buyers MUST treat this as transient and MUST NOT mint a fresh `idempotency_key` — minting a new key turns a safe retry into a double-execution race. Recovery: transient (wait `error.retry_after` seconds and retry with the same `idempotency_key`; the second attempt will either replay the now-cached response or, if still in flight, return IDEMPOTENCY_IN_FLIGHT again).",
     "INVALID_STATE": "Operation is not permitted for the resource's current status (e.g., updating a completed or canceled media buy, or modifying a canceled package). Recovery: correctable (check current status via get_media_buys and adjust request).",
     "MEDIA_BUY_NOT_FOUND": "Referenced media buy does not exist or is not accessible to the requesting agent. Recovery: correctable (verify media_buy_id; when recovering across legacy sellers or missing echoed IDs, reconcile via get_media_buys and the opaque request/response context correlation handle, such as context.internal_campaign_id, rather than deprecated top-level buyer_ref).",
     "NOT_CANCELLABLE": "The media buy or package cannot be canceled in its current state. The seller may have contractual or operational constraints that prevent cancellation. Recovery: correctable (check the seller's cancellation policy or contact the seller).",
@@ -216,7 +216,7 @@
     },
     "RATE_LIMITED": {
       "recovery": "transient",
-      "suggestion": "retry after the retry_after interval"
+      "suggestion": "wait top-level error.retry_after seconds when present, then retry"
     },
     "SERVICE_UNAVAILABLE": {
       "recovery": "transient",
@@ -328,7 +328,7 @@
     },
     "IDEMPOTENCY_IN_FLIGHT": {
       "recovery": "transient",
-      "suggestion": "wait error.details.retry_after seconds and retry with the SAME idempotency_key — MUST NOT mint a fresh key (turns a safe retry into a double-execution race)"
+      "suggestion": "wait top-level error.retry_after seconds and retry with the SAME idempotency_key — MUST NOT mint a fresh key (turns a safe retry into a double-execution race)"
     },
     "CREATIVE_DEADLINE_EXCEEDED": {
       "recovery": "correctable",

package/dist/lib/schemas-data/3.1/enums/error-scope.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/enums/error-scope.json",
+  "$id": "/schemas/3.1.5/enums/error-scope.json",
   "title": "Error Scope",
   "description": "Shared discriminator vocabulary for `error.details.scope` across `error-details/` shapes that distinguish *which axis* of the seller's relationship triggered the rejection. Each error-details shape constrains its own `scope` field to the registered subset relevant to that code (e.g., `error-details/billing-not-supported.json` accepts `\"capability\" | \"account\"`; `error-details/agent-permission-denied.json` accepts only `\"agent\"`). This enum is the single source of truth for the union vocabulary so cross-language SDKs can dispatch on `details.scope` without re-deriving the value space per code. New scopes added here SHOULD be reflected in the per-shape constrained subsets that emit them, and MUST be coordinated across the `error-details/` schemas that participate in the discriminator.",
   "type": "string",