@adcp/sdk 6.6.0 → 6.7.0

package/dist/lib/schemas-data/3.0/bundled/media-buy/sync-event-sources-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/sync-event-sources-response.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/sync-event-sources-response.json",
   "title": "Sync Event Sources Response",
   "description": "Response from event source sync operation. Returns either per-source results OR operation-level errors.",
   "type": "object",
@@ -292,7 +292,7 @@
                     },
                     "field": {
                       "type": "string",
-                      "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+                      "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
                     },
                     "suggestion": {
                       "type": "string",
@@ -304,9 +304,40 @@
                       "minimum": 1,
                       "maximum": 3600
                     },
+                    "issues": {
+                      "type": "array",
+                      "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+                      "items": {
+                        "type": "object",
+                        "properties": {
+                          "pointer": {
+                            "type": "string",
+                            "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                          },
+                          "message": {
+                            "type": "string",
+                            "description": "Human-readable description of why this specific field was rejected."
+                          },
+                          "keyword": {
+                            "type": "string",
+                            "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                          },
+                          "schemaPath": {
+                            "type": "string",
+                            "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                          }
+                        },
+                        "required": [
+                          "pointer",
+                          "message",
+                          "keyword"
+                        ],
+                        "additionalProperties": true
+                      }
+                    },
                     "details": {
                       "type": "object",
-                      "description": "Additional task-specific error details",
+                      "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
                       "additionalProperties": true
                     },
                     "recovery": {
@@ -386,7 +417,7 @@
               },
               "field": {
                 "type": "string",
-                "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+                "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
               },
               "suggestion": {
                 "type": "string",
@@ -398,9 +429,40 @@
                 "minimum": 1,
                 "maximum": 3600
               },
+              "issues": {
+                "type": "array",
+                "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+                "items": {
+                  "type": "object",
+                  "properties": {
+                    "pointer": {
+                      "type": "string",
+                      "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                    },
+                    "message": {
+                      "type": "string",
+                      "description": "Human-readable description of why this specific field was rejected."
+                    },
+                    "keyword": {
+                      "type": "string",
+                      "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                    },
+                    "schemaPath": {
+                      "type": "string",
+                      "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                    }
+                  },
+                  "required": [
+                    "pointer",
+                    "message",
+                    "keyword"
+                  ],
+                  "additionalProperties": true
+                }
+              },
               "details": {
                 "type": "object",
-                "description": "Additional task-specific error details",
+                "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
                 "additionalProperties": true
               },
               "recovery": {
@@ -455,7 +517,7 @@
     }
   ],
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.014Z",
+    "generatedAt": "2026-05-02T21:51:30.467Z",
     "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.0/bundled/media-buy/update-media-buy-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/update-media-buy-request.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/update-media-buy-request.json",
   "title": "Update Media Buy Request",
   "description": "Request parameters for updating campaign and package settings",
   "x-mutates-state": true,
@@ -1914,6 +1914,8 @@
                   "description": "Assets required by the format, keyed by asset_id. Each asset value carries an `asset_type` discriminator that selects the matching asset schema.",
                   "patternProperties": {
                     "^[a-z0-9_]+$": {
+                      "title": "AssetVariant",
+                      "description": "Canonical union of all asset variant schemas. Referenced from creative-asset.json and creative-manifest.json to ensure a single named type is emitted by schema-to-TypeScript tooling. Add new asset types here and to the creative/asset-types registry.",
                       "oneOf": [
                         {
                           "title": "Image Asset",
@@ -3499,7 +3501,8 @@
                         },
                         {
                           "title": "URL Asset",
-                          "description": "URL reference asset",
+                          "$comment": "Fallback table is also rendered in docs/creative/asset-types.mdx (URL Asset section). Keep the two in sync — schema description is the normative source for conformance tools; mdx is the human-readable copy.",
+                          "description": "URL reference asset. `url_type` declares the mechanism a receiver uses to invoke the URL (clickthrough vs. tracker_pixel vs. tracker_script) and is distinct from the URL's purpose, which the format declares in `url-asset-requirements.role` (clickthrough, landing_page, impression_tracker, click_tracker, viewability_tracker, third_party_tracker). Senders SHOULD include `url_type` on every URL asset. When `url_type` is absent, receivers SHOULD fall back to the format's `url-asset-requirements.role` per this mapping: clickthrough/landing_page → `clickthrough`; impression_tracker/click_tracker → `tracker_pixel`; viewability_tracker → `tracker_script` (OMID and equivalent verification SDKs require a <script> tag — firing them as a pixel produces no measurement); third_party_tracker → no safe fallback (mechanism is integration-specific — DV/IAS ship both pixel and script forms — receivers MAY reject or warn). When neither `url_type` nor a format-side `role` is available, receivers MUST NOT silently pick a mechanism; they SHOULD reject the manifest. Note: VAST/DAAST tag URLs are not URL assets — use `asset_type: \"vast\"` (or the dedicated tracker types pending RFC #2915), not `asset_type: \"url\"` with a tracker_pixel mechanism.",
                           "type": "object",
                           "properties": {
                             "asset_type": {
@@ -8336,6 +8339,8 @@
                   "description": "Assets required by the format, keyed by asset_id. Each asset value carries an `asset_type` discriminator that selects the matching asset schema.",
                   "patternProperties": {
                     "^[a-z0-9_]+$": {
+                      "title": "AssetVariant",
+                      "description": "Canonical union of all asset variant schemas. Referenced from creative-asset.json and creative-manifest.json to ensure a single named type is emitted by schema-to-TypeScript tooling. Add new asset types here and to the creative/asset-types registry.",
                       "oneOf": [
                         {
                           "title": "Image Asset",
@@ -9921,7 +9926,8 @@
                         },
                         {
                           "title": "URL Asset",
-                          "description": "URL reference asset",
+                          "$comment": "Fallback table is also rendered in docs/creative/asset-types.mdx (URL Asset section). Keep the two in sync — schema description is the normative source for conformance tools; mdx is the human-readable copy.",
+                          "description": "URL reference asset. `url_type` declares the mechanism a receiver uses to invoke the URL (clickthrough vs. tracker_pixel vs. tracker_script) and is distinct from the URL's purpose, which the format declares in `url-asset-requirements.role` (clickthrough, landing_page, impression_tracker, click_tracker, viewability_tracker, third_party_tracker). Senders SHOULD include `url_type` on every URL asset. When `url_type` is absent, receivers SHOULD fall back to the format's `url-asset-requirements.role` per this mapping: clickthrough/landing_page → `clickthrough`; impression_tracker/click_tracker → `tracker_pixel`; viewability_tracker → `tracker_script` (OMID and equivalent verification SDKs require a <script> tag — firing them as a pixel produces no measurement); third_party_tracker → no safe fallback (mechanism is integration-specific — DV/IAS ship both pixel and script forms — receivers MAY reject or warn). When neither `url_type` nor a format-side `role` is available, receivers MUST NOT silently pick a mechanism; they SHOULD reject the manifest. Note: VAST/DAAST tag URLs are not URL assets — use `asset_type: \"vast\"` (or the dedicated tracker types pending RFC #2915), not `asset_type: \"url\"` with a tracker_pixel mechanism.",
                           "type": "object",
                           "properties": {
                             "asset_type": {
@@ -13247,7 +13253,7 @@
     },
     "URLAssetType": {
       "title": "URL Asset Type",
-      "description": "Type of URL asset: 'clickthrough' for user click destination (landing page), 'tracker_pixel' for impression/event tracking via HTTP request (fires GET, expects pixel/204 response), 'tracker_script' for measurement SDKs that must load as <script> tag (OMID verification, native event trackers using method:2)",
+      "description": "Mechanism a receiver uses to invoke this URL (distinct from purpose, which lives in `url-asset-requirements.role`): `clickthrough` for user click destination (landing page), `tracker_pixel` for impression/event tracking via HTTP request (fires GET, expects pixel/204 response), `tracker_script` for measurement SDKs that must load as a <script> tag (OMID verification, native event trackers using method:2). SHOULD be present on every URL asset; senders that omit it force the receiver into the role-based fallback described in this schema's top-level description.",
       "type": "string",
       "enum": [
         "clickthrough",
@@ -13542,7 +13548,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.025Z",
+    "generatedAt": "2026-05-02T21:51:30.483Z",
     "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.0/bundled/media-buy/update-media-buy-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/update-media-buy-response.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/update-media-buy-response.json",
   "title": "Update Media Buy Response",
   "description": "Response payload for update_media_buy task. Returns either complete success data OR error information, never both. This enforces atomic operation semantics - updates are either fully applied or not applied at all.",
   "type": "object",
@@ -2573,7 +2573,7 @@
               },
               "field": {
                 "type": "string",
-                "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+                "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
               },
               "suggestion": {
                 "type": "string",
@@ -2585,9 +2585,40 @@
                 "minimum": 1,
                 "maximum": 3600
               },
+              "issues": {
+                "type": "array",
+                "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+                "items": {
+                  "type": "object",
+                  "properties": {
+                    "pointer": {
+                      "type": "string",
+                      "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                    },
+                    "message": {
+                      "type": "string",
+                      "description": "Human-readable description of why this specific field was rejected."
+                    },
+                    "keyword": {
+                      "type": "string",
+                      "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                    },
+                    "schemaPath": {
+                      "type": "string",
+                      "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                    }
+                  },
+                  "required": [
+                    "pointer",
+                    "message",
+                    "keyword"
+                  ],
+                  "additionalProperties": true
+                }
+              },
               "details": {
                 "type": "object",
-                "description": "Additional task-specific error details",
+                "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
                 "additionalProperties": true
               },
               "recovery": {
@@ -2793,7 +2824,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.032Z",
+    "generatedAt": "2026-05-02T21:51:30.491Z",
     "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.0/bundled/property/create-property-list-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/create-property-list-request.json",
+  "$id": "/schemas/3.0.5/bundled/property/create-property-list-request.json",
   "title": "Create Property List Request",
   "description": "Request parameters for creating a new property list",
   "x-mutates-state": true,
@@ -655,7 +655,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.034Z",
+    "generatedAt": "2026-05-02T21:51:30.493Z",
     "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.0/bundled/property/create-property-list-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/create-property-list-response.json",
+  "$id": "/schemas/3.0.5/bundled/property/create-property-list-response.json",
   "title": "Create Property List Response",
   "description": "Response payload for create_property_list task",
   "type": "object",
@@ -922,7 +922,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.035Z",
+    "generatedAt": "2026-05-02T21:51:30.494Z",
     "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.0/bundled/property/delete-property-list-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/delete-property-list-request.json",
+  "$id": "/schemas/3.0.5/bundled/property/delete-property-list-request.json",
   "title": "Delete Property List Request",
   "description": "Request parameters for deleting a property list",
   "x-mutates-state": true,
@@ -192,7 +192,7 @@
   ],
   "additionalProperties": false,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.036Z",
+    "generatedAt": "2026-05-02T21:51:30.495Z",
     "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.0/bundled/property/delete-property-list-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/delete-property-list-response.json",
+  "$id": "/schemas/3.0.5/bundled/property/delete-property-list-response.json",
   "title": "Delete Property List Response",
   "description": "Response payload for delete_property_list task",
   "type": "object",
@@ -38,7 +38,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.036Z",
+    "generatedAt": "2026-05-02T21:51:30.495Z",
     "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.0/bundled/property/get-property-list-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/get-property-list-request.json",
+  "$id": "/schemas/3.0.5/bundled/property/get-property-list-request.json",
   "title": "Get Property List Request",
   "description": "Request parameters for retrieving a property list with resolved identifiers",
   "type": "object",
@@ -206,7 +206,7 @@
   ],
   "additionalProperties": false,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.036Z",
+    "generatedAt": "2026-05-02T21:51:30.495Z",
     "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.0/bundled/property/get-property-list-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/get-property-list-response.json",
+  "$id": "/schemas/3.0.5/bundled/property/get-property-list-response.json",
   "title": "Get Property List Response",
   "description": "Response payload for get_property_list task. Returns identifiers only (not full property objects or scores). Consumers should cache the resolved identifiers and refresh based on cache_valid_until.",
   "type": "object",
@@ -995,7 +995,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.037Z",
+    "generatedAt": "2026-05-02T21:51:30.496Z",
     "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.0/bundled/property/list-property-lists-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/list-property-lists-request.json",
+  "$id": "/schemas/3.0.5/bundled/property/list-property-lists-request.json",
   "title": "List Property Lists Request",
   "description": "Request parameters for listing property lists",
   "type": "object",
@@ -198,7 +198,7 @@
   },
   "additionalProperties": false,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.038Z",
+    "generatedAt": "2026-05-02T21:51:30.497Z",
     "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.0/bundled/property/list-property-lists-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/list-property-lists-response.json",
+  "$id": "/schemas/3.0.5/bundled/property/list-property-lists-response.json",
   "title": "List Property Lists Response",
   "description": "Response payload for list_property_lists task",
   "type": "object",
@@ -940,7 +940,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.039Z",
+    "generatedAt": "2026-05-02T21:51:30.498Z",
     "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.0/bundled/property/update-property-list-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/update-property-list-request.json",
+  "$id": "/schemas/3.0.5/bundled/property/update-property-list-request.json",
   "title": "Update Property List Request",
   "description": "Request parameters for updating an existing property list",
   "x-mutates-state": true,
@@ -664,7 +664,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.040Z",
+    "generatedAt": "2026-05-02T21:51:30.498Z",
     "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.0/bundled/property/update-property-list-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/update-property-list-response.json",
+  "$id": "/schemas/3.0.5/bundled/property/update-property-list-response.json",
   "title": "Update Property List Response",
   "description": "Response payload for update_property_list task",
   "type": "object",
@@ -917,7 +917,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.040Z",
+    "generatedAt": "2026-05-02T21:51:30.499Z",
     "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.0/bundled/property/validate-property-delivery-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/validate-property-delivery-request.json",
+  "$id": "/schemas/3.0.5/bundled/property/validate-property-delivery-request.json",
   "title": "Validate Property Delivery Request",
   "description": "Request payload for validate_property_delivery task. Validates delivery records against a property list to determine compliance.",
   "type": "object",
@@ -302,7 +302,7 @@
   ],
   "additionalProperties": false,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.041Z",
+    "generatedAt": "2026-05-02T21:51:30.500Z",
     "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.0/bundled/property/validate-property-delivery-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/property/validate-property-delivery-response.json",
+  "$id": "/schemas/3.0.5/bundled/property/validate-property-delivery-response.json",
   "title": "Validate Property Delivery Response",
   "description": "Response payload for validate_property_delivery task. Returns aggregate compliance statistics and per-record validation results.",
   "type": "object",
@@ -412,7 +412,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.042Z",
+    "generatedAt": "2026-05-02T21:51:30.500Z",
     "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.0/bundled/protocol/get-adcp-capabilities-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/protocol/get-adcp-capabilities-request.json",
+  "$id": "/schemas/3.0.5/bundled/protocol/get-adcp-capabilities-request.json",
   "title": "Get AdCP Capabilities Request",
   "description": "Request payload for get_adcp_capabilities task. Protocol-level capability discovery that works across all AdCP protocols.",
   "type": "object",
@@ -41,7 +41,7 @@
   },
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.042Z",
+    "generatedAt": "2026-05-02T21:51:30.501Z",
     "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.0/bundled/protocol/get-adcp-capabilities-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/protocol/get-adcp-capabilities-response.json",
+  "$id": "/schemas/3.0.5/bundled/protocol/get-adcp-capabilities-response.json",
   "title": "Get AdCP Capabilities Response",
   "description": "Response payload for get_adcp_capabilities task. Protocol-level capability discovery across all AdCP protocols. Each protocol has its own capability section.",
   "type": "object",
@@ -1379,7 +1379,7 @@
           "additionalProperties": false
         }
       },
-      "additionalProperties": false
+      "additionalProperties": true
     },
     "compliance_testing": {
       "type": "object",
@@ -1510,7 +1510,7 @@
           },
           "field": {
             "type": "string",
-            "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+            "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
           },
           "suggestion": {
             "type": "string",
@@ -1522,9 +1522,40 @@
             "minimum": 1,
             "maximum": 3600
           },
+          "issues": {
+            "type": "array",
+            "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+            "items": {
+              "type": "object",
+              "properties": {
+                "pointer": {
+                  "type": "string",
+                  "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                },
+                "message": {
+                  "type": "string",
+                  "description": "Human-readable description of why this specific field was rejected."
+                },
+                "keyword": {
+                  "type": "string",
+                  "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                },
+                "schemaPath": {
+                  "type": "string",
+                  "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                }
+              },
+              "required": [
+                "pointer",
+                "message",
+                "keyword"
+              ],
+              "additionalProperties": true
+            }
+          },
           "details": {
             "type": "object",
-            "description": "Additional task-specific error details",
+            "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
             "additionalProperties": true
           },
           "recovery": {
@@ -1723,7 +1754,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.044Z",
+    "generatedAt": "2026-05-02T21:51:30.503Z",
     "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.0/bundled/signals/activate-signal-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/signals/activate-signal-request.json",
+  "$id": "/schemas/3.0.5/bundled/signals/activate-signal-request.json",
   "title": "Activate Signal Request",
   "description": "Request parameters for activating or deactivating a signal on deployment targets",
   "x-mutates-state": true,
@@ -263,7 +263,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.044Z",
+    "generatedAt": "2026-05-02T21:51:30.504Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }