@adcp/sdk 12.0.5 → 12.1.0

package/dist/lib/schemas-data/3.1/formats/canonical/_base.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/_base.json",
+  "$id": "/schemas/3.1.5/formats/canonical/_base.json",
   "title": "Canonical Format Base",
   "description": "Shared parameter fields that apply across canonical formats. Each canonical format extends this base with format-specific parameters (dimensions, durations, codecs, slot constraints).",
   "type": "object",
@@ -46,7 +46,7 @@
       "type": "array",
       "description": "Platform-specific extensions narrowing the canonical (pixel ID shapes, conversion event taxonomies, platform-specific CTAs/destinations). Each extension is a URI+digest reference resolved against the bundled `extensions` map in get_products responses or fetched directly.\n\n**Collision precedence (normative).** When two or more `platform_extensions[]` entries on the same declaration extend the same target (e.g., both extend `tracking`) with overlapping field names, **array order is authoritative — later entries override earlier ones on a per-field basis** (last-in-array-wins). SDKs MUST surface the overlap via the `errors[]` array on the `get_products` response with a structured code (`FORMAT_DECLARATION_DIVERGENT` is appropriate when the overlap appears across dual-emitted shapes; a producer-self-emitted overlap on a single declaration SHOULD use the same code with `error.details: { collision_kind: \"platform_extension_field\", target, overlapping_fields, winning_extension_uri }`). Producers SHOULD avoid the collision by emitting one extension per target or by partitioning fields across extensions; the deterministic precedence is for last-resort consistency across SDK implementations, not a sanctioned merging strategy.",
       "items": {
-        "$ref": "/schemas/3.1.2/core/platform-extension-ref.json"
+        "$ref": "/schemas/3.1.5/core/platform-extension-ref.json"
       }
     },
     "synthesis_nondeterministic": {
@@ -123,7 +123,7 @@
           "logo_slots": {
             "type": "array",
             "items": {
-              "$ref": "/schemas/3.1.2/enums/logo-slot.json"
+              "$ref": "/schemas/3.1.5/enums/logo-slot.json"
             },
             "uniqueItems": true,
             "description": "When `asset_group_id` is `logo`, renderer-facing brand.json logo slots acceptable for this format slot. Producers selecting from brand.json SHOULD prefer `logos[]` entries whose `slots[]` intersects this list, then apply `visual_guidelines.logo_usage_rules[]`."
@@ -131,7 +131,7 @@
           "required_logo_slots": {
             "type": "array",
             "items": {
-              "$ref": "/schemas/3.1.2/enums/logo-slot.json"
+              "$ref": "/schemas/3.1.5/enums/logo-slot.json"
             },
             "uniqueItems": true,
             "description": "Subset of `logo_slots` for which this format expects explicit logo coverage. A manifest or brand-derived logo pool SHOULD include at least one usable logo for each required slot; if coverage is missing, builders SHOULD surface a validation warning or approval mapping instead of guessing from prose."
@@ -277,7 +277,7 @@
     "required_connections": {
       "type": "array",
       "items": {
-        "$ref": "/schemas/3.1.2/core/downstream-connection-requirement.json"
+        "$ref": "/schemas/3.1.5/core/downstream-connection-requirement.json"
       },
       "description": "Downstream platform connections or grants required to use this format declaration. These are in addition to the single AdCP caller credential. Use this when a platform product requires multiple downstream grants, such as an advertiser account connection plus a publisher identity or post authorization for published-post references."
     },

package/dist/lib/schemas-data/3.1/formats/canonical/agent_placement.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/agent_placement.json",
+  "$id": "/schemas/3.1.5/formats/canonical/agent_placement.json",
   "title": "Canonical Format: Agent Placement (AI-surface sponsored placement)",
   "description": "**3.2-track canonical.** The structural shape (algorithmic composition + brand-context input + optional offering/landing_page) is captured here so adopters can declare against it in 3.1 catalogs, but the **mention-level tracking contract is intentionally underspecified for 3.1**: no normative macro vocabulary, no postback shape, no cross-surface dedup model. Adopters claiming `agent_placement` in 3.1 ship private tracking integrations and SHOULD leave `experimental: true` on the product declaration that references this canonical; buyer agents MUST treat agent_placement attribution as adapter-defined until the 3.2 tracking-macro spec lands. The canonical promotes to a normatively-buyer-callable surface in 3.2 (or later) once the tracking contract is specified.\n\nSponsored placement integrated into an AI-surface's response to a user. Buyer supplies a `BrandRef` (resolving brand.json for context), an optional `offering_ref` to focus the mention on a specific offering, and an optional `landing_page_url` the surface MAY attach as a citation. The surface (LLM, voice assistant, sponsored-search ranker) composes a natural-language mention, sponsored card, or audio snippet within its response to a user query. **Composition is algorithmic** — the agent chooses phrasing and presentation. Output asset_type varies by surface: `text` for chat UIs and sponsored search snippets; `audio` (synthesized) for voice assistants; `card` for structured AI-surface result cards. Tracking model: mention-level impression + attribution events; per-mention id keys back to brand and offering — but see the 3.2-track note above; the wire shape of these events is not yet specified. Distinct from `si_chat` (which is the user-converses-with-brand's-agent pattern — brand owns the conversational surface) and from `sponsored_placement` (retail-media catalog-driven). Parallels `sponsored_placement` structurally: both are surface-composed placements; agent_placement is for AI/agentic surfaces, sponsored_placement is for retail media.",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     }
   ],
   "properties": {

package/dist/lib/schemas-data/3.1/formats/canonical/audio_daast.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/audio_daast.json",
+  "$id": "/schemas/3.1.5/formats/canonical/audio_daast.json",
   "title": "Canonical Format: DAAST Audio",
   "description": "DAAST-tag-delivered audio creative (audio analog of VAST). Slot: `daast_tag` (daast asset, URL or inline XML). Tracking model: DAAST events inherent to the spec — `impression`, `firstQuartile`, `midpoint`, `thirdQuartile`, `complete`, `start`, `pause`, `resume`, `mute`, `unmute`, `clickTracking`, `error`. Distinct from `audio_hosted` (direct file with external tracking).",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     }
   ],
   "properties": {

package/dist/lib/schemas-data/3.1/formats/canonical/audio_hosted.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/audio_hosted.json",
+  "$id": "/schemas/3.1.5/formats/canonical/audio_hosted.json",
   "title": "Canonical Format: Hosted Audio",
   "description": "Direct audio creative — buyer ships an `audio` asset (mp3/aac/wav) for asset-driven products, or ships a `script` / `creative_brief` text asset for products where the seller produces audio internally (podcast host-reads, TTS synthesis). Optional companion slots: `companion_image`, `brand_name`, `landing_page_url`. Tracking model: standard impression + completion + companion-image-click pixels via universal_macros. Distinct from `audio_daast` (DAAST tag, inherent DAAST event tracking). For host-reads and synthesized audio, the format declares `asset_source: 'publisher_host_recorded'` or `'agent_synthesized'` plus `buyer_asset_acceptance: 'rejected'`; the format's `slots` declaration enumerates which assets the buyer ships (e.g., `script` text asset for host-reads). The seller decides how to consume each asset (render verbatim vs produce audio from text) — there is no separate manifest 'inputs' map; everything the buyer ships goes in `assets`.",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     }
   ],
   "properties": {

package/dist/lib/schemas-data/3.1/formats/canonical/display_tag.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/display_tag.json",
+  "$id": "/schemas/3.1.5/formats/canonical/display_tag.json",
   "title": "Canonical Format: Display Tag",
   "description": "Third-party-served display tag (JS, iframe, or 1×1 redirect). The buyer's adserver hosts the creative; the seller calls the tag URL at impression time. Slot: `tag_url` (url asset with appropriate `url_type`). Tracking model: opaque to seller — third party serves and measures. Click tracking via redirect URL substitution using universal_macros. Distinct from `image` (static asset hosted by seller) and `html5` (zip bundle hosted by seller).",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     },
     {
       "title": "Size-mode mutex",

package/dist/lib/schemas-data/3.1/formats/canonical/html5.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/html5.json",
+  "$id": "/schemas/3.1.5/formats/canonical/html5.json",
   "title": "Canonical Format: HTML5 Banner",
   "description": "Interactive HTML5 banner delivered as a zip archive. Slot: `html5_bundle` (zip asset). Tracking model: MRAID + IAB Open Measurement (OM-SDK) + click-tag macro substitution + backup image fallback. Receivers unpack the zip, validate internal structure, and serve from CDN. Distinct from `image` (static, non-interactive) and `display_tag` (third-party served). The zip's entry point is typically `index.html`; click handling uses `clickTag` (or `clickTAG`) macro substitution.",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     },
     {
       "title": "Size-mode mutex",

package/dist/lib/schemas-data/3.1/formats/canonical/image.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/image.json",
+  "$id": "/schemas/3.1.5/formats/canonical/image.json",
   "title": "Canonical Format: Image",
   "description": "Static image creative format. Slots: `image_main` (image asset, file or hosted URL), optional `headline` (text), `body_text` (text), `cta` (text/enum), `landing_page_url` (url). Tracking model: impression pixel + click URL via universal_macros, with optional viewability pixel. Distinct from `html5` (interactive bundles) and `display_tag` (third-party served). AR/dimensions narrow to specific sizes via product parameters — covers IAB display sizes (300x250, 728x90, 970x250, etc.) without a separate iab_size enum.",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     },
     {
       "title": "Size-mode mutex",

package/dist/lib/schemas-data/3.1/formats/canonical/image_carousel.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/image_carousel.json",
+  "$id": "/schemas/3.1.5/formats/canonical/image_carousel.json",
   "title": "Canonical Format: Image Carousel",
   "description": "Multi-card swipeable carousel. The buyer ships a `cards` slot whose value is an **array** of [card-asset](/schemas/core/assets/card-asset.json) objects (a single key with an array value — NOT one key per card, NOT dotted/bracketed paths). Each card-asset carries: `asset_type: \"card\"`, `media` (an image or video asset), optional `headline` (text), optional `landing_page_url` (url asset). Per-card structure is the same across all cards; mixed orientations not allowed within a single carousel. Tracking model: per-card impression and engagement pixels + carousel-level engagement (swipe, view-time). Allowed asset types for a card's `media` field: `image` and `video` (Meta-style mixed-media); platforms can narrow to image-only or video-only via `allowed_card_media_asset_types`.\n\nThe manifest's `assets.cards` value is an array of card-asset objects. Example: `\"cards\": [{\"asset_type\": \"card\", \"media\": {\"asset_type\": \"image\", \"url\": \"...\"}, \"headline\": \"Buy now\", \"landing_page_url\": {\"asset_type\": \"url\", \"url_type\": \"clickthrough\", \"url\": \"...\"}}, ...]`. Each card-asset validates against the card schema; per-card platform extensions attach via the card's `platform_extensions` field, never via inline non-canonical keys.",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     }
   ],
   "properties": {

package/dist/lib/schemas-data/3.1/formats/canonical/native_in_feed.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/native_in_feed.json",
+  "$id": "/schemas/3.1.5/formats/canonical/native_in_feed.json",
   "title": "Canonical Format: Native In-Feed",
   "description": "IAB-shaped native creative for in-feed and content-recommendation surfaces. Default slots cover the primary IAB OpenRTB Native 1.2 asset types — `title` (Title Asset), `body_text` (Data Asset type 2), `main_image` (Image Asset main), `icon` (Image Asset icon), `cta` (Data Asset type 12), `advertiser_name` (Data Asset type 1), `sponsored_label` (Title-adjacent), `landing_page_url` (Link Asset), `display_url` (Data Asset type 11 — visible URL/domain, distinct from clickthrough), `rating` (Data Asset type 3 — app/product rating), `price` (Data Asset type 6 — product price), plus renderer-fired `impression_tracker` / `viewability_tracker` / `click_tracker` (`pixel_tracker`). Products MAY use `slots_override` to add other IAB Native data asset types (likes — type 4, downloads — type 5, saleprice — type 7, phone_number — type 8, address — type 9, desc2 — type 10, etc.) or to remove slots the surface doesn't render. The publisher's renderer assembles these into its own look-and-feel — feed card, content-recommendation slot, in-stream native unit. Buyer ships a single asset bundle; the surface chooses presentation.\n\n**Scope (normative — buyer-agent routing).** This canonical is the home for:\n- IAB OpenRTB Native 1.2 in-feed native ads (publisher feeds, app feeds)\n- Content-recommendation widgets (Taboola, Outbrain, Yahoo Recommendations)\n- AdMob Native / Yahoo Native publisher slots\n- In-feed sponsored placements without catalog dependency\n\n**Not this canonical:**\n- Catalog-driven retail-media (Amazon SP, Criteo SP, CitrusAd SP) — use `sponsored_placement` (requires `source_catalog`).\n- Algorithmic surface that picks from a buyer-supplied asset pool (Google PMax, Meta Advantage+) — use `responsive_creative`.\n- Multi-card carousel — use `image_carousel`.\n- Video-first native units where the asset is a hosted video file — use `video_hosted` with `applies_to_channels: [\"native\"]`.\n\nDistinct from `sponsored_placement` along the catalog axis: native_in_feed is asset-bundle composition; sponsored_placement is catalog-row composition. A buyer agent reading `format_kind: native_in_feed` knows to assemble title + image + body + CTA; reading `format_kind: sponsored_placement` knows to attach a catalog feed.",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     }
   ],
   "properties": {

package/dist/lib/schemas-data/3.1/formats/canonical/responsive_creative.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/responsive_creative.json",
+  "$id": "/schemas/3.1.5/formats/canonical/responsive_creative.json",
   "title": "Canonical Format: Responsive Creative",
   "description": "Buyer supplies a pool of typed assets (multiple headlines, descriptions, images, videos, logos); the surface algorithmically composes combinations per placement. **Composition is algorithmic** — surface picks combinations and reports per-asset performance breakdowns. Covers Google Responsive Display Ads (RDA), Responsive Search Ads (RSA), Performance Max (PMax), Demand Gen, and Meta Advantage+ creative. Industry term: \"Responsive\" (Google) / \"Advantage+ creative\" (Meta) / \"Dynamic Creative\" (older Meta term). Distinct from `sponsored_placement` (catalog-driven, deterministic) and `agent_placement` (AI-surface composition). The structured `slots` field below enumerates expected canonical asset_group_id slots; per-slot count/length narrowing lives in flat parameters (`headlines_min`, `headline_max_chars`, etc.).",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     }
   ],
   "properties": {

package/dist/lib/schemas-data/3.1/formats/canonical/sponsored_placement.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/sponsored_placement.json",
+  "$id": "/schemas/3.1.5/formats/canonical/sponsored_placement.json",
   "title": "Canonical Format: Sponsored Placement (retail-media catalog-driven)",
   "description": "Catalog-driven retail-media format. Slot: `source_catalog` (catalog asset — product/SKU/ASIN/GTIN catalog reference, REQUIRED), optional `hero_asset`, optional `landing_page_url`. Buyer supplies the catalog reference; surface composes per-item or multi-item rendering using its native placement template. **Composition is deterministic** — buyer can predict per-slot rendering from the catalog item structure. Tracking model: per-item impression + click + conversion (catalog-keyed via offering_id/sku/gtin macros). Covers Amazon Sponsored Products, Criteo Sponsored Products, CitrusAd Sponsored Products, Walmart Connect Sponsored Products, Pinterest Collection (catalog-driven mode).\n\n**Scope (normative — buyer-agent routing).** This canonical is the home for catalog-driven retail-media placements ONLY. The defining feature is the `source_catalog` slot — products under this canonical compose their creative *per catalog item* using the buyer-supplied catalog feed. Without a catalog feed there is nothing to render against. Buyer agents reading `format_kind: sponsored_placement` MUST attach a catalog reference; sellers MUST require `source_catalog` in the manifest.\n\n**Not this canonical (route elsewhere):**\n- IAB in-feed native ads, content-recommendation widgets (Taboola, Outbrain, Yahoo Native, AdMob Native, in-feed sponsored cards) — use `native_in_feed` (asset-bundle composition; no catalog).\n- Algorithmic surface that picks from a buyer-supplied asset pool (Google PMax, Meta Advantage+) — use `responsive_creative`.\n- Single-image or single-video creative — use `image` or `video_hosted`.\n\nThe earlier broader framing ('any sponsored placement') was too loose for buyer-agent routing — a buyer reading `sponsored_placement` couldn't disambiguate a catalog-driven Amazon SP from an in-feed Taboola widget. As of 3.1, the canonical is narrowed to catalog-keyed retail-media; native moves to `native_in_feed`. Distinct from `responsive_creative` (algorithmic combinator from buyer pool) and `agent_placement` (text/audio AI-surface composition).",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     }
   ],
   "properties": {

package/dist/lib/schemas-data/3.1/formats/canonical/video_hosted.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/video_hosted.json",
+  "$id": "/schemas/3.1.5/formats/canonical/video_hosted.json",
   "title": "Canonical Format: Hosted Video",
   "description": "Direct video file (mp4/webm/mov) hosted by the buyer. Slot: `video_main` (video asset, file or hosted URL), optional `headline`, `brand_name`, `cta`, `companion_banner`, `landing_page_url`. Tracking model: IAB Open Measurement SDK + external impression/click/quartile pixels via universal_macros. Orientation is a parameter (vertical 9:16 / horizontal 16:9 / square 1:1); slot shape includes optional `brand_name` (typical for vertical short-form) and optional `companion_banner` (typical for horizontal instream). Distinct from `video_vast` (VAST tag, inherent VAST event tracking) — receivers fire impression and click pixels at delivery time.",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     }
   ],
   "properties": {

package/dist/lib/schemas-data/3.1/formats/canonical/video_vast.json

@@ -1,11 +1,11 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/formats/canonical/video_vast.json",
+  "$id": "/schemas/3.1.5/formats/canonical/video_vast.json",
   "title": "Canonical Format: VAST Video",
   "description": "VAST-tag-delivered video creative. Slot: `vast_tag` (vast asset, URL or inline XML, VAST 2.x-4.x). Tracking model: VAST events inherent to the spec — `impression`, `firstQuartile`, `midpoint`, `thirdQuartile`, `complete`, `start`, `pause`, `resume`, `mute`, `unmute`, `expand`, `collapse`, `fullscreen`, `creativeView`, `clickTracking`, `error`. VPAID interactivity via `vpaid_enabled: true` flag. SIMID extensions for interactive video supported as VAST extensions. Orientation is a parameter (vertical / horizontal / square). Distinct from `video_hosted` (direct file with external tracking).",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/formats/canonical/_base.json"
+      "$ref": "/schemas/3.1.5/formats/canonical/_base.json"
     }
   ],
   "properties": {

package/dist/lib/schemas-data/3.1/governance/attribute-definition.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/governance/attribute-definition.json",
+  "$id": "/schemas/3.1.5/governance/attribute-definition.json",
   "title": "Attribute Definition",
   "description": "Definition of a restricted personal data attribute in the policy registry. Attributes are the shared vocabulary used across campaign plans (restricted_attributes), signal definitions (restricted_attributes), and data marketplace catalogs. Each definition documents the regulatory basis, scope, and common signal patterns for the attribute category.",
   "type": "object",

package/dist/lib/schemas-data/3.1/governance/audience-constraints.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/governance/audience-constraints.json",
+  "$id": "/schemas/3.1.5/governance/audience-constraints.json",
   "title": "Audience Constraints",
   "description": "Buyer-defined audience targeting constraints for a campaign plan. Specifies who the campaign should and should not reach. The governance agent evaluates seller targeting against these constraints during check_governance.",
   "type": "object",
@@ -9,7 +9,7 @@
       "type": "array",
       "description": "Desired audience criteria. The seller's targeting should align with these. Each criterion is evaluated independently — the combined targeting should satisfy at least one inclusion criterion.",
       "items": {
-        "$ref": "/schemas/3.1.2/core/audience-selector.json"
+        "$ref": "/schemas/3.1.5/core/audience-selector.json"
       },
       "minItems": 1
     },
@@ -17,7 +17,7 @@
       "type": "array",
       "description": "Excluded audience criteria. The seller's targeting must not overlap with these. Exclusions take precedence over inclusions. Used for protected groups, vulnerable communities, regulatory restrictions, or brand safety.",
       "items": {
-        "$ref": "/schemas/3.1.2/core/audience-selector.json"
+        "$ref": "/schemas/3.1.5/core/audience-selector.json"
       },
       "minItems": 1
     }

package/dist/lib/schemas-data/3.1/governance/check-governance-request.json

@@ -1,12 +1,12 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/governance/check-governance-request.json",
+  "$id": "/schemas/3.1.5/governance/check-governance-request.json",
   "title": "Check Governance Request",
   "description": "Universal governance check for campaign actions. The governance agent infers the check type from the fields present: tool+payload = intent check (proposed, orchestrator-side). planned_delivery = execution check (committed, seller-side). governance_context maintains lifecycle continuity across either check type — its presence alone does not determine binding. To check budget availability without a specific action, omit tool and payload.",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/core/version-envelope.json"
+      "$ref": "/schemas/3.1.5/core/version-envelope.json"
     }
   ],
   "x-status": "experimental",
@@ -22,7 +22,7 @@
       "description": "URL of the agent making the request."
     },
     "purchase_type": {
-      "$ref": "/schemas/3.1.2/enums/purchase-type.json",
+      "$ref": "/schemas/3.1.5/enums/purchase-type.json",
       "description": "The type of financial commitment being checked. Determines which budget allocation (if any) to validate against. Defaults to 'media_buy' when omitted.",
       "default": "media_buy"
     },
@@ -44,12 +44,12 @@
       "pattern": "^[\\x20-\\x7E]+$"
     },
     "phase": {
-      "$ref": "/schemas/3.1.2/enums/governance-phase.json",
+      "$ref": "/schemas/3.1.5/enums/governance-phase.json",
       "description": "The phase of the governed action's lifecycle. 'purchase': initial commitment (create_media_buy, acquire_rights, activate_signal). 'modification': update to existing commitment. 'delivery': periodic delivery or usage reporting. Defaults to 'purchase' if omitted.",
       "default": "purchase"
     },
     "planned_delivery": {
-      "$ref": "/schemas/3.1.2/core/planned-delivery.json",
+      "$ref": "/schemas/3.1.5/core/planned-delivery.json",
       "description": "What the seller will actually deliver. Present on execution checks."
     },
     "delivery_metrics": {
@@ -180,14 +180,14 @@
       "maxLength": 1000
     },
     "invoice_recipient": {
-      "$ref": "/schemas/3.1.2/core/business-entity.json",
+      "$ref": "/schemas/3.1.5/core/business-entity.json",
       "description": "Invoice recipient from the purchase request. MUST be present when the tool payload includes invoice_recipient, so the governance agent can validate billing changes."
     },
     "context": {
-      "$ref": "/schemas/3.1.2/core/context.json"
+      "$ref": "/schemas/3.1.5/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.2/core/ext.json"
+      "$ref": "/schemas/3.1.5/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/governance/check-governance-response.json

@@ -1,12 +1,12 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/governance/check-governance-response.json",
+  "$id": "/schemas/3.1.5/governance/check-governance-response.json",
   "title": "Check Governance Response",
   "description": "Governance agent's response to a check request. Returns whether the action is approved under the governance plan.",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/core/version-envelope.json"
+      "$ref": "/schemas/3.1.5/core/version-envelope.json"
     },
     {
       "if": {
@@ -81,7 +81,7 @@
       "x-entity": "governance_check"
     },
     "verdict": {
-      "$ref": "/schemas/3.1.2/enums/governance-decision.json",
+      "$ref": "/schemas/3.1.5/enums/governance-decision.json",
       "description": "Governance verdict: approved | denied | conditions. Renamed from `status` in 3.1 to free the top-level `status` key for the envelope task-status (TaskStatus) under MCP flat-on-the-wire serialization. The enum values are unchanged; only the property name moved."
     },
     "plan_id": {
@@ -114,7 +114,7 @@
             "x-entity": "governance_plan"
           },
           "severity": {
-            "$ref": "/schemas/3.1.2/enums/escalation-severity.json"
+            "$ref": "/schemas/3.1.5/enums/escalation-severity.json"
           },
           "explanation": {
             "type": "string",
@@ -194,7 +194,7 @@
       "description": "Policy IDs evaluated during this check. Includes registry policy IDs (resolved via the policy registry) and any inline `policy_id`s declared in the plan's `custom_policies`."
     },
     "mode": {
-      "$ref": "/schemas/3.1.2/enums/governance-mode.json",
+      "$ref": "/schemas/3.1.5/enums/governance-mode.json",
       "description": "Governance enforcement mode active when this check was evaluated. Allows counterparties, regulators, and auditors to distinguish whether a finding blocked execution (enforce) or was logged silently (audit)."
     },
     "governance_context": {
@@ -205,10 +205,10 @@
       "pattern": "^[\\x20-\\x7E]+$"
     },
     "context": {
-      "$ref": "/schemas/3.1.2/core/context.json"
+      "$ref": "/schemas/3.1.5/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.2/core/ext.json"
+      "$ref": "/schemas/3.1.5/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/governance/get-plan-audit-logs-request.json

@@ -1,12 +1,12 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/governance/get-plan-audit-logs-request.json",
+  "$id": "/schemas/3.1.5/governance/get-plan-audit-logs-request.json",
   "title": "Get Plan Audit Logs Request",
   "description": "Retrieve governance state and audit trail for one or more plans.",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/core/version-envelope.json"
+      "$ref": "/schemas/3.1.5/core/version-envelope.json"
     }
   ],
   "x-status": "experimental",
@@ -40,7 +40,7 @@
     "purchase_types": {
       "type": "array",
       "items": {
-        "$ref": "/schemas/3.1.2/enums/purchase-type.json"
+        "$ref": "/schemas/3.1.5/enums/purchase-type.json"
       },
       "minItems": 1,
       "description": "Filter audit entries by purchase type. Returns only checks and outcomes matching these purchase types (e.g., ['rights_license'] to see all rights activity)."
@@ -51,10 +51,10 @@
       "default": false
     },
     "context": {
-      "$ref": "/schemas/3.1.2/core/context.json"
+      "$ref": "/schemas/3.1.5/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.2/core/ext.json"
+      "$ref": "/schemas/3.1.5/core/ext.json"
     }
   },
   "anyOf": [

package/dist/lib/schemas-data/3.1/governance/get-plan-audit-logs-response.json

@@ -1,15 +1,15 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/governance/get-plan-audit-logs-response.json",
+  "$id": "/schemas/3.1.5/governance/get-plan-audit-logs-response.json",
   "title": "Get Plan Audit Logs Response",
   "description": "Governance state and audit trail for one or more plans.",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.2/core/version-envelope.json"
+      "$ref": "/schemas/3.1.5/core/version-envelope.json"
     },
     {
-      "$ref": "/schemas/3.1.2/core/protocol-envelope.json"
+      "$ref": "/schemas/3.1.5/core/protocol-envelope.json"
     }
   ],
   "x-status": "experimental",
@@ -259,7 +259,7 @@
                   "description": "The AdCP tool (present for check entries)."
                 },
                 "verdict": {
-                  "$ref": "/schemas/3.1.2/enums/governance-decision.json",
+                  "$ref": "/schemas/3.1.5/enums/governance-decision.json",
                   "description": "Governance verdict (present for check entries). Renamed from `status` in 3.1 alongside check-governance-response for vocabulary consistency."
                 },
                 "check_type": {
@@ -271,7 +271,7 @@
                   "description": "Whether the check was an intent check (orchestrator) or execution check (seller). Inferred from the fields present on the original check request. Present for check entries."
                 },
                 "mode": {
-                  "$ref": "/schemas/3.1.2/enums/governance-mode.json",
+                  "$ref": "/schemas/3.1.5/enums/governance-mode.json",
                   "description": "Governance mode active at the moment this specific check was evaluated. Governance agents SHOULD populate this field on check entries, recording the mode from their runtime configuration at the moment check_governance was processed — not derived from a plan field. This is a per-check value: if the operator changes mode between checks for the same governed action, each entry records the mode active for that entry. A future `governed_actions[].mode` field would describe the action's current mode, which may differ from the most recent entry's `mode` if the plan has since been re-synced. Absent for outcome entries and for pre-3.1 governance agents that do not surface mode on audit responses."
                 },
                 "explanation": {
@@ -306,7 +306,7 @@
                         "$comment": "x-entity deliberately omitted — audit log findings mirror check_governance findings and can reference either a governance_registry_policy or a governance_inline_policy (see #2685)."
                       },
                       "severity": {
-                        "$ref": "/schemas/3.1.2/enums/escalation-severity.json"
+                        "$ref": "/schemas/3.1.5/enums/escalation-severity.json"
                       },
                       "explanation": {
                         "type": "string"
@@ -326,7 +326,7 @@
                   }
                 },
                 "outcome": {
-                  "$ref": "/schemas/3.1.2/enums/outcome-type.json",
+                  "$ref": "/schemas/3.1.5/enums/outcome-type.json",
                   "description": "Outcome type (present for outcome entries)."
                 },
                 "committed_budget": {
@@ -343,7 +343,7 @@
                   "description": "Audit-layer binding to the plan revision this attestation was evaluated over — base64url_no_pad(SHA-256(JCS(plan_payload))) per Plan binding and audit in the campaign-governance specification. Present on check entries. Auditors and buyer-side compliance verify by recomputing over the retained plan revision and byte-comparing the decoded 32-byte digests."
                 },
                 "purchase_type": {
-                  "$ref": "/schemas/3.1.2/enums/purchase-type.json",
+                  "$ref": "/schemas/3.1.5/enums/purchase-type.json",
                   "description": "Purchase type for this entry."
                 },
                 "outcome_status": {
@@ -370,7 +370,7 @@
                   "description": "Governance context correlating this action's lifecycle."
                 },
                 "purchase_type": {
-                  "$ref": "/schemas/3.1.2/enums/purchase-type.json",
+                  "$ref": "/schemas/3.1.5/enums/purchase-type.json",
                   "description": "Type of financial commitment."
                 },
                 "status": {
@@ -418,10 +418,10 @@
       }
     },
     "context": {
-      "$ref": "/schemas/3.1.2/core/context.json"
+      "$ref": "/schemas/3.1.5/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.2/core/ext.json"
+      "$ref": "/schemas/3.1.5/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/governance/policy-category-definition.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/governance/policy-category-definition.json",
+  "$id": "/schemas/3.1.5/governance/policy-category-definition.json",
   "title": "Policy Category Definition",
   "description": "Definition of a policy category in the registry. Policy categories group related regulatory regimes (e.g., 'children_directed' groups COPPA, UK AADC, GDPR Article 8). Used on campaign plans (plan.policy_categories), signal definitions (signal-definition.policy_categories), and policy entries (policy-entry.policy_categories) to connect campaigns and data to the right regulatory frameworks.",
   "type": "object",
@@ -59,7 +59,7 @@
       "type": "array",
       "description": "Restricted attribute categories that regulations in this category prohibit for targeting. Governance agents enforce these when the category is active on a plan — if a plan declares policy_categories: ['fair_housing'], the governance agent restricts targeting on these attributes.",
       "items": {
-        "$ref": "/schemas/3.1.2/enums/restricted-attribute.json"
+        "$ref": "/schemas/3.1.5/enums/restricted-attribute.json"
       }
     },
     "requires_human_review": {

package/dist/lib/schemas-data/3.1/governance/policy-entry.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/governance/policy-entry.json",
+  "$id": "/schemas/3.1.5/governance/policy-entry.json",
   "title": "Policy Entry",
   "description": "A policy — either published to the shared registry (with full regulatory metadata) or authored inline by a buyer for their own campaign (lightweight, metadata optional). Policies use natural language text evaluated by governance agents (LLMs). Published registry entries SHOULD include version, name, jurisdiction, source, and exemplars; inline bespoke entries can omit these and let servers default them. Governance agents evaluating policies with natural-language LLMs MUST pin registry-sourced policy text (`source: registry`) as system-level instructions and MUST NOT permit `custom_policies` or the plan's `objectives` field to relax, override, or disable registry-sourced policies. Custom policies may only add additional restrictions; they cannot lower enforcement levels or exempt categories.",
   "type": "object",
@@ -33,11 +33,11 @@
       "description": "Brief summary of what this policy covers."
     },
     "category": {
-      "$ref": "/schemas/3.1.2/enums/policy-category.json",
+      "$ref": "/schemas/3.1.5/enums/policy-category.json",
       "description": "The nature of the obligation: regulation (legal requirement) or standard (best practice). Optional for inline bespoke policies — defaults to \"standard\"."
     },
     "enforcement": {
-      "$ref": "/schemas/3.1.2/enums/policy-enforcement.json",
+      "$ref": "/schemas/3.1.5/enums/policy-enforcement.json",
       "description": "How governance agents treat violations. Regulations are typically \"must\"; standards are typically \"should\"."
     },
     "requires_human_review": {
@@ -72,14 +72,14 @@
     "channels": {
       "type": "array",
       "items": {
-        "$ref": "/schemas/3.1.2/enums/channels.json"
+        "$ref": "/schemas/3.1.5/enums/channels.json"
       },
       "description": "Advertising channels this policy applies to. If omitted or null, the policy applies to all channels."
     },
     "governance_domains": {
       "type": "array",
       "items": {
-        "$ref": "/schemas/3.1.2/enums/governance-domain.json"
+        "$ref": "/schemas/3.1.5/enums/governance-domain.json"
       },
       "description": "Governance sub-domains this policy applies to. Determines which types of governance agents can declare registry:{policy_id} features. For example, a policy with domains [\"creative\", \"property\"] can be declared as a feature by both creative and property governance agents."
     },
@@ -133,7 +133,7 @@
       "additionalProperties": false
     },
     "ext": {
-      "$ref": "/schemas/3.1.2/core/ext.json"
+      "$ref": "/schemas/3.1.5/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/governance/policy-ref.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/governance/policy-ref.json",
+  "$id": "/schemas/3.1.5/governance/policy-ref.json",
   "title": "Policy Reference",
   "description": "A reference to a policy in the policy registry. Used in brand compliance configurations to declare which registry policies apply.",
   "type": "object",