@adcp/sdk 15.8.1 → 15.9.0

package/dist/lib/validation/sync-creatives.d.ts

@@ -247,7 +247,7 @@ export declare const SyncCreativesItemSchema: z.ZodObject<{
             }, z.core.$loose>>;
             issues: z.ZodOptional<z.ZodArray<z.ZodObject<{
                 issue_id: z.ZodString;
-                code: z.ZodUnion<readonly [z.ZodLiteral<"REPORT_OVERDUE">, z.ZodLiteral<"PRODUCTION_FAILED">, z.ZodLiteral<"DELIVERY_FAILED">, z.ZodLiteral<"ACCESS_REQUIRED">, z.ZodLiteral<"CONFIGURATION_REQUIRED">, z.ZodLiteral<"REPORTING_COVERAGE_INCOMPLETE">, z.ZodLiteral<"RESOURCE_EXPIRED">, z.ZodLiteral<"READER_INCOMPATIBLE">, z.ZodLiteral<"HISTORY_UNAVAILABLE">, z.ZodLiteral<"RECEIPT_REQUIRED">, z.ZodLiteral<"RECEIPT_REJECTED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REQUIRED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REJECTED">, z.ZodLiteral<"CONSUMER_STATUS_MISMATCH">]>;
+                code: z.ZodUnion<readonly [z.ZodLiteral<"REPORT_OVERDUE">, z.ZodLiteral<"PRODUCTION_FAILED">, z.ZodLiteral<"DELIVERY_FAILED">, z.ZodLiteral<"ACCESS_REQUIRED">, z.ZodLiteral<"CONFIGURATION_REQUIRED">, z.ZodLiteral<"REPORTING_COVERAGE_INCOMPLETE">, z.ZodLiteral<"RESOURCE_EXPIRED">, z.ZodLiteral<"READER_INCOMPATIBLE">, z.ZodLiteral<"HISTORY_UNAVAILABLE">, z.ZodLiteral<"REVISION_UNREADABLE">, z.ZodLiteral<"RECEIPT_REQUIRED">, z.ZodLiteral<"RECEIPT_REJECTED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REQUIRED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REJECTED">, z.ZodLiteral<"CONSUMER_STATUS_MISMATCH">]>;
                 severity: z.ZodUnion<readonly [z.ZodLiteral<"delayed">, z.ZodLiteral<"action_required">]>;
                 opened_at: z.ZodOptional<z.ZodString>;
                 issue_state: z.ZodOptional<z.ZodUnion<readonly [z.ZodLiteral<"open">, z.ZodLiteral<"acknowledged">, z.ZodLiteral<"resolved">, z.ZodLiteral<"waived">]>>;
@@ -256,6 +256,7 @@ export declare const SyncCreativesItemSchema: z.ZodObject<{
                 recommended_action: z.ZodUnion<readonly [z.ZodLiteral<"wait_for_retry">, z.ZodLiteral<"contact_buyer">, z.ZodLiteral<"contact_seller">, z.ZodLiteral<"contact_provider">, z.ZodLiteral<"repair_access">, z.ZodLiteral<"update_configuration">, z.ZodLiteral<"change_reporting_scope">, z.ZodLiteral<"use_supported_reader">]>;
                 message: z.ZodOptional<z.ZodString>;
                 reporting_obligation_id: z.ZodOptional<z.ZodString>;
+                reporting_revision_id: z.ZodOptional<z.ZodString>;
                 reporting_status_id: z.ZodOptional<z.ZodString>;
                 delivery_config_id: z.ZodOptional<z.ZodString>;
                 delivery_config_version: z.ZodOptional<z.ZodNumber>;
@@ -598,7 +599,7 @@ export declare const SyncCreativesSuccessStrictSchema: z.ZodObject<{
                 }, z.core.$loose>>;
                 issues: z.ZodOptional<z.ZodArray<z.ZodObject<{
                     issue_id: z.ZodString;
-                    code: z.ZodUnion<readonly [z.ZodLiteral<"REPORT_OVERDUE">, z.ZodLiteral<"PRODUCTION_FAILED">, z.ZodLiteral<"DELIVERY_FAILED">, z.ZodLiteral<"ACCESS_REQUIRED">, z.ZodLiteral<"CONFIGURATION_REQUIRED">, z.ZodLiteral<"REPORTING_COVERAGE_INCOMPLETE">, z.ZodLiteral<"RESOURCE_EXPIRED">, z.ZodLiteral<"READER_INCOMPATIBLE">, z.ZodLiteral<"HISTORY_UNAVAILABLE">, z.ZodLiteral<"RECEIPT_REQUIRED">, z.ZodLiteral<"RECEIPT_REJECTED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REQUIRED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REJECTED">, z.ZodLiteral<"CONSUMER_STATUS_MISMATCH">]>;
+                    code: z.ZodUnion<readonly [z.ZodLiteral<"REPORT_OVERDUE">, z.ZodLiteral<"PRODUCTION_FAILED">, z.ZodLiteral<"DELIVERY_FAILED">, z.ZodLiteral<"ACCESS_REQUIRED">, z.ZodLiteral<"CONFIGURATION_REQUIRED">, z.ZodLiteral<"REPORTING_COVERAGE_INCOMPLETE">, z.ZodLiteral<"RESOURCE_EXPIRED">, z.ZodLiteral<"READER_INCOMPATIBLE">, z.ZodLiteral<"HISTORY_UNAVAILABLE">, z.ZodLiteral<"REVISION_UNREADABLE">, z.ZodLiteral<"RECEIPT_REQUIRED">, z.ZodLiteral<"RECEIPT_REJECTED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REQUIRED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REJECTED">, z.ZodLiteral<"CONSUMER_STATUS_MISMATCH">]>;
                     severity: z.ZodUnion<readonly [z.ZodLiteral<"delayed">, z.ZodLiteral<"action_required">]>;
                     opened_at: z.ZodOptional<z.ZodString>;
                     issue_state: z.ZodOptional<z.ZodUnion<readonly [z.ZodLiteral<"open">, z.ZodLiteral<"acknowledged">, z.ZodLiteral<"resolved">, z.ZodLiteral<"waived">]>>;
@@ -607,6 +608,7 @@ export declare const SyncCreativesSuccessStrictSchema: z.ZodObject<{
                     recommended_action: z.ZodUnion<readonly [z.ZodLiteral<"wait_for_retry">, z.ZodLiteral<"contact_buyer">, z.ZodLiteral<"contact_seller">, z.ZodLiteral<"contact_provider">, z.ZodLiteral<"repair_access">, z.ZodLiteral<"update_configuration">, z.ZodLiteral<"change_reporting_scope">, z.ZodLiteral<"use_supported_reader">]>;
                     message: z.ZodOptional<z.ZodString>;
                     reporting_obligation_id: z.ZodOptional<z.ZodString>;
+                    reporting_revision_id: z.ZodOptional<z.ZodString>;
                     reporting_status_id: z.ZodOptional<z.ZodString>;
                     delivery_config_id: z.ZodOptional<z.ZodString>;
                     delivery_config_version: z.ZodOptional<z.ZodNumber>;
@@ -961,7 +963,7 @@ export declare const SyncCreativesResponseStrictSchema: z.ZodUnion<readonly [z.Z
                 }, z.core.$loose>>;
                 issues: z.ZodOptional<z.ZodArray<z.ZodObject<{
                     issue_id: z.ZodString;
-                    code: z.ZodUnion<readonly [z.ZodLiteral<"REPORT_OVERDUE">, z.ZodLiteral<"PRODUCTION_FAILED">, z.ZodLiteral<"DELIVERY_FAILED">, z.ZodLiteral<"ACCESS_REQUIRED">, z.ZodLiteral<"CONFIGURATION_REQUIRED">, z.ZodLiteral<"REPORTING_COVERAGE_INCOMPLETE">, z.ZodLiteral<"RESOURCE_EXPIRED">, z.ZodLiteral<"READER_INCOMPATIBLE">, z.ZodLiteral<"HISTORY_UNAVAILABLE">, z.ZodLiteral<"RECEIPT_REQUIRED">, z.ZodLiteral<"RECEIPT_REJECTED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REQUIRED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REJECTED">, z.ZodLiteral<"CONSUMER_STATUS_MISMATCH">]>;
+                    code: z.ZodUnion<readonly [z.ZodLiteral<"REPORT_OVERDUE">, z.ZodLiteral<"PRODUCTION_FAILED">, z.ZodLiteral<"DELIVERY_FAILED">, z.ZodLiteral<"ACCESS_REQUIRED">, z.ZodLiteral<"CONFIGURATION_REQUIRED">, z.ZodLiteral<"REPORTING_COVERAGE_INCOMPLETE">, z.ZodLiteral<"RESOURCE_EXPIRED">, z.ZodLiteral<"READER_INCOMPATIBLE">, z.ZodLiteral<"HISTORY_UNAVAILABLE">, z.ZodLiteral<"REVISION_UNREADABLE">, z.ZodLiteral<"RECEIPT_REQUIRED">, z.ZodLiteral<"RECEIPT_REJECTED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REQUIRED">, z.ZodLiteral<"ADJUSTMENT_RECEIPT_REJECTED">, z.ZodLiteral<"CONSUMER_STATUS_MISMATCH">]>;
                     severity: z.ZodUnion<readonly [z.ZodLiteral<"delayed">, z.ZodLiteral<"action_required">]>;
                     opened_at: z.ZodOptional<z.ZodString>;
                     issue_state: z.ZodOptional<z.ZodUnion<readonly [z.ZodLiteral<"open">, z.ZodLiteral<"acknowledged">, z.ZodLiteral<"resolved">, z.ZodLiteral<"waived">]>>;
@@ -970,6 +972,7 @@ export declare const SyncCreativesResponseStrictSchema: z.ZodUnion<readonly [z.Z
                     recommended_action: z.ZodUnion<readonly [z.ZodLiteral<"wait_for_retry">, z.ZodLiteral<"contact_buyer">, z.ZodLiteral<"contact_seller">, z.ZodLiteral<"contact_provider">, z.ZodLiteral<"repair_access">, z.ZodLiteral<"update_configuration">, z.ZodLiteral<"change_reporting_scope">, z.ZodLiteral<"use_supported_reader">]>;
                     message: z.ZodOptional<z.ZodString>;
                     reporting_obligation_id: z.ZodOptional<z.ZodString>;
+                    reporting_revision_id: z.ZodOptional<z.ZodString>;
                     reporting_status_id: z.ZodOptional<z.ZodString>;
                     delivery_config_id: z.ZodOptional<z.ZodString>;
                     delivery_config_version: z.ZodOptional<z.ZodNumber>;

package/dist/lib/version.d.mts

@@ -1,11 +1,11 @@
 /**
  * AdCP SDK library version
  */
-export declare const LIBRARY_VERSION = "15.8.1";
+export declare const LIBRARY_VERSION = "15.9.0";
 /**
  * AdCP specification version this library is built for
  */
-export declare const ADCP_VERSION = "3.2.3";
+export declare const ADCP_VERSION = "3.2.4";
 /**
  * AdCP major version sent with every request (adcp_major_version field).
  * Sellers validate this against their supported versions and return
@@ -19,7 +19,7 @@ export declare const ADCP_MAJOR_VERSION = 3;
  * this list by hand; bumping the AdCP pin via `npm run sync-version`
  * extends it.
  */
-export declare const COMPATIBLE_ADCP_VERSIONS: readonly ["v2.5", "v2.6", "v3", "3.0.0", "3.0", "3.0.1", "3.0.2", "3.0.3", "3.0.4", "3.0.5", "3.0.6", "3.0.7", "3.0.8", "3.0.9", "3.0.10", "3.0.11", "3.0.12", "3.0.13", "3.0.14", "3.0.15", "3.0.16", "3.0.17", "3.0.18", "3.0.19", "3.0.20", "3.0.21", "3.0.22", "3.0.23", "3.0.24", "3.0.25", "3.1.0", "3.1", "3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1.5", "3.1.6", "3.1.7", "3.1.8", "3.1.9", "3.1.10", "3.1.11", "3.1.12", "3.1.13", "3.1.14", "3.1.15", "3.1.16", "3.1.17", "3.1.18", "3.1.19", "3.1.20", "3.1.21", "3.1.22", "3.1.23", "3.1.24", "3.2.1", "3.2", "3.2.2", "3.2.3"];
+export declare const COMPATIBLE_ADCP_VERSIONS: readonly ["v2.5", "v2.6", "v3", "3.0.0", "3.0", "3.0.1", "3.0.2", "3.0.3", "3.0.4", "3.0.5", "3.0.6", "3.0.7", "3.0.8", "3.0.9", "3.0.10", "3.0.11", "3.0.12", "3.0.13", "3.0.14", "3.0.15", "3.0.16", "3.0.17", "3.0.18", "3.0.19", "3.0.20", "3.0.21", "3.0.22", "3.0.23", "3.0.24", "3.0.25", "3.1.0", "3.1", "3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1.5", "3.1.6", "3.1.7", "3.1.8", "3.1.9", "3.1.10", "3.1.11", "3.1.12", "3.1.13", "3.1.14", "3.1.15", "3.1.16", "3.1.17", "3.1.18", "3.1.19", "3.1.20", "3.1.21", "3.1.22", "3.1.23", "3.1.24", "3.2.1", "3.2", "3.2.2", "3.2.3", "3.2.4"];
 /**
  * String literal union of every AdCP version the SDK formally supports.
  *
@@ -33,10 +33,10 @@ export type AdcpVersion = (typeof COMPATIBLE_ADCP_VERSIONS)[number];
  * Full version information
  */
 export declare const VERSION_INFO: {
-    readonly library: "15.8.1";
-    readonly adcp: "3.2.3";
-    readonly compatibleVersions: readonly ["v2.5", "v2.6", "v3", "3.0.0", "3.0", "3.0.1", "3.0.2", "3.0.3", "3.0.4", "3.0.5", "3.0.6", "3.0.7", "3.0.8", "3.0.9", "3.0.10", "3.0.11", "3.0.12", "3.0.13", "3.0.14", "3.0.15", "3.0.16", "3.0.17", "3.0.18", "3.0.19", "3.0.20", "3.0.21", "3.0.22", "3.0.23", "3.0.24", "3.0.25", "3.1.0", "3.1", "3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1.5", "3.1.6", "3.1.7", "3.1.8", "3.1.9", "3.1.10", "3.1.11", "3.1.12", "3.1.13", "3.1.14", "3.1.15", "3.1.16", "3.1.17", "3.1.18", "3.1.19", "3.1.20", "3.1.21", "3.1.22", "3.1.23", "3.1.24", "3.2.1", "3.2", "3.2.2", "3.2.3"];
-    readonly generatedAt: "2026-10-11T16:14:38.709Z";
+    readonly library: "15.9.0";
+    readonly adcp: "3.2.4";
+    readonly compatibleVersions: readonly ["v2.5", "v2.6", "v3", "3.0.0", "3.0", "3.0.1", "3.0.2", "3.0.3", "3.0.4", "3.0.5", "3.0.6", "3.0.7", "3.0.8", "3.0.9", "3.0.10", "3.0.11", "3.0.12", "3.0.13", "3.0.14", "3.0.15", "3.0.16", "3.0.17", "3.0.18", "3.0.19", "3.0.20", "3.0.21", "3.0.22", "3.0.23", "3.0.24", "3.0.25", "3.1.0", "3.1", "3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1.5", "3.1.6", "3.1.7", "3.1.8", "3.1.9", "3.1.10", "3.1.11", "3.1.12", "3.1.13", "3.1.14", "3.1.15", "3.1.16", "3.1.17", "3.1.18", "3.1.19", "3.1.20", "3.1.21", "3.1.22", "3.1.23", "3.1.24", "3.2.1", "3.2", "3.2.2", "3.2.3", "3.2.4"];
+    readonly generatedAt: "2026-10-13T01:26:11.275Z";
 };
 /**
  * Get the AdCP specification version this library is built for

package/dist/lib/version.d.ts

@@ -1,11 +1,11 @@
 /**
  * AdCP SDK library version
  */
-export declare const LIBRARY_VERSION = "15.8.1";
+export declare const LIBRARY_VERSION = "15.9.0";
 /**
  * AdCP specification version this library is built for
  */
-export declare const ADCP_VERSION = "3.2.3";
+export declare const ADCP_VERSION = "3.2.4";
 /**
  * AdCP major version sent with every request (adcp_major_version field).
  * Sellers validate this against their supported versions and return
@@ -19,7 +19,7 @@ export declare const ADCP_MAJOR_VERSION = 3;
  * this list by hand; bumping the AdCP pin via `npm run sync-version`
  * extends it.
  */
-export declare const COMPATIBLE_ADCP_VERSIONS: readonly ["v2.5", "v2.6", "v3", "3.0.0", "3.0", "3.0.1", "3.0.2", "3.0.3", "3.0.4", "3.0.5", "3.0.6", "3.0.7", "3.0.8", "3.0.9", "3.0.10", "3.0.11", "3.0.12", "3.0.13", "3.0.14", "3.0.15", "3.0.16", "3.0.17", "3.0.18", "3.0.19", "3.0.20", "3.0.21", "3.0.22", "3.0.23", "3.0.24", "3.0.25", "3.1.0", "3.1", "3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1.5", "3.1.6", "3.1.7", "3.1.8", "3.1.9", "3.1.10", "3.1.11", "3.1.12", "3.1.13", "3.1.14", "3.1.15", "3.1.16", "3.1.17", "3.1.18", "3.1.19", "3.1.20", "3.1.21", "3.1.22", "3.1.23", "3.1.24", "3.2.1", "3.2", "3.2.2", "3.2.3"];
+export declare const COMPATIBLE_ADCP_VERSIONS: readonly ["v2.5", "v2.6", "v3", "3.0.0", "3.0", "3.0.1", "3.0.2", "3.0.3", "3.0.4", "3.0.5", "3.0.6", "3.0.7", "3.0.8", "3.0.9", "3.0.10", "3.0.11", "3.0.12", "3.0.13", "3.0.14", "3.0.15", "3.0.16", "3.0.17", "3.0.18", "3.0.19", "3.0.20", "3.0.21", "3.0.22", "3.0.23", "3.0.24", "3.0.25", "3.1.0", "3.1", "3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1.5", "3.1.6", "3.1.7", "3.1.8", "3.1.9", "3.1.10", "3.1.11", "3.1.12", "3.1.13", "3.1.14", "3.1.15", "3.1.16", "3.1.17", "3.1.18", "3.1.19", "3.1.20", "3.1.21", "3.1.22", "3.1.23", "3.1.24", "3.2.1", "3.2", "3.2.2", "3.2.3", "3.2.4"];
 /**
  * String literal union of every AdCP version the SDK formally supports.
  *
@@ -33,10 +33,10 @@ export type AdcpVersion = (typeof COMPATIBLE_ADCP_VERSIONS)[number];
  * Full version information
  */
 export declare const VERSION_INFO: {
-    readonly library: "15.8.1";
-    readonly adcp: "3.2.3";
-    readonly compatibleVersions: readonly ["v2.5", "v2.6", "v3", "3.0.0", "3.0", "3.0.1", "3.0.2", "3.0.3", "3.0.4", "3.0.5", "3.0.6", "3.0.7", "3.0.8", "3.0.9", "3.0.10", "3.0.11", "3.0.12", "3.0.13", "3.0.14", "3.0.15", "3.0.16", "3.0.17", "3.0.18", "3.0.19", "3.0.20", "3.0.21", "3.0.22", "3.0.23", "3.0.24", "3.0.25", "3.1.0", "3.1", "3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1.5", "3.1.6", "3.1.7", "3.1.8", "3.1.9", "3.1.10", "3.1.11", "3.1.12", "3.1.13", "3.1.14", "3.1.15", "3.1.16", "3.1.17", "3.1.18", "3.1.19", "3.1.20", "3.1.21", "3.1.22", "3.1.23", "3.1.24", "3.2.1", "3.2", "3.2.2", "3.2.3"];
-    readonly generatedAt: "2026-10-11T16:14:38.709Z";
+    readonly library: "15.9.0";
+    readonly adcp: "3.2.4";
+    readonly compatibleVersions: readonly ["v2.5", "v2.6", "v3", "3.0.0", "3.0", "3.0.1", "3.0.2", "3.0.3", "3.0.4", "3.0.5", "3.0.6", "3.0.7", "3.0.8", "3.0.9", "3.0.10", "3.0.11", "3.0.12", "3.0.13", "3.0.14", "3.0.15", "3.0.16", "3.0.17", "3.0.18", "3.0.19", "3.0.20", "3.0.21", "3.0.22", "3.0.23", "3.0.24", "3.0.25", "3.1.0", "3.1", "3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1.5", "3.1.6", "3.1.7", "3.1.8", "3.1.9", "3.1.10", "3.1.11", "3.1.12", "3.1.13", "3.1.14", "3.1.15", "3.1.16", "3.1.17", "3.1.18", "3.1.19", "3.1.20", "3.1.21", "3.1.22", "3.1.23", "3.1.24", "3.2.1", "3.2", "3.2.2", "3.2.3", "3.2.4"];
+    readonly generatedAt: "2026-10-13T01:26:11.275Z";
 };
 /**
  * Get the AdCP specification version this library is built for

package/dist/lib/version.js

@@ -31,8 +31,8 @@ __export(version_exports, {
   toReleasePrecisionVersion: () => toReleasePrecisionVersion
 });
 module.exports = __toCommonJS(version_exports);
-const LIBRARY_VERSION = "15.8.1";
-const ADCP_VERSION = "3.2.3";
+const LIBRARY_VERSION = "15.9.0";
+const ADCP_VERSION = "3.2.4";
 const ADCP_MAJOR_VERSION = 3;
 const COMPATIBLE_ADCP_VERSIONS = [
   "v2.5",
@@ -94,13 +94,14 @@ const COMPATIBLE_ADCP_VERSIONS = [
   "3.2.1",
   "3.2",
   "3.2.2",
-  "3.2.3"
+  "3.2.3",
+  "3.2.4"
 ];
 const VERSION_INFO = {
-  library: "15.8.1",
-  adcp: "3.2.3",
+  library: "15.9.0",
+  adcp: "3.2.4",
   compatibleVersions: COMPATIBLE_ADCP_VERSIONS,
-  generatedAt: "2026-10-11T16:14:38.709Z"
+  generatedAt: "2026-10-13T01:26:11.275Z"
 };
 function getAdcpVersion() {
   return ADCP_VERSION;

package/dist/lib/version.mjs

@@ -1,5 +1,5 @@
-const LIBRARY_VERSION = "15.8.1";
-const ADCP_VERSION = "3.2.3";
+const LIBRARY_VERSION = "15.9.0";
+const ADCP_VERSION = "3.2.4";
 const ADCP_MAJOR_VERSION = 3;
 const COMPATIBLE_ADCP_VERSIONS = [
   "v2.5",
@@ -61,13 +61,14 @@ const COMPATIBLE_ADCP_VERSIONS = [
   "3.2.1",
   "3.2",
   "3.2.2",
-  "3.2.3"
+  "3.2.3",
+  "3.2.4"
 ];
 const VERSION_INFO = {
-  library: "15.8.1",
-  adcp: "3.2.3",
+  library: "15.9.0",
+  adcp: "3.2.4",
   compatibleVersions: COMPATIBLE_ADCP_VERSIONS,
-  generatedAt: "2026-10-11T16:14:38.709Z"
+  generatedAt: "2026-10-13T01:26:11.275Z"
 };
 function getAdcpVersion() {
   return ADCP_VERSION;

package/docs/TYPE-SUMMARY.md

@@ -1,7 +1,7 @@
 # AdCP Type Summary
 
-> Generated at: 2026-10-11
-> @adcp/sdk v15.8.1
+> Generated at: 2026-10-13
+> @adcp/sdk v15.9.0
 
 Curated reference of the types that matter for using the AdCP client. For full generated types see `src/lib/types/tools.generated.ts` and `src/lib/types/core.generated.ts`.
 

package/docs/guides/CONFORMANCE.md

@@ -241,7 +241,7 @@ nightly job to broaden coverage.
 ## Canonical principal and reporting-core storyboards
 
 `@adcp/sdk/compliance-fixtures` ships the protocol-authored AdCP
-3.2.1 `universal/principal` and `universal/reporting-core`
+3.2.4 `universal/principal` and `universal/reporting-core`
 storyboards as stable, runner-ready fixtures:
 
 ```ts

package/docs/guides/FIRST-CALL-TO-A-SELLER.md

@@ -2,7 +2,7 @@
 
 An account reference selects a provisioned account at that seller. Discovery
 does not provision it. Until setup is complete, send a top-level `brand` on
-tools that support public discovery, and omit `account`.
+tools that support public discovery, and omit `account`, when your account policy permits it.
 
 ```ts
 import { AgentClient, createProductCache } from '@adcp/sdk';
@@ -50,16 +50,64 @@ completed rows to `accounts.observeSync([key], rows)` (or let the original
 `syncAccounts` completion handle update the registry). Do not resubmit unresolved tasks.
 
 For a seller that requires operator authentication, use `resolveAccount()` to
-select an active account returned by `list_accounts`. An account ID echoed by
-`sync_accounts` is a seller handle; implicit sellers still require the natural
-key on subsequent calls. Do not replace it with `{ account_id }` automatically.
+select an active account returned by `list_accounts`.
 
-`accountPolicy` defaults to `'off'` to preserve existing requests. Opt-in
+For implicit sellers, the default `accountReferenceMode: 'auto'` selects
+`{ account_id }` after provisioning only when the seller declares
+`account.stable_account_id: true` (normalized as `capabilities.account.stableAccountId`),
+or both the effective wire version and seller contract require IDs under AdCP 4+.
+For these sellers, `resolveAccount()` returns the ID reference, and requests
+using a provisioned natural key are rewritten to the same ID across discovery,
+creative sync, media buys, and other account-scoped tasks. `sync_accounts`
+provisioning and explicit `list_accounts` filters keep their authored references.
+An ID returned by a legacy implicit seller alone does not establish that IDs
+are accepted; those sellers still receive the natural key. Set
+`accountReferenceMode: 'natural-key'` to retain natural-key selection on implicit
+sellers. Explicitly supplied ID references are preserved in either mode.
+
+`resolveAccount()` still returns a wire reference by default, so existing code
+can pass the result directly as `account`. To retain the seller's handle even
+on a legacy implicit seller, request the detailed result:
+
+```ts
+const resolved = await client.resolveAccount({
+  ...account,
+  includeDetails: true,
+});
+// reference follows the seller's contract; account_id is the returned seller ID.
+const catalog = await client.getProducts({
+  account: resolved.reference,
+  buying_mode: 'brief',
+  brief: 'Display inventory',
+});
+console.log(resolved.account_id, resolved.naturalKey);
+```
+
+`naturalKey` is present for implicit provisioning; `account_id` is omitted if
+a legacy seller did not return one. A seller declaring stable IDs must return
+an ID; otherwise reference selection refuses the request with `AccountSetupRequiredError`.
+
+`accountPolicy` defaults to `'off'` to disable provisioning gates. ID selection
+still applies to known registry entries, including entries created by `accounts.ensure()`.
+Opt-in
 `'auto'` omits unknown accounts on public discovery tools that support `brand`;
 it refuses required-account discovery, async discovery, and mutations until
 the registry knows the key. `'strict'` refuses every unknown account-carrying
-request. Both policies require an active account before spend commitments.
+request. On stable-ID sellers, `'strict'` also refuses `get_products` and
+`list_products` without an account reference, even when public discovery is
+available; provision an account and supply its reference. Both policies require
+an active account before spend commitments. `sync_creatives` accepts `active`
+and `payment_required` accounts; it refuses `pending_approval`, `suspended`,
+`rejected`, and `closed` accounts. `payment_required` blocks new spend, while
+allowing creative sync and management of existing buys.
+The natural-key override changes reference selection, not strict provisioning
+requirements. `AccountNotProvisionedError.account` is `undefined` when the
+request omitted its account; check for presence before inspecting the reference.
 Explicit account filters on `list_accounts` remain filters.
+For durable retries, persist the selected wire reference with the request and
+reuse it with the same idempotency key. Switching from a natural key to an ID
+between attempts changes the request body and can cause `IDEMPOTENCY_CONFLICT`;
+the natural-key override can preserve requests authored before ID routing was enabled.
 Call `listAccounts` first when adopting these policies with existing opaque
 account IDs so the registry knows those seller handles.
 
@@ -69,9 +117,20 @@ runs do not establish accounts. After verifying an `account.status_changed`
 notification, call `client.accounts.applyStatusChange({ account_id })` to repair
 from authoritative `list_accounts`. The notification's status is not trusted as
 a snapshot, which avoids reordered deliveries overwriting current state.
+Use `client.accounts.getByAccountId(account_id)` to look up the ID alias;
+it includes `aliases` for the provisioned natural keys and is isolated by
+seller and caller scope. The lookup works in memory and after a storage-backed restart.
+Default-off stable-ID resolution also remembers recent bindings in a bounded
+routing cache while continuing to sync on every resolution. That automatic cache
+evicts old entries at capacity, including after read-only ID lookups. Calling
+`accounts.ensure()` or opting into registry configuration retains provisioning
+state and capacity checks.
 
 The registry is in memory by default. Set `accountStorage` to an adapter with
-`get(key)` and `set(key, entry)` for persistence. For multiple processes, add
+`get(key)` and `set(key, entry)` for persistence. The registry writes both
+natural-key entries and ID aliases. An optional `getByAccountId(accountId, scope)`
+storage method can read those aliases through an index; existing get/set adapters
+continue to work. For multiple processes, add
 revision-checked `compareAndSet` writes and dispatch ledger hooks; see
 [buyer storage and scheduling](BUYER-STORAGE.md). Keys partition by seller URI,
 protocol, and caller scope. Client-credentials OAuth uses the stable client ID, token endpoint, scopes, and resource. Authorization-code OAuth pins this client's initial grant fingerprint, keeping distinct user grants apart while automatic refreshes preserve its partition. Create a new client when switching users. Other credential modes fingerprint credentials;

package/docs/guides/REPORTING-LEDGER.md

@@ -565,6 +565,31 @@ ledger records together. The tombstone keeps the final revision ID and digest,
 and planners never re-create a retired period. `ledger_retained_from` advances
 because the retired obligations no longer exist.
 
+A period whose deletes fail (a removed binding, a permanent provider error)
+stays `retiring` and is retried with backoff rather than on every pass. The
+tombstone records `attempts`, `next_attempt_at` and `last_failure`; the wait
+starts at one minute, doubles per failure and is capped at six hours. Periods
+still backing off are skipped. Ready retries go ahead of fresh periods for up to
+half of each pass (rounded up) and only fill slots fresh periods leave empty, so
+a retry backlog still drains at full speed when nothing else is eligible and a
+few stuck periods cannot stop others from retiring (each leaves the head of the
+queue for its backoff after one failed attempt). The result reports `failed` and `failures` for this pass,
+`deferred` for periods backing off, and `stuck` (up to 20, with `attempts` and
+`cause`) for periods that have failed five or more times. The maintenance helper
+passes `stuck` and `deferred` to `onError`. Re-apply `REPORTING_LEDGER_MIGRATION`
+before upgrading; it adds the three tombstone columns idempotently.
+
+`sweepRowWriteIntents` backs off the same way (`sweep_attempts`, `next_sweep_at`,
+added idempotently by `REPORTING_ROW_STORAGE_MIGRATION`) and takes intents that
+never failed first. An intent with objects to delete through a binding this host
+does not configure is left untouched, since a host that configures it can finish
+the sweep. The result counts `swept`, `objectsDeleted`, `failed` (this pass),
+`skippedUnconfigured`, `deferred` and `overdue`; the last three describe what is
+still waiting after the pass. `overdue` counts intents expired for longer than
+`overdueAfterSeconds` (default 24 hours): no host is sweeping them and their
+objects are leaking, so check that some host configures every binding you have
+used.
+
 `createPostgresReliableReportingProductionService` accepts
 `retention: { enabled: true, recordRetentionDays?, limit? }`. Its scheduler
 always sweeps abandoned row uploads and expired cursor snapshots and
@@ -791,11 +816,52 @@ await store.saveFeedConsumerCursor('pacing', page.cursor); // holds back pruning
   changes. Account feeds order by sequence. The deployment-wide feed (omit
   `account_id`) orders by `(xid, seq)` and returns only changes whose
   transaction precedes every transaction still in flight, so a slow commit is
-  never skipped.
+  never skipped. The account feed applies the same guard: a page ends before the
+  first change whose transaction has not finished (`xid` at or above the reading
+  snapshot's `xmin`), so the cursor never passes a change that commits late. The
+  page is cut there rather than filtered, because seq order and xid order can
+  differ and a filter would hand out a later change while skipping an earlier
+  one it excluded. The cost is that any older open transaction on the cluster,
+  including an idle one in another database, holds both kinds of feed back until
+  it ends; keep transactions short. An empty page therefore means either caught
+  up or held back, so poll again rather than treating it as the end of the feed.
+- **A ledger database has exactly one writer SDK.** The store writes each change
+  row under the account advisory lock, taking the sequence value only after it,
+  so per-account `seq` order equals commit order. The in-flight guard above is
+  defense in depth, not a substitute: a second SDK (for example a Python
+  deployment, or a hand-written writer) that takes a different lock key, or
+  writes change rows outside the account lock, can allocate a lower `seq` that
+  commits after a higher one. The guard narrows that window but cannot close it
+  for every interleaving, so run one writer SDK per ledger database and give
+  another SDK its own database. `pruneChanges` only deletes changes older than
+  `changeRetentionDays`, far longer than any transaction should stay open, and
+  consumer holds compare against cursors the feed itself returned, so neither
+  adds a new ordering assumption.
 - `pruneChanges` deletes changes older than `changeRetentionDays` (default 30)
   that every consumer updated within `maxFeedHoldDays` (default 7) has passed.
   An older cursor throws `ReportingChangeCursorExpiredError`; resynchronize from
   `listCurrentRevisions`.
+- A read with no cursor can throw `ReportingChangeCursorExpiredError` too. `changesAfter`
+  re-reads the retention horizon after the page, so a prune that commits during
+  a consumer's first read rejects that page instead of returning one that skips
+  the pruned changes. Host startup code must handle `CURSOR_EXPIRED` on a first
+  read the same way as on a saved cursor: retry (the new read starts at the later
+  horizon) or resynchronize from `listCurrentRevisions`. Match on
+  `error.code === 'CURSOR_EXPIRED'` rather than `instanceof`, which fails when
+  the store and your code load through different module formats (CJS and ESM).
+- Consumer checkpoints are forward-only. `saveFeedConsumerCursor(name, cursor)`
+  ignores a cursor behind the saved one in the same feed scope, so a delayed or
+  stale acknowledgment cannot pull the retention hold backward. It resolves
+  `true` when the checkpoint was written and `false` when it was ignored (an
+  equal position also resolves `false` with `{ refreshUnchanged: false }`). To
+  rewind a consumer on purpose, for example to replay changes, pass
+  `{ rewind: true }`; the saved position and retention hold move back to that
+  cursor (the write always applies, and the cursor is not checked against the
+  retention horizon, so it must still be inside the retained history). Without it a rewound
+  consumer would keep its old, newer hold, pruning could remove exactly what it
+  is about to read, and its next read would throw `CURSOR_EXPIRED`.
+  `removeFeedConsumer(name)` unregisters a consumer so it stops holding back
+  pruning; it resolves `true` when a registration was removed.
 - Period retention honours the same hold: `retireExpiredPeriods` does not retire
   a period while a live consumer has not read its changes. A consumer that
   stays silent past `maxFeedHoldDays` stops holding, and its unread changes can
@@ -818,10 +884,11 @@ import {
 } from '@adcp/sdk/reporting/bigquery';
 
 await pool.query(REPORTING_WAREHOUSE_SINK_MIGRATION); // after REPORTING_LEDGER_CHANGES_MIGRATION
+const bigquery = new BigQuery({ projectId: 'analytics-prod' }); // ADC / workload identity
 const sink = createBigQueryReportingWarehouseSinkV1({
   store, // PostgresReportingLedgerStore with changeFeed: true
   db: pool,
-  bigquery: new BigQuery({ projectId: 'analytics-prod' }), // ADC / workload identity
+  bigquery,
   name: 'warehouse',
   projectId: 'analytics-prod',
   datasetId: 'reporting',
@@ -829,11 +896,12 @@ const sink = createBigQueryReportingWarehouseSinkV1({
   revisionsTableId: 'media_buy_delivery_revisions',
   location: 'US',
   mapRow: row => ({ media_buy_id: row.media_buy_id, impressions: row.impressions, spend: row.spend }),
-  labels: { component: 'adcp-reporting' },
 });
 await bigquery.query({ query: sink.defaultTablesSql }); // or create your own tables
 await bigquery.query({ query: sink.currentRowsViewSql });
-setInterval(() => void sink.runOnce(), 15 * 60_000);
+setInterval(() => {
+  void sink.runOnce().catch(error => console.error('Warehouse run failed', error));
+}, 15 * 60_000);
 ```
 
 - Each run follows the change feed and reads every revision's rows through the
@@ -847,6 +915,77 @@ setInterval(() => void sink.runOnce(), 15 * 60_000);
   same batch under the same job ID, which BigQuery refuses to run twice. A job
   that finished with an error is retried under a new attempt for that table
   only.
+- `projectId` scopes both load submission and replay status checks. When it is
+  omitted, both use the BigQuery client's default project. Each replica must
+  be able to read the BigQuery jobs submitted by the other replicas.
+- `loadTimeoutMilliseconds` (default 10 minutes) is a client-side deadline for
+  one load. When a load passes it, the sink asks BigQuery to cancel that job by
+  its deterministic ID, in `projectId` and `location`, and rejects with the
+  plan retained. The next run finds the cancelled job finished with an error,
+  advances that table's attempt and rejects; the run after that loads under the
+  new attempt. If the cancel has not taken effect yet it waits for the job.
+  Each attempt doubles the load deadline (up to 6 hours), so a slow but healthy
+  load converges; set the deadline above your slowest expected load to avoid
+  the cancelled attempts. Cancellation is best effort (BigQuery may finish the
+  job anyway, which the next run then accepts), a failed cancel other than "not
+  found" raises a `ADCP_BIGQUERY_SINK_CANCEL_FAILED` process warning, and a
+  status check that times out is not cancelled. BigQuery's server-side
+  `jobTimeoutMs` is not used: for a local-file load the official client builds
+  `configuration.load` from the load options and cannot set job-level fields,
+  and BigQuery silently drops `labels` and `jobTimeoutMs` found inside
+  `configuration.load`. (Staging the file in GCS and submitting the load with
+  `bigquery.createJob` can set both; the sink does not stage files.) For the
+  same reason the `labels` option has no effect (it warns once per process and
+  is deprecated). To attribute load cost, query
+  `` `region-<location>`.INFORMATION_SCHEMA.JOBS_BY_PROJECT `` (needs
+  `bigquery.jobs.listAll`; about 180 days of history), filtering on
+  `STARTS_WITH(job_id, 'adcp_rr_')` or on `destination_table`, and summing
+  `total_slot_ms` or `total_bytes_billed`.
+- Overlapping runs atomically claim one durable batch. Replays use that
+  batch's job IDs; attempts and cursor commits compare the full saved plan.
+  A stale run rejects without replacing another batch or rewinding either
+  the warehouse cursor or its feed checkpoint. Catch the rejection and retry
+  `runOnce()` on the next tick. Empty-feed cursor initialization uses the
+  same claim and commit rules. Replicas sharing a sink name must use the same
+  ledger database, feed scope, destination, location and row mapping. Use a new
+  name when that configuration changes. Independent ledgers loading into the
+  same BigQuery project must use distinct sink names, even if their destination
+  tables differ. An idle tick drains non-revision changes through the
+  same fenced checkpoint. An idle tick also recovers a failed acknowledgment
+  without refreshing an unchanged checkpoint. Failed loads and idle ticks
+  behind the deployment feed's transaction fence can still age out after
+  `maxFeedHoldDays`.
+- Feed reads recheck the retention horizon before returning a page. If pruning
+  overtakes the starting position during a read, `runOnce()` rejects with
+  `ReportingChangeCursorExpiredError` before committing the page.
+  The non-revision fallback preserves the first read's cursor, including on
+  initial startup. If retention overtakes the initial read, the sink records
+  that starting cursor before rejecting, so later ticks and restarted workers
+  continue to report the gap. This does not acknowledge the missing changes or
+  renew their retention hold. Resynchronize from current revisions before resuming.
+- A brand-new sink can hit that rejection from a harmless startup race: pruning
+  commits during its very first read, after the changes it lost were already
+  past retention and held by nobody. Every later tick then rejects with
+  `CURSOR_EXPIRED` because the sink keeps reporting that gap. Clear it with
+  `await sink.reset()`, which resets the sink to start from the oldest retained
+  change and unregisters its feed consumer (stop every worker with that sink
+  name first; do not edit `adcp_reporting_warehouse_sinks` by hand). `reset()`
+  refuses while a batch plan is retained, because that batch's BigQuery load
+  jobs may have succeeded; reconcile the plan against BigQuery, then call
+  `reset({ discardRetainedPlan: true })`. It does not touch the warehouse: a sink
+  that already loaded history reloads the retained revisions, so empty the
+  destination tables first or use a new sink name against new tables. Every
+  reset starts a new job ID generation, so reloaded batches submit fresh BigQuery
+  jobs instead of matching the finished jobs of the earlier history. Nothing holds
+  change retention between `reset()` and the first committed batch. If `reset()`
+  rejects after clearing the sink (it could not unregister the consumer), call
+  it again before restarting workers. Re-run `REPORTING_WAREHOUSE_SINK_MIGRATION`
+  after upgrading: it adds the `reset_generation` column.
+- Stop old sink workers before relying on these overlap guarantees. If an
+  earlier overlapping run left a plan whose starting cursor differs from the
+  committed cursor, the sink rejects it before loading. Reconcile the retained
+  plan, its BigQuery jobs and warehouse rows before repairing the checkpoint.
+  Do not discard the plan automatically: its load jobs may have succeeded.
 - Query `current_rows`, not the raw rows table. Pacing snapshots are
   cumulative, so summing across revisions double-counts. The view keeps each
   obligation's current revision.
@@ -855,7 +994,9 @@ setInterval(() => void sink.runOnce(), 15 * 60_000);
   loaded yet, in both cases only while its cursor was saved within
   `maxFeedHoldDays`. Superseded snapshots are the intraday pacing curve, and the
   warehouse may keep them as long as you like.
-- `runOnce()` resolves with `{ idle, revisions, rows, missing }`. `missing`
+- `runOnce()` resolves with `{ idle, revisions, rows, missing }`. `idle` means
+  no revision changes were selected for this batch; an idle tick can still advance
+  past non-revision feed changes without submitting load jobs. `missing`
   lists revision IDs the feed announced that were retired before the batch ran.
   A non-empty `missing` means the sink fell behind retention (it was down longer
   than `maxFeedHoldDays` plus the retention window): the warehouse lacks those
@@ -889,6 +1030,9 @@ await managedStore.authorizeDestination({
   destination_ref: destinationRef,
   generation: 1,
   authorized_at: new Date().toISOString(),
+  // The delivery contract this generation serves, recorded once and immutable.
+  pattern: 'file_transfer',
+  transport: 'gcs',
 });
 await managedStore.installBinding(
   reportingManagedDeliveryBindingV1({
@@ -925,6 +1069,56 @@ const reportingDelivery = managed.reportingDeliveryCapabilities;
 await managed.runWorker({ maxIterations: 100 });
 ```
 
+### Pattern and transport on a destination authorization
+
+A destination has exactly one delivery pattern, and a change to its delivery contract mints a new `destination_ref` generation, so the pattern and transport are fixed for an authorization generation. Pass `pattern` (`file_transfer`, `dataset_share`, `warehouse_materialization`) and `transport` (the same lowercase token the offering's `method.transport` uses, such as `gcs` or `s3`) to `authorizeDestination()` when you create the generation. The store records them in `pattern`/`transport` columns and returns them on the authorization that `claimRevocation()` hands to `adapter.revoke()`, so a revocation can be routed to the transport that holds the provider grant instead of being guessed or fanned out.
+
+- Both are optional, and `transport` requires `pattern`. A generation recorded without them stays valid and revocable; it is simply unroutable by transport.
+- They are immutable. Replaying `authorizeDestination()` for the current generation may omit them but cannot state different values, and it cannot add them to a generation recorded without. Change the contract by minting a new generation.
+- `installBinding()` rejects a binding whose `method` or `transport` differs from what its generation recorded, so one generation can never be delivered through one transport and revoked through another.
+- Upgrading: `REPORTING_MANAGED_DELIVERY_MIGRATION` is additive (`ADD COLUMN IF NOT EXISTS`) and safe to re-run. The run that adds the columns backfills each existing generation from the bindings that reference it, but only where every such binding names the same method and the same transport. A generation whose bindings disagree, name no transport, or do not exist is left NULL, and the migration raises a `NOTICE` with how many. Later runs do nothing, so a NULL generation is never re-decided by a binding that arrived afterwards. `managedStore.listDestinationAuthorizationsWithoutContract()` lists the NULL generations with a `reason` (`no_binding`, `binding_without_transport`, `bindings_disagree`, `not_recorded`) so you can see which still need handling.
+
+### Multi-transport delivery with the router
+
+A seller often delivers one feed through several transports: one buyer takes files in a GCS bucket, another in S3. A runtime takes one adapter, so install a router that is itself a `ReportingManagedDeliveryAdapterV1` and dispatches to one adapter per `(pattern, transport)`. The router is pure dispatch with no state of its own, so the store and worker keep every fence they provide today: leases, the authorization-generation check, settlement, the retry and attempt cap, and revocation SLA accounting, per materialization and whichever route served it.
+
+```ts
+import {
+  createReportingManagedDeliveryAdapterRouterV1,
+  createReportingManagedDeliveryRuntime,
+} from '@adcp/sdk/reporting/ledger';
+
+const adapter = createReportingManagedDeliveryAdapterRouterV1({
+  routes: [
+    { id: 'gcs', match: { pattern: 'file_transfer', transport: 'gcs' }, adapter: gcsAdapter },
+    { id: 's3', match: { pattern: 'file_transfer', transport: 's3' }, adapter: s3Adapter },
+  ],
+  // Optional. Only for bindings and authorizations recorded before a transport was.
+  legacyDefault: 'gcs',
+});
+
+const managed = await createReportingManagedDeliveryRuntime({ /* ... */ adapter });
+// or: createPostgresReliableReportingProductionService({ /* ... */ managedDelivery: { adapter, /* ... */ } })
+```
+
+How a route is chosen:
+
+- `deliver()` and `read()` select from the immutable binding alone: `binding.method` (the pattern) and `binding.transport`. They never look at request input, materialization state or the resource.
+- `revoke()` selects from the `pattern` and `transport` recorded on the destination authorization generation (see above). It calls exactly one adapter and never fans out.
+- Anything that cannot be routed throws a typed `ReportingManagedDeliveryRoutingErrorV1` (`code`: `REPORTING_ROUTE_NOT_FOUND`, `REPORTING_ROUTE_TRANSPORT_REQUIRED`, `REPORTING_ROUTE_CONTRACT_UNRECORDED`, `REPORTING_ROUTE_VERIFICATION_UNSUPPORTED`) before any adapter is called. A failed delivery is an ordinary failed attempt and counts toward the attempt cap. A failed revocation is released for retry and counted as overdue once it outlives `authorization_revocation_seconds`, so an unroutable grant is visible, not silent.
+- A binding with no `transport`, and an authorization with no recorded pattern/transport, go to `legacyDefault` if you configured one (and, for a pattern that is stated, only if it is that route's pattern); otherwise they fail as above. A recorded transport with no route never falls back to `legacyDefault`: the router will not guess which provider holds the grant.
+
+Construction throws if route ids repeat, if two routes match the same `(pattern, transport)`, if a route adapter does not declare `revocationFencesDeliveryGenerations: true`, or if a route has an empty `verificationProfiles`. The router's own `verificationProfiles` is the union of its routes' and exists only for compatibility; it never admits a binding.
+
+Admission happens at install and at startup, not at first delivery:
+
+- `createReportingManagedDeliveryRuntime` registers the router's `admitBinding` with the store (`setBindingAdmission`), so `installBinding` refuses a binding whose pattern/transport has no route, or whose `verification_profile` is not one of that route's `verificationProfiles`, before it writes anything. The refusal is the router's own typed error. A runtime whose adapter provides `admitBinding` refuses a store that cannot enforce it. Single adapters define no such hook and behave exactly as before.
+- At runtime construction every advertised managed offering's `method` (pattern and transport) must have a route, and a consumer-receipt offering needs a route that supports `canonical_digest`. Bindings installed before you adopted the router are not re-checked at startup; they fail at delivery with the typed error unless `legacyDefault` takes them.
+
+Optional adapter probe: an adapter may define `probe({ signal })`, which must not mutate provider state. The router probes every route that defines one, concurrently and each within `probeTimeoutMilliseconds` (default 10 seconds; it must be below the runtime's 30 second probe deadline so a hung route is still named), and the runtime calls it before it adopts any durable policy. A failure stops startup with an error naming the failing route id (`Managed Delivery adapter probe failed for route "s3"`); the provider's own message stays on `cause` and out of the message. Offerings are not withdrawn dynamically: fix the route or remove it, then restart.
+
+Observability: when the adapter is a router, `runWorker()` results also carry per-route counts keyed by route id: `deliveriesByRoute`, `deliveryFailuresByRoute`, `revocationsByRoute`, `revocationFailuresByRoute` and `overdueByRoute`. Work no route could take is counted under `UNROUTED_REPORTING_ROUTE_KEY_V1` (`'~unrouted'`, which no route id can equal). The counts carry route ids only, never credentials, locations or provider messages. A single-adapter runtime's result shape is unchanged.
+
 Deployment-wide materialization planning is durably round-robin. The PostgreSQL
 store advances an agent-wide cursor before processing its bounded account page
 and gives every selected account a first-pass share before unused capacity