@adcp/sdk 6.5.0 → 6.7.0

package/dist/lib/schemas-data/3.0/bundled/signals/activate-signal-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/signals/activate-signal-response.json",
+  "$id": "/schemas/3.0.5/bundled/signals/activate-signal-response.json",
   "title": "Activate Signal Response",
   "description": "Response payload for activate_signal task. Returns either complete success data OR error information, never both. This enforces atomic operation semantics - the signal is either fully activated or not activated at all.",
   "type": "object",
@@ -245,7 +245,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",
@@ -257,9 +257,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": {
@@ -314,7 +345,7 @@
     }
   ],
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.045Z",
+    "generatedAt": "2026-05-02T21:51:30.505Z",
     "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/get-signals-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/signals/get-signals-request.json",
+  "$id": "/schemas/3.0.5/bundled/signals/get-signals-request.json",
   "title": "Get Signals Request",
   "description": "Request parameters for discovering and refining signals. Use signal_spec for natural language discovery, signal_ids for exact lookups, or both to refine previous results (signal_ids anchor the starting set, signal_spec guides adjustments).",
   "type": "object",
@@ -403,7 +403,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.045Z",
+    "generatedAt": "2026-05-02T21:51:30.505Z",
     "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/get-signals-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/signals/get-signals-response.json",
+  "$id": "/schemas/3.0.5/bundled/signals/get-signals-response.json",
   "title": "Get Signals Response",
   "description": "Response payload for get_signals task",
   "type": "object",
@@ -603,7 +603,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",
@@ -615,9 +615,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": {
@@ -683,7 +714,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.046Z",
+    "generatedAt": "2026-05-02T21:51:30.506Z",
     "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/sponsored-intelligence/si-get-offering-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/sponsored-intelligence/si-get-offering-request.json",
+  "$id": "/schemas/3.0.5/bundled/sponsored-intelligence/si-get-offering-request.json",
   "title": "SI Get Offering Request",
   "description": "Get offering details and availability before session handoff. Returns offering information, availability status, and optionally matching products based on context.",
   "x-status": "experimental",
@@ -51,7 +51,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.046Z",
+    "generatedAt": "2026-05-02T21:51:30.506Z",
     "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/sponsored-intelligence/si-get-offering-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/sponsored-intelligence/si-get-offering-response.json",
+  "$id": "/schemas/3.0.5/bundled/sponsored-intelligence/si-get-offering-response.json",
   "title": "SI Get Offering Response",
   "description": "Offering details, availability status, and optionally matching products. Use the offering_token in si_initiate_session for correlation.",
   "x-status": "experimental",
@@ -148,7 +148,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",
@@ -160,9 +160,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": {
@@ -201,7 +232,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.046Z",
+    "generatedAt": "2026-05-02T21:51:30.507Z",
     "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/sponsored-intelligence/si-initiate-session-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/sponsored-intelligence/si-initiate-session-request.json",
+  "$id": "/schemas/3.0.5/bundled/sponsored-intelligence/si-initiate-session-request.json",
   "title": "SI Initiate Session Request",
   "description": "Host initiates a session with a brand agent",
   "x-status": "experimental",
@@ -316,7 +316,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.047Z",
+    "generatedAt": "2026-05-02T21:51:30.507Z",
     "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/sponsored-intelligence/si-initiate-session-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/sponsored-intelligence/si-initiate-session-response.json",
+  "$id": "/schemas/3.0.5/bundled/sponsored-intelligence/si-initiate-session-response.json",
   "title": "SI Initiate Session Response",
   "description": "Brand agent's response to session initiation",
   "x-status": "experimental",
@@ -558,7 +558,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",
@@ -570,9 +570,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": {
@@ -612,7 +643,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.047Z",
+    "generatedAt": "2026-05-02T21:51:30.508Z",
     "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/sponsored-intelligence/si-send-message-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/sponsored-intelligence/si-send-message-request.json",
+  "$id": "/schemas/3.0.5/bundled/sponsored-intelligence/si-send-message-request.json",
   "title": "SI Send Message Request",
   "description": "Send a message to the brand agent within an active session",
   "x-status": "experimental",
@@ -75,7 +75,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.047Z",
+    "generatedAt": "2026-05-02T21:51:30.508Z",
     "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/sponsored-intelligence/si-send-message-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/sponsored-intelligence/si-send-message-response.json",
+  "$id": "/schemas/3.0.5/bundled/sponsored-intelligence/si-send-message-response.json",
   "title": "SI Send Message Response",
   "description": "Brand agent's response to a user message",
   "x-status": "experimental",
@@ -530,7 +530,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",
@@ -542,9 +542,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": {
@@ -583,7 +614,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.048Z",
+    "generatedAt": "2026-05-02T21:51:30.508Z",
     "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/sponsored-intelligence/si-terminate-session-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/sponsored-intelligence/si-terminate-session-request.json",
+  "$id": "/schemas/3.0.5/bundled/sponsored-intelligence/si-terminate-session-request.json",
   "title": "SI Terminate Session Request",
   "description": "Request to terminate an SI session. Naturally idempotent — `session_id` is the dedup boundary, and terminating an already-terminated session is a no-op that returns the same terminal state. No `idempotency_key` is needed on this request.",
   "x-status": "experimental",
@@ -81,7 +81,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.048Z",
+    "generatedAt": "2026-05-02T21:51:30.509Z",
     "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/sponsored-intelligence/si-terminate-session-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/sponsored-intelligence/si-terminate-session-response.json",
+  "$id": "/schemas/3.0.5/bundled/sponsored-intelligence/si-terminate-session-response.json",
   "title": "SI Terminate Session Response",
   "description": "Confirmation of session termination",
   "x-status": "experimental",
@@ -97,7 +97,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",
@@ -109,9 +109,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": {
@@ -150,7 +181,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.048Z",
+    "generatedAt": "2026-05-02T21:51:30.509Z",
     "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/collection/base-collection-source.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/collection/base-collection-source.json",
+  "$id": "/schemas/3.0.5/collection/base-collection-source.json",
   "title": "Base Collection Source",
   "description": "A source of collections for a collection list. Supports three selection patterns: distribution identifiers (cross-publisher), publisher-specific collection IDs, or publisher-specific genres.",
   "discriminator": {
@@ -24,7 +24,7 @@
             "type": "object",
             "properties": {
               "type": {
-                "$ref": "/schemas/3.0.1/enums/distribution-identifier-type.json",
+                "$ref": "/schemas/3.0.5/enums/distribution-identifier-type.json",
                 "description": "Type of distribution identifier"
               },
               "value": {
@@ -102,7 +102,7 @@
           "minItems": 1
         },
         "genre_taxonomy": {
-          "$ref": "/schemas/3.0.1/enums/genre-taxonomy.json",
+          "$ref": "/schemas/3.0.5/enums/genre-taxonomy.json",
           "description": "Taxonomy for the genre values. Required so sellers can interpret genre strings unambiguously. Use 'custom' for free-form values negotiated out of band."
         }
       },

package/dist/lib/schemas-data/3.0/collection/collection-list-changed-webhook.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/collection/collection-list-changed-webhook.json",
+  "$id": "/schemas/3.0.5/collection/collection-list-changed-webhook.json",
   "title": "Collection List Changed Webhook",
   "description": "Webhook notification sent when a collection list's resolved collections change. Contains a summary only — recipients must call get_collection_list to retrieve the updated collections.",
   "type": "object",
@@ -60,7 +60,7 @@
       "description": "HMAC-SHA256 webhook signature over {unix_timestamp}.{raw_http_body_bytes} using the secret exchanged out-of-band when the seller registered with the governance agent. Recipients MUST verify against the X-ADCP-Signature and X-ADCP-Timestamp headers using timing-safe comparison and MUST reject requests where |now - timestamp| > 300 seconds. The body copy of this field is a convenience only — the headers are authoritative. See docs/building/implementation/security#webhook-security."
     },
     "ext": {
-      "$ref": "/schemas/3.0.1/core/ext.json"
+      "$ref": "/schemas/3.0.5/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.0/collection/collection-list-filters.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/collection/collection-list-filters.json",
+  "$id": "/schemas/3.0.5/collection/collection-list-filters.json",
   "title": "Collection List Filters",
   "description": "Filters that dynamically modify a collection list when resolved. Include filters are allowlists (only matching collections pass). Exclude filters are blocklists (matching collections are removed). When both are present for the same dimension, include is applied first, then exclude narrows further.",
   "type": "object",
@@ -9,7 +9,7 @@
       "type": "array",
       "description": "Exclude collections with any of these content ratings (OR logic). This is a metadata filter on the collection's declared content_rating field — it does not evaluate episode content.",
       "items": {
-        "$ref": "/schemas/3.0.1/core/content-rating.json"
+        "$ref": "/schemas/3.0.5/core/content-rating.json"
       },
       "minItems": 1
     },
@@ -17,7 +17,7 @@
       "type": "array",
       "description": "Include only collections with any of these content ratings (OR logic). Collections without a declared content_rating are excluded.",
       "items": {
-        "$ref": "/schemas/3.0.1/core/content-rating.json"
+        "$ref": "/schemas/3.0.5/core/content-rating.json"
       },
       "minItems": 1
     },
@@ -38,14 +38,14 @@
       "minItems": 1
     },
     "genre_taxonomy": {
-      "$ref": "/schemas/3.0.1/enums/genre-taxonomy.json",
+      "$ref": "/schemas/3.0.5/enums/genre-taxonomy.json",
       "description": "Taxonomy for genre filter values. When present, genres_include and genres_exclude values are interpreted as taxonomy IDs."
     },
     "kinds": {
       "type": "array",
       "description": "Filter to these collection kinds",
       "items": {
-        "$ref": "/schemas/3.0.1/enums/collection-kind.json"
+        "$ref": "/schemas/3.0.5/enums/collection-kind.json"
       },
       "minItems": 1
     },
@@ -56,7 +56,7 @@
         "type": "object",
         "properties": {
           "type": {
-            "$ref": "/schemas/3.0.1/enums/distribution-identifier-type.json",
+            "$ref": "/schemas/3.0.5/enums/distribution-identifier-type.json",
             "description": "Type of distribution identifier"
           },
           "value": {
@@ -76,7 +76,7 @@
       "type": "array",
       "description": "Filter by production quality tier",
       "items": {
-        "$ref": "/schemas/3.0.1/enums/production-quality.json"
+        "$ref": "/schemas/3.0.5/enums/production-quality.json"
       },
       "minItems": 1
     }