@adcp/sdk 12.0.6 → 12.1.1

package/dist/lib/schemas-data/3.1/bundled/creative/validate-input-request.json

@@ -1,8 +1,8 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/bundled/creative/validate-input-request.json",
+  "$id": "/schemas/3.1.5/bundled/creative/validate-input-request.json",
   "title": "Validate Input Request",
-  "description": "Request payload for the validate_input task. Lets buyers dry-run a creative manifest against canonical formats and/or specific products before committing to a render. Cheaper than preview_creative (no synthesis cost). Used by build_creative internally to validate inputs before producing output. For genuinely nondeterministic generative platforms (Veo/Sora/Runway-class) where predictive validation is impossible, the platform's own post-synthesis QA loop applies — validate_input is the predictable-case primitive.\n\nThe `targets[]` array is a discriminated list of validation targets, mirroring the response shape on `validate-input-result.json#target`. Each entry has a `kind` (canonical | product | third_party_format) plus a kind-specific identifier. Discriminated-by-kind on both sides eliminates a wire-shape mismatch: a previous draft used `format_ids: string[]` for canonical names alongside `product_ids: string[]`, which collided with `Product.format_ids: FormatId[]` ({agent_url, id}) — codegen would emit the same field name with two different types. Discriminated `targets[]` makes the intent explicit and codegen-clean.",
+  "description": "Request payload for the validate_input task. Lets buyers preflight a creative manifest against canonical formats and/or specific products before committing to a render or other expensive creative-production step. It validates manifest structure and target format constraints only: slot counts, asset types, parameter ranges, and format-shape constraints. It does not rehearse a seller's library mutation, creative_id upsert semantics, package assignments, account authorization, active-delivery protections, or other trafficking-time gates. When the question is final seller acceptance for a creative that is ready to traffic, call sync_creatives directly; use dry_run: true for a non-mutating rehearsal of that operation. Used by build_creative internally to validate inputs before producing output. For genuinely nondeterministic generative platforms (Veo/Sora/Runway-class) where predictive validation is impossible, the platform's own post-synthesis QA loop applies — validate_input is the predictable-case primitive.\n\nThe `targets[]` array is a discriminated list of validation targets, mirroring the response shape on `validate-input-result.json#target`. Each entry has a `kind` (canonical | product | third_party_format) plus a kind-specific identifier. Discriminated-by-kind on both sides eliminates a wire-shape mismatch: a previous draft used `format_ids: string[]` for canonical names alongside `product_ids: string[]`, which collided with `Product.format_ids: FormatId[]` ({agent_url, id}) — codegen would emit the same field name with two different types. Discriminated `targets[]` makes the intent explicit and codegen-clean.",
   "type": "object",
   "required": [
     "manifest"
@@ -51,7 +51,7 @@
                     "nike",
                     "pampers"
                   ],
-                  "$id": "/schemas/3.1.2/core/brand-id.json"
+                  "$id": "/schemas/3.1.5/core/brand-id.json"
                 },
                 "industries": {
                   "type": "array",
@@ -396,7 +396,7 @@
                                             "description": "Extension object for platform-specific, vendor-namespaced parameters. Extensions are always optional and must be namespaced under a vendor/platform key (e.g., ext.gam, ext.roku). Used for custom capabilities, partner-specific configuration, and features being proposed for standardization.",
                                             "type": "object",
                                             "additionalProperties": true,
-                                            "$id": "/schemas/3.1.2/core/ext.json"
+                                            "$id": "/schemas/3.1.5/core/ext.json"
                                           }
                                         },
                                         "additionalProperties": true
@@ -1121,7 +1121,7 @@
               "width"
             ]
           },
-          "$id": "/schemas/3.1.2/core/format-id.json"
+          "$id": "/schemas/3.1.5/core/format-id.json"
         },
         "format_kind": {
           "title": "Canonical Format Kind",
@@ -1142,7 +1142,7 @@
             "agent_placement",
             "custom"
           ],
-          "$id": "/schemas/3.1.2/core/canonical-format-kind.json"
+          "$id": "/schemas/3.1.5/core/canonical-format-kind.json"
         },
         "format_option_ref": {
           "title": "Format Option Reference",
@@ -1203,7 +1203,7 @@
             }
           ],
           "additionalProperties": true,
-          "$id": "/schemas/3.1.2/core/format-option-ref.json"
+          "$id": "/schemas/3.1.5/core/format-option-ref.json"
         },
         "assets": {
           "type": "object",
@@ -6216,7 +6216,7 @@
                                   "role"
                                 ],
                                 "additionalProperties": true,
-                                "$id": "/schemas/3.1.2/core/reference-asset.json"
+                                "$id": "/schemas/3.1.5/core/reference-asset.json"
                               }
                             },
                             "compliance": {
@@ -6531,7 +6531,7 @@
                                     }
                                   }
                                 ],
-                                "$id": "/schemas/3.1.2/core/catalog-field-mapping.json"
+                                "$id": "/schemas/3.1.5/core/catalog-field-mapping.json"
                               },
                               "minItems": 1
                             }
@@ -8431,7 +8431,7 @@
                                 "digest": "sha256:a3f5b7c9d8e2f1a4b6c8d0e2f4a6b8c0d2e4f6a8b0c2d4e6f8a0b2c4d6e8f0a2"
                               }
                             ],
-                            "$id": "/schemas/3.1.2/core/platform-extension-ref.json"
+                            "$id": "/schemas/3.1.5/core/platform-extension-ref.json"
                           }
                         },
                         "provenance": {
@@ -19496,7 +19496,7 @@
                     "commercial": "Use in commercial advertising and promotional contexts",
                     "ai_generated_image": "License to produce AI-generated still imagery derived from the rights holder's IP (brand assets, character designs, talent likeness). Distinct from likeness/voice by output modality — a get_rights query filtered on ai_generated_image returns rights whose pricing options cover image generation, regardless of the underlying IP category."
                   },
-                  "$id": "/schemas/3.1.2/enums/right-use.json"
+                  "$id": "/schemas/3.1.5/enums/right-use.json"
                 },
                 "minItems": 1
               },
@@ -19540,7 +19540,7 @@
                   "music": "Rights to musical compositions or recordings (sync, background music)",
                   "stock_media": "Rights to stock photography, video, or audio collections"
                 },
-                "$id": "/schemas/3.1.2/enums/right-type.json"
+                "$id": "/schemas/3.1.5/enums/right-type.json"
               },
               "approval_status": {
                 "type": "string",
@@ -19569,7 +19569,7 @@
               "uses"
             ],
             "additionalProperties": true,
-            "$id": "/schemas/3.1.2/core/rights-constraint.json"
+            "$id": "/schemas/3.1.5/core/rights-constraint.json"
           }
         },
         "industry_identifiers": {
@@ -19602,7 +19602,7 @@
                   "clearcast_clock",
                   "idcrea"
                 ],
-                "$id": "/schemas/3.1.2/enums/creative-identifier-type.json"
+                "$id": "/schemas/3.1.5/enums/creative-identifier-type.json"
               },
               "value": {
                 "type": "string",
@@ -19615,7 +19615,7 @@
               "value"
             ],
             "additionalProperties": true,
-            "$id": "/schemas/3.1.2/core/industry-identifier.json"
+            "$id": "/schemas/3.1.5/core/industry-identifier.json"
           },
           "uniqueItems": true
         },
@@ -20082,7 +20082,7 @@
   "additionalProperties": true,
   "examples": [
     {
-      "description": "Dry-run a video manifest against canonical video_hosted and a specific Meta product in one round-trip",
+      "description": "Preflight a video manifest against canonical video_hosted and a specific Meta product in one round-trip",
       "data": {
         "manifest": {
           "format_kind": "video_hosted",
@@ -20139,7 +20139,7 @@
         "human_edits": "Content augmented, corrected, or enhanced by humans using non-generative tools",
         "data_driven_media": "Assembled from structured data feeds (DCO templates, product catalogs, weather-triggered variants)"
       },
-      "$id": "/schemas/3.1.2/enums/digital-source-type.json"
+      "$id": "/schemas/3.1.5/enums/digital-source-type.json"
     },
     "EmbeddedProvenanceMethod": {
       "title": "Embedded Provenance Method",
@@ -20153,7 +20153,7 @@
         "manifest_wrapper": "A provenance manifest embedded in the file container per format-specific rules (e.g., JUMBF box in JPEG, C2PATextManifestWrapper in plaintext per C2PA Section A.7). The manifest travels with the file but is tied to the file's byte structure.",
         "provenance_markers": "Invisible markers embedded within the content stream that encode or reference a provenance record. Designed to survive reformatting, copy-paste, CMS ingestion, and ad-server transcoding that breaks file-level bindings."
       },
-      "$id": "/schemas/3.1.2/enums/embedded-provenance-method.json"
+      "$id": "/schemas/3.1.5/enums/embedded-provenance-method.json"
     },
     "WatermarkMediaType": {
       "title": "Watermark Media Type",
@@ -20171,7 +20171,7 @@
         "video": "Watermark applied to video content (e.g., per-frame image watermarking, temporal watermarking)",
         "text": "Watermark applied to text content (e.g., synonym substitution, structural modification)"
       },
-      "$id": "/schemas/3.1.2/enums/watermark-media-type.json"
+      "$id": "/schemas/3.1.5/enums/watermark-media-type.json"
     },
     "C2PAWatermarkAction": {
       "title": "C2PA Watermark Action",
@@ -20185,7 +20185,7 @@
         "c2pa.watermarked.bound": "Watermark linked to a C2PA manifest for this asset. The watermark and manifest are mutually reinforcing: the manifest references the watermark, and the watermark can be used to locate the manifest.",
         "c2pa.watermarked.unbound": "Watermark independent of any C2PA manifest. Applied before any provenance signing event (e.g., by the AI generator at creation time) or in pipelines where no manifest is present."
       },
-      "$id": "/schemas/3.1.2/enums/c2pa-watermark-action.json"
+      "$id": "/schemas/3.1.5/enums/c2pa-watermark-action.json"
     },
     "DisclosurePersistence": {
       "title": "Disclosure Persistence",
@@ -20201,7 +20201,7 @@
         "initial": "Disclosure must appear at the start of content for a minimum duration before it may be removed. Pair with min_duration_ms in render_guidance or creative brief to specify the required duration.",
         "flexible": "Disclosure presence is sufficient; placement timing and duration are at the publisher's discretion"
       },
-      "$id": "/schemas/3.1.2/enums/disclosure-persistence.json"
+      "$id": "/schemas/3.1.5/enums/disclosure-persistence.json"
     },
     "DisclosurePosition": {
       "title": "Disclosure Position",
@@ -20217,7 +20217,7 @@
         "pre_roll",
         "companion"
       ],
-      "$id": "/schemas/3.1.2/enums/disclosure-position.json"
+      "$id": "/schemas/3.1.5/enums/disclosure-position.json"
     },
     "FrameRateType": {
       "title": "Frame Rate Type",
@@ -20231,7 +20231,7 @@
         "constant": "Constant frame rate (CFR) — each frame occupies an identical time interval",
         "variable": "Variable frame rate (VFR) — frame intervals may differ"
       },
-      "$id": "/schemas/3.1.2/enums/frame-rate-type.json"
+      "$id": "/schemas/3.1.5/enums/frame-rate-type.json"
     },
     "ScanType": {
       "title": "Scan Type",
@@ -20245,7 +20245,7 @@
         "progressive": "All lines of each frame are drawn in sequence",
         "interlaced": "Alternating lines drawn in two passes per frame (legacy broadcast)"
       },
-      "$id": "/schemas/3.1.2/enums/scan-type.json"
+      "$id": "/schemas/3.1.5/enums/scan-type.json"
     },
     "GOPType": {
       "title": "GOP Type",
@@ -20259,7 +20259,7 @@
         "closed": "Each GOP is independently decodable — required for SSAI and broadcast splicing",
         "open": "GOPs may reference frames from adjacent GOPs — not suitable for splicing"
       },
-      "$id": "/schemas/3.1.2/enums/gop-type.json"
+      "$id": "/schemas/3.1.5/enums/gop-type.json"
     },
     "MoovAtomPosition": {
       "title": "Moov Atom Position",
@@ -20273,7 +20273,7 @@
         "start": "moov atom at beginning of file — enables progressive download and streaming delivery",
         "end": "moov atom at end of file — requires full download before playback can begin"
       },
-      "$id": "/schemas/3.1.2/enums/moov-atom-position.json"
+      "$id": "/schemas/3.1.5/enums/moov-atom-position.json"
     },
     "AudioChannelLayout": {
       "title": "Audio Channel Layout",
@@ -20285,7 +20285,7 @@
         "5.1",
         "7.1"
       ],
-      "$id": "/schemas/3.1.2/enums/audio-channel-layout.json"
+      "$id": "/schemas/3.1.5/enums/audio-channel-layout.json"
     },
     "VASTVersion": {
       "title": "VAST Version",
@@ -20298,7 +20298,7 @@
         "4.1",
         "4.2"
       ],
-      "$id": "/schemas/3.1.2/enums/vast-version.json"
+      "$id": "/schemas/3.1.5/enums/vast-version.json"
     },
     "VASTTrackingEvent": {
       "title": "VAST Tracking Event",
@@ -20342,7 +20342,7 @@
         "measurableImpression",
         "viewableImpression"
       ],
-      "$id": "/schemas/3.1.2/enums/vast-tracking-event.json"
+      "$id": "/schemas/3.1.5/enums/vast-tracking-event.json"
     },
     "URLAssetType": {
       "title": "URL Asset Type",
@@ -20353,7 +20353,7 @@
         "tracker_pixel",
         "tracker_script"
       ],
-      "$id": "/schemas/3.1.2/enums/url-asset-type.json"
+      "$id": "/schemas/3.1.5/enums/url-asset-type.json"
     },
     "JavaScriptModuleType": {
       "title": "JavaScript Module Type",
@@ -20364,7 +20364,7 @@
         "commonjs",
         "script"
       ],
-      "$id": "/schemas/3.1.2/enums/javascript-module-type.json"
+      "$id": "/schemas/3.1.5/enums/javascript-module-type.json"
     },
     "HTTPMethod": {
       "title": "HTTP Method",
@@ -20374,7 +20374,7 @@
         "GET",
         "POST"
       ],
-      "$id": "/schemas/3.1.2/enums/http-method.json",
+      "$id": "/schemas/3.1.5/enums/http-method.json",
       "default": "POST"
     },
     "UniversalMacro": {
@@ -20535,7 +20535,7 @@
         "ITEM_PRICE": "Price amount of the catalog item being rendered (catalog_field: price.amount). Catalog content macro — scalar text value substituted under the catalog-item substitution-safety rules.",
         "ITEM_PRICE_CURRENCY": "ISO 4217 currency code of the catalog item being rendered (catalog_field: price.currency). Catalog content macro — scalar text value substituted under the catalog-item substitution-safety rules."
       },
-      "$id": "/schemas/3.1.2/enums/universal-macro.json"
+      "$id": "/schemas/3.1.5/enums/universal-macro.json"
     },
     "WebhookResponseType": {
       "title": "Webhook Response Type",
@@ -20547,7 +20547,7 @@
         "xml",
         "javascript"
       ],
-      "$id": "/schemas/3.1.2/enums/webhook-response-type.json"
+      "$id": "/schemas/3.1.5/enums/webhook-response-type.json"
     },
     "WebhookSecurityMethod": {
       "title": "Webhook Security Method",
@@ -20558,7 +20558,7 @@
         "api_key",
         "none"
       ],
-      "$id": "/schemas/3.1.2/enums/webhook-security-method.json"
+      "$id": "/schemas/3.1.5/enums/webhook-security-method.json"
     },
     "DAASTVersion": {
       "title": "DAAST Version",
@@ -20568,7 +20568,7 @@
         "1.0",
         "1.1"
       ],
-      "$id": "/schemas/3.1.2/enums/daast-version.json"
+      "$id": "/schemas/3.1.5/enums/daast-version.json"
     },
     "DAASTTrackingEvent": {
       "title": "DAAST Tracking Event",
@@ -20599,7 +20599,7 @@
         "measurableImpression",
         "viewableImpression"
       ],
-      "$id": "/schemas/3.1.2/enums/daast-tracking-event.json"
+      "$id": "/schemas/3.1.5/enums/daast-tracking-event.json"
     },
     "MarkdownFlavor": {
       "title": "Markdown Flavor",
@@ -20609,7 +20609,7 @@
         "commonmark",
         "gfm"
       ],
-      "$id": "/schemas/3.1.2/enums/markdown-flavor.json",
+      "$id": "/schemas/3.1.5/enums/markdown-flavor.json",
       "default": "commonmark"
     },
     "CatalogType": {
@@ -20631,7 +20631,7 @@
         "destination",
         "app"
       ],
-      "$id": "/schemas/3.1.2/enums/catalog-type.json"
+      "$id": "/schemas/3.1.5/enums/catalog-type.json"
     },
     "FeedFormat": {
       "title": "Feed Format",
@@ -20657,7 +20657,7 @@
         "openai_product_feed": "OpenAI Commerce product feed for ChatGPT shopping — a GMC-derived dialect adding ChatGPT-specific eligibility flags (is_eligible_search / is_eligible_checkout / is_eligible_ads). Spec: https://developers.openai.com/commerce/specs/file-upload/products",
         "custom": "A feed whose shape is not one of the named formats above. The buyer MUST supply feed_field_mappings to normalize it to the AdCP catalog item schema."
       },
-      "$id": "/schemas/3.1.2/enums/feed-format.json"
+      "$id": "/schemas/3.1.5/enums/feed-format.json"
     },
     "UpdateFrequency": {
       "title": "Update Frequency",
@@ -20669,7 +20669,7 @@
         "daily",
         "weekly"
       ],
-      "$id": "/schemas/3.1.2/enums/update-frequency.json"
+      "$id": "/schemas/3.1.5/enums/update-frequency.json"
     },
     "EventType": {
       "title": "Event Type",
@@ -20741,7 +20741,7 @@
         "submit_application": "User submitted an application (loan, job, etc.)",
         "custom": "Custom event type (specify in custom_event_name)"
       },
-      "$id": "/schemas/3.1.2/enums/event-type.json"
+      "$id": "/schemas/3.1.5/enums/event-type.json"
     },
     "ContentIDType": {
       "title": "Content ID Type",
@@ -20761,11 +20761,11 @@
         "destination_id",
         "app_id"
       ],
-      "$id": "/schemas/3.1.2/enums/content-id-type.json"
+      "$id": "/schemas/3.1.5/enums/content-id-type.json"
     }
   },
   "_bundled": {
-    "generatedAt": "2026-07-08T13:55:48.678Z",
+    "generatedAt": "2026-07-24T14:33:01.856Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.1/bundled/creative/validate-input-response.json

@@ -1,8 +1,8 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.2/bundled/creative/validate-input-response.json",
+  "$id": "/schemas/3.1.5/bundled/creative/validate-input-response.json",
   "title": "Validate Input Response",
-  "description": "Response payload for the validate_input task. Returns per-target validation results — one entry per format_id or product_id requested. Each result carries a `result_kind` discriminator (`validated_pass` / `validated_fail` / `unvalidatable_nondeterministic`) so callers can branch on three meaningfully different outcomes. The `predicted` field on violations carries the platform's pre-flight estimate (e.g., predicted audio duration from text-length analysis), NOT the actual output — there is no protocol state for orphaned out-of-spec artifacts. For nondeterministic generative platforms (Veo / Sora / Runway-class with `synthesis_nondeterministic: true`), the result_kind is `unvalidatable_nondeterministic` — predictive validation is impossible, the platform's post-synthesis QA loop applies on `build_creative`, and out-of-spec output never reaches this surface (instead `build_creative` returns task_failed with synthesis_failed reason).\n\nThe `ValidateInputResult` type is split into its own schema (`/schemas/creative/validate-input-result.json`) rather than inlined here because the same per-target shape is intended for reuse by adjacent async-validation surfaces (planned: per-batch result envelopes on `build_creative` async paths, and asynchronous canonical-against-product validation in `sync_creatives`). Producers that only need the synchronous batch shape today MAY treat the split as YAGNI, but the schema reuse anchors the violation/retry shape so downstream surfaces don't drift.",
+  "description": "Response payload for the validate_input task. Returns per-target manifest validation results — one entry per canonical, product, or third-party target requested. Each result carries a `result_kind` discriminator (`validated_pass` / `validated_fail` / `unvalidatable_nondeterministic`) so callers can branch on three meaningfully different outcomes. A pass means the manifest is structurally valid for that target; it does not mean a later sync_creatives call will be accepted, because trafficking-time gates such as account authorization, creative_id upsert state, package assignments, active-delivery protections, and seller review policy are outside validate_input's scope. The `predicted` field on violations carries the platform's pre-flight estimate (e.g., predicted audio duration from text-length analysis), NOT the actual output — there is no protocol state for orphaned out-of-spec artifacts. For nondeterministic generative platforms (Veo / Sora / Runway-class with `synthesis_nondeterministic: true`), the result_kind is `unvalidatable_nondeterministic` — predictive validation is impossible, the platform's post-synthesis QA loop applies on `build_creative`, and out-of-spec output never reaches this surface (instead `build_creative` returns task_failed with synthesis_failed reason).\n\nThe `ValidateInputResult` type is split into its own schema (`/schemas/creative/validate-input-result.json`) rather than inlined here because the same per-target shape is intended for reuse by adjacent async-validation surfaces (planned: per-batch result envelopes on `build_creative` async paths, and asynchronous canonical-against-product validation in `sync_creatives`). Producers that only need the synchronous batch shape today MAY treat the split as YAGNI, but the schema reuse anchors the violation/retry shape so downstream surfaces don't drift.",
   "type": "object",
   "required": [
     "results"
@@ -12,7 +12,7 @@
       "type": "array",
       "items": {
         "title": "Validate Input Result",
-        "description": "Per-target result of a validate_input call. The `result_kind` discriminator (replacing the earlier boolean `ok`) lets buyers distinguish three meaningfully different outcomes:\n\n- `validated_pass` — manifest validates cleanly against the target. Buyers can submit with confidence.\n- `validated_fail` — manifest is structurally evaluable AND fails specific constraints. `violations[]` enumerates which. Buyers fix and retry.\n- `unvalidatable_nondeterministic` — predictive validation is impossible because the target's production pipeline is genuinely nondeterministic (Veo / Sora / Runway-class formats with `synthesis_nondeterministic: true`). The platform's own post-synthesis QA loop applies; outcome is unknowable until `build_creative` runs. Buyers MUST plan for the QA-loop semantics: submission may return `task_failed` with a `synthesis_failed` reason if the QA loop exhausts. There is no protocol state for orphaned out-of-spec artifacts.\n\nThe boolean `ok` field carried in earlier drafts is removed — it conflated `validated_fail` (a real validation result the buyer can act on) with `unvalidatable_nondeterministic` (a structural property of the target the buyer needs to handle differently). `validated_fail` returns `violations[]`; `unvalidatable_nondeterministic` does not (there's nothing to enumerate).\n\n**Scope of validation (normative).** `validate_input` validates **manifest structure** against the canonical / product / third-party format target — slot counts, asset types, parameter ranges, format-shape constraints. It does NOT predict the surface's per-impression rendering choice. This distinction matters for `composition_model: algorithmic` formats (`responsive_creative`, `agent_placement`) where the surface picks combinations or phrasing at delivery time: the buyer's asset pool can still be structurally validated (does it meet the count/size/length requirements?) → `validated_pass` or `validated_fail` with violations. What's unpredictable is the rendered output composition, and that's NOT what `validate_input` claims to predict. `unvalidatable_nondeterministic` is reserved for `synthesis_nondeterministic: true` cases where the production pipeline itself can't be evaluated upfront — distinct from algorithmic composition where the inputs ARE evaluable but the output rendering isn't. Buyers calling `validate_input` on an algorithmic-composition target SHOULD expect a structural verdict (pass/fail), not a rendering preview.",
+        "description": "Per-target result of a validate_input call. The `result_kind` discriminator (replacing the earlier boolean `ok`) lets buyers distinguish three meaningfully different outcomes:\n\n- `validated_pass` — manifest is structurally valid against the target. This is not seller trafficking acceptance; use `sync_creatives` or `sync_creatives` with `dry_run: true` for upload/update, account, assignment, policy, and lifecycle gates.\n- `validated_fail` — manifest is structurally evaluable AND fails specific constraints. `violations[]` enumerates which. Buyers fix and retry.\n- `unvalidatable_nondeterministic` — predictive validation is impossible because the target's production pipeline is genuinely nondeterministic (Veo / Sora / Runway-class formats with `synthesis_nondeterministic: true`). The platform's own post-synthesis QA loop applies; outcome is unknowable until `build_creative` runs. Buyers MUST plan for the QA-loop semantics: submission may return `task_failed` with a `synthesis_failed` reason if the QA loop exhausts. There is no protocol state for orphaned out-of-spec artifacts.\n\nThe boolean `ok` field carried in earlier drafts is removed — it conflated `validated_fail` (a real validation result the buyer can act on) with `unvalidatable_nondeterministic` (a structural property of the target the buyer needs to handle differently). `validated_fail` returns `violations[]`; `unvalidatable_nondeterministic` does not (there's nothing to enumerate).\n\n**Scope of validation (normative).** `validate_input` validates **manifest structure** against the canonical / product / third-party format target — slot counts, asset types, parameter ranges, format-shape constraints. It does NOT predict the surface's per-impression rendering choice. This distinction matters for `composition_model: algorithmic` formats (`responsive_creative`, `agent_placement`) where the surface picks combinations or phrasing at delivery time: the buyer's asset pool can still be structurally validated (does it meet the count/size/length requirements?) → `validated_pass` or `validated_fail` with violations. What's unpredictable is the rendered output composition, and that's NOT what `validate_input` claims to predict. `unvalidatable_nondeterministic` is reserved for `synthesis_nondeterministic: true` cases where the production pipeline itself can't be evaluated upfront — distinct from algorithmic composition where the inputs ARE evaluable but the output rendering isn't. Buyers calling `validate_input` on an algorithmic-composition target SHOULD expect a structural verdict (pass/fail), not a rendering preview.",
         "type": "object",
         "required": [
           "target",
@@ -168,7 +168,7 @@
             }
           }
         ],
-        "$id": "/schemas/3.1.2/creative/validate-input-result.json"
+        "$id": "/schemas/3.1.5/creative/validate-input-result.json"
       },
       "description": "Per-target validation results."
     }
@@ -198,7 +198,7 @@
           "maximum": 99
         }
       },
-      "$id": "/schemas/3.1.2/core/version-envelope.json"
+      "$id": "/schemas/3.1.5/core/version-envelope.json"
     },
     {
       "title": "Protocol Envelope",
@@ -214,7 +214,7 @@
           "description": "Per-request opaque caller-supplied correlation object echoed unchanged in the response. Used for buyer-side tracking (UI session IDs, trace IDs, custom metadata) that the agent MUST preserve byte-for-byte without parsing. Distinct from `context_id` (server-managed session identifier) — `context` is caller-owned echo, `context_id` is server-owned session scope. Both MAY appear on the same response.\n\n**Relationship to per-task body-level `context` declarations.** Many task request/response schemas (147 as of 3.1) already declare a body-level `context` field that `$ref`s `/schemas/core/context.json` at the body root. Under the flat-on-the-wire MCP serialization (see `notes` below), envelope-level `context` and body-level `context` occupy the same key on the response root — they are NOT separate fields, they MUST share the same value, and they MUST both `$ref` `core/context.json`. The envelope declaration is **authoritative** for the schema definition; per-task body declarations are mirrors retained for tooling reasons (SDK codegen completeness, per-task validation against the response schema in isolation). Future versions MAY drop body-level `context` declarations from per-task schemas; conformance does not require either declaration to be present, only that the wire value `$ref`s `core/context.json`.",
           "type": "object",
           "additionalProperties": true,
-          "$id": "/schemas/3.1.2/core/context.json"
+          "$id": "/schemas/3.1.5/core/context.json"
         },
         "task_id": {
           "type": "string",
@@ -247,7 +247,7 @@
             "auth-required": "Task requires authentication to proceed",
             "unknown": "Task is in an unknown or indeterminate state"
           },
-          "$id": "/schemas/3.1.2/enums/task-status.json"
+          "$id": "/schemas/3.1.5/enums/task-status.json"
         },
         "message": {
           "type": "string",
@@ -386,7 +386,7 @@
             "message"
           ],
           "additionalProperties": true,
-          "$id": "/schemas/3.1.2/core/error.json"
+          "$id": "/schemas/3.1.5/core/error.json"
         },
         "push_notification_config": {
           "title": "Push Notification Config",
@@ -426,7 +426,7 @@
                       "Bearer",
                       "HMAC-SHA256"
                     ],
-                    "$id": "/schemas/3.1.2/enums/auth-scheme.json"
+                    "$id": "/schemas/3.1.5/enums/auth-scheme.json"
                   },
                   "minItems": 1,
                   "maxItems": 1
@@ -447,7 +447,7 @@
           "required": [
             "url"
           ],
-          "$id": "/schemas/3.1.2/core/push-notification-config.json"
+          "$id": "/schemas/3.1.5/core/push-notification-config.json"
         },
         "governance_context": {
           "type": "string",
@@ -597,11 +597,11 @@
         "`status` is REQUIRED on the conceptual envelope across all transports. On MCP and REST it appears as a sibling field at the JSON root (or `structuredContent` root for MCP); on A2A the canonical carrier is `task.status.state`, which maps 1:1 to this `status` value — receivers MUST extract A2A's `task.status.state` into the in-memory envelope `status` per the canonical extraction algorithm. The schema-level `required: [status]` enforces the post-extraction in-memory shape; the transport-native form satisfies the requirement on each wire. `payload` remains intentionally NOT required — it is a documentary grouping construct, never a required wire field. See `mcp-guide.mdx` and `a2a-guide.mdx` for the wire-level patterns receivers MUST implement.",
         "Receivers MUST handle absence of an envelope field (e.g., `replayed` omitted) as the field's documented default — see each field's `default` clause."
       ],
-      "$id": "/schemas/3.1.2/core/protocol-envelope.json"
+      "$id": "/schemas/3.1.5/core/protocol-envelope.json"
     }
   ],
   "_bundled": {
-    "generatedAt": "2026-07-08T13:55:48.685Z",
+    "generatedAt": "2026-07-24T14:33:01.863Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }