@adcp/sdk 16.0.0-beta.3 → 16.0.0-beta.4

package/dist/lib/version.d.mts

@@ -1,7 +1,7 @@
 /**
  * AdCP SDK library version
  */
-export declare const LIBRARY_VERSION = "16.0.0-beta.3";
+export declare const LIBRARY_VERSION = "16.0.0-beta.4";
 /**
  * AdCP specification version this library is built for
  */
@@ -33,10 +33,10 @@ export type AdcpVersion = (typeof COMPATIBLE_ADCP_VERSIONS)[number];
  * Full version information
  */
 export declare const VERSION_INFO: {
-    readonly library: "16.0.0-beta.3";
+    readonly library: "16.0.0-beta.4";
     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-15T18:57:32.995Z";
+    readonly generatedAt: "2026-10-16T14:15:27.258Z";
 };
 /**
  * Get the AdCP specification version this library is built for

package/dist/lib/version.d.ts

@@ -1,7 +1,7 @@
 /**
  * AdCP SDK library version
  */
-export declare const LIBRARY_VERSION = "16.0.0-beta.3";
+export declare const LIBRARY_VERSION = "16.0.0-beta.4";
 /**
  * AdCP specification version this library is built for
  */
@@ -33,10 +33,10 @@ export type AdcpVersion = (typeof COMPATIBLE_ADCP_VERSIONS)[number];
  * Full version information
  */
 export declare const VERSION_INFO: {
-    readonly library: "16.0.0-beta.3";
+    readonly library: "16.0.0-beta.4";
     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-15T18:57:32.995Z";
+    readonly generatedAt: "2026-10-16T14:15:27.258Z";
 };
 /**
  * Get the AdCP specification version this library is built for

package/dist/lib/version.js

@@ -31,7 +31,7 @@ __export(version_exports, {
   toReleasePrecisionVersion: () => toReleasePrecisionVersion
 });
 module.exports = __toCommonJS(version_exports);
-const LIBRARY_VERSION = "16.0.0-beta.3";
+const LIBRARY_VERSION = "16.0.0-beta.4";
 const ADCP_VERSION = "3.2.4";
 const ADCP_MAJOR_VERSION = 3;
 const COMPATIBLE_ADCP_VERSIONS = [
@@ -98,10 +98,10 @@ const COMPATIBLE_ADCP_VERSIONS = [
   "3.2.4"
 ];
 const VERSION_INFO = {
-  library: "16.0.0-beta.3",
+  library: "16.0.0-beta.4",
   adcp: "3.2.4",
   compatibleVersions: COMPATIBLE_ADCP_VERSIONS,
-  generatedAt: "2026-10-15T18:57:32.995Z"
+  generatedAt: "2026-10-16T14:15:27.258Z"
 };
 function getAdcpVersion() {
   return ADCP_VERSION;

package/dist/lib/version.mjs

@@ -1,4 +1,4 @@
-const LIBRARY_VERSION = "16.0.0-beta.3";
+const LIBRARY_VERSION = "16.0.0-beta.4";
 const ADCP_VERSION = "3.2.4";
 const ADCP_MAJOR_VERSION = 3;
 const COMPATIBLE_ADCP_VERSIONS = [
@@ -65,10 +65,10 @@ const COMPATIBLE_ADCP_VERSIONS = [
   "3.2.4"
 ];
 const VERSION_INFO = {
-  library: "16.0.0-beta.3",
+  library: "16.0.0-beta.4",
   adcp: "3.2.4",
   compatibleVersions: COMPATIBLE_ADCP_VERSIONS,
-  generatedAt: "2026-10-15T18:57:32.995Z"
+  generatedAt: "2026-10-16T14:15:27.258Z"
 };
 function getAdcpVersion() {
   return ADCP_VERSION;

package/docs/TYPE-SUMMARY.md

@@ -1,7 +1,7 @@
 # AdCP Type Summary
 
-> Generated at: 2026-10-15
-> @adcp/sdk v16.0.0-beta.3
+> Generated at: 2026-10-16
+> @adcp/sdk v16.0.0-beta.4
 
 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`.
 
@@ -2900,9 +2900,23 @@ interface InlineReportingAvailabilityEvidenceV1 {
 
 ## Seller Reporting Ledger
 
-Ledger symbols import from `@adcp/sdk/reporting/ledger`; `createPostgresPersistentNotificationRuntime` is a server symbol and imports from `@adcp/sdk/server`.
+The ledger interface, handlers and producer import from `@adcp/sdk/reporting/ledger`. The PostgreSQL store, its migrations, row storage and maintenance import from `@adcp/reporting-storage`, managed delivery from `@adcp/reporting-storage/managed` and notification activity from `@adcp/reporting-storage/notifications` (install `@adcp/reporting-storage` next to `@adcp/sdk`; it is pre-1.0 and every export is experimental). `createPostgresPersistentNotificationRuntime` is a server symbol and imports from `@adcp/sdk/server`.
 
 ```typescript
+import { Pool } from 'pg';
+import { createPostgresPersistentNotificationRuntime } from '@adcp/sdk/server';
+import {
+  createReportingDeliveryHandler,
+  createReportingProducer,
+  createReportingStatusHandler,
+  createSyncReportingStatusHandler,
+} from '@adcp/sdk/reporting/ledger';
+import { PostgresReportingLedgerStore, REPORTING_LEDGER_MIGRATION } from '@adcp/reporting-storage';
+import {
+  createPostgresReportingNotificationActivityRuntime,
+  createPostgresReportingNotificationAttemptCheckpoint,
+} from '@adcp/reporting-storage/notifications';
+
 // Build the notification path first: the store must be constructed with the
 // activity port, or lifecycle transitions record no activity and notify nobody.
 const attemptCheckpoint = createPostgresReportingNotificationAttemptCheckpoint({
@@ -2965,6 +2979,9 @@ The store freezes configuration lineage and period-end denominators, retains imm
 Import from `@adcp/sdk/reporting/service`. This is the adapter-first lifecycle owner over the source and ledger primitives; it does not introduce another store or transport.
 
 ```typescript
+import { createReliableReportingService } from '@adcp/sdk/reporting/service';
+import { PostgresReportingLedgerStore, reportingLedgerMaintenance } from '@adcp/reporting-storage';
+
 interface ReliableReportingAdapterV1 {
   readonly sourceOffering: ReportingSourceOfferingV1;
   readonly deliveryOffering: ReportingDeliveryOffering;
@@ -2987,9 +3004,10 @@ const reporting = createReliableReportingService({
   resolveCurrency: account => currency,
   resolveCoverage: account => ({ constituents }), // authorized media-buy/package denominator
   resolveConsumerId, // optional; controls consumer-status handler/capability
+  maintenance: reportingLedgerMaintenance({ retention: { enabled: true } }), // optional factory from @adcp/reporting-storage
 });
 
-await pool.query(reporting.setup.migrations[0]);
+for (const sql of reporting.setup.migrations) await pool.query(sql);
 const installedPlatform = reporting.install(platform);
 await reporting.installConfiguration(configuration, { account: ctx.account });
 await reporting.runCycle({ accountId }); // tenant-partitioned
@@ -2999,7 +3017,7 @@ await reporting.stop();
 
 Account identity comes only from the framework-resolved context. Trusted host callbacks derive adapter routing, credential-free `sourceScope`, source timezone, currency, and the authorized constituent denominator. A declaration cannot supply `account`, `sourceScope`, `sourceTimezone`, `contract`, `currency`, `constituents`, or `mediaBuyIds`; `mediaBuyIds` is derived from `resolveCoverage`, so a buyer cannot name another buyer's media buys on a shared upstream network. Currency is frozen into configuration and obligation lineage. Capabilities are Core-only and derived from installed adapters and handlers; managed delivery, reconciled billing, receipts, webhook activity, and notifications are not advertised. Installation requires `platform.accounts.upsert`, which owns the advertised `sync_accounts` configuration path.
 
-For complete seller production assembly, use async `createPostgresReliableReportingProductionService` from `@adcp/sdk/reporting/service`. It owns the PostgreSQL Core/Managed stores, receipts, all three reporting notifications, webhook activity, migrations, probes, recovery, and capability publication. Supply `activity.tenantScopeForAccount`; Reconciled Billing offerings also require a trusted `obligatedConsumers` roster. Its scheduler and `recoverOnce` require explicit `deploymentWide: true` because recovery scans the whole namespace. See `docs/guides/REPORTING-LEDGER.md` and `docs/guides/REPORTING-OPERATIONS.md`.
+For complete seller production assembly, use async `createPostgresReliableReportingProductionService` from `@adcp/reporting-storage/service`. It owns the PostgreSQL Core/Managed stores, receipts, all three reporting notifications, webhook activity, migrations, probes, recovery, and capability publication. Supply `activity.tenantScopeForAccount`; Reconciled Billing offerings also require a trusted `obligatedConsumers` roster. Its scheduler and `recoverOnce` require explicit `deploymentWide: true` because recovery scans the whole namespace. See `docs/guides/REPORTING-LEDGER.md` and `docs/guides/REPORTING-OPERATIONS.md`.
 
 Buyer production processes use `createPostgresReportingConsumerRuntimeV1` with `createReliableReportingConsumerV1` from the package root. Verify webhook signatures before passing authenticated hints, preserve seller/principal scope, and configure `evaluateAdjustment` to authorize integrity-valid post-official corrections; the default defers them. See `docs/guides/REPORTING-RECONCILIATION.md`.
 

package/docs/guides/REPORTING-GCS-FENCE.md

@@ -1,12 +1,12 @@
 # Durable GCS reporting write fence
 
-`@adcp/sdk/reporting/gcs` provides a provider write-fence primitive backed by the existing PostgreSQL destination authority. It is a building block for a managed delivery adapter; it does not advertise Managed Delivery or Reconciled Billing capabilities or implement `ReportingManagedDeliveryAdapterV1`.
+`@adcp/reporting-storage/gcs` provides a provider write-fence primitive backed by the existing PostgreSQL destination authority. It is a building block for a managed delivery adapter; it does not advertise Managed Delivery or Reconciled Billing capabilities or implement `ReportingManagedDeliveryAdapterV1`.
 
-Install the optional official Google client with `npm install @google-cloud/storage@^7.22.0` for Node 20 or Node 22+. Google client `^8.2.0` is also supported on Node 22+. This peer is required when compiling or using the GCS subpath, including its public types; other SDK subpaths remain independent. Apply `REPORTING_LEDGER_MIGRATION`, `REPORTING_MANAGED_DELIVERY_MIGRATION`, then the additive `REPORTING_OBJECT_WRITE_MIGRATION` from `@adcp/sdk/reporting/ledger` in the same isolated tenant schema. Apply the final migration to a fresh object-write schema if experimenting with earlier, unpublished versions of these tables: `CREATE TABLE IF NOT EXISTS` does not upgrade incompatible prerelease tables.
+Install the optional official Google client with `npm install @google-cloud/storage@^7.22.0` for Node 20 or Node 22+. Google client `^8.2.0` is also supported on Node 22+. This peer is required when compiling or using the GCS subpath, including its public types; other subpaths remain independent. Apply `REPORTING_LEDGER_MIGRATION`, `REPORTING_MANAGED_DELIVERY_MIGRATION`, then the additive `REPORTING_OBJECT_WRITE_MIGRATION` from `@adcp/reporting-storage` (and `@adcp/reporting-storage/managed` for the managed-delivery one) in the same isolated tenant schema. Apply the final migration to a fresh object-write schema if experimenting with earlier, unpublished versions of these tables: `CREATE TABLE IF NOT EXISTS` does not upgrade incompatible prerelease tables.
 
 ```typescript
 import { Storage } from '@google-cloud/storage';
-import { createGcsReportingObjectFenceV1 } from '@adcp/sdk/reporting/gcs';
+import { createGcsReportingObjectFenceV1 } from '@adcp/reporting-storage/gcs';
 
 const fence = createGcsReportingObjectFenceV1({
   storage: new Storage({ retryOptions: { totalTimeout: 60, maxRetries: 3 } }), // Host-owned ADC; retry timeout is in seconds.

package/docs/guides/REPORTING-GCS-MANAGED.md

@@ -1,17 +1,17 @@
 # Managed reporting delivery on GCS
 
-`@adcp/sdk/reporting/gcs` supplies a complete `ReportingManagedDeliveryAdapterV1` for private GCS file transfer. It supports `manifest_checksums` and `canonical_digest` by uploading deterministic JSONL and manifest bytes, then inspecting actual provider bytes and digest-pinned private contracts. The managed runtime owns materialization settlement, cleanup leases, retries and capability publication. Verification is attributed to the producer; independent buyer qualification is a separate gate.
+`@adcp/reporting-storage/gcs` supplies a complete `ReportingManagedDeliveryAdapterV1` for private GCS file transfer. It supports `manifest_checksums` and `canonical_digest` by uploading deterministic JSONL and manifest bytes, then inspecting actual provider bytes and digest-pinned private contracts. The managed runtime owns materialization settlement, cleanup leases, retries and capability publication. Verification is attributed to the producer; independent buyer qualification is a separate gate.
 
 Install the optional official `@google-cloud/storage` peer. Use 7.22.x on Node 20.19 or later; Storage 8.2.x requires Node 22 or later. The default SDK import does not load Google Storage. Supply a host-owned official Storage client using ADC, workload identity or short-lived impersonation. Never persist credentials in reporting descriptors, contract URIs, `ctx_metadata`, inventory or error envelopes.
 
-Apply `REPORTING_LEDGER_MIGRATION`, the applicable Core writer-fence migration, `REPORTING_MANAGED_DELIVERY_MIGRATION`, `REPORTING_OBJECT_WRITE_MIGRATION`, then `REPORTING_OBJECT_WRITE_AUTHORITY_MIGRATION` from `@adcp/sdk/reporting/ledger`. The last migration requires PostgreSQL 13 or later and creates one persistent installation UUID per isolated schema. Reapplying it preserves the UUID. Keep that row in backups and restores. **Never run delivery or cleanup from an independently writable clone of live authorization, inventory or materialization tables.** Such a clone would still address the original objects. Start a fresh isolated schema with a distinct deployment namespace and installation UUID, provision new destination grants, and import only the needed immutable Core facts. A restored replica of the same authority keeps its identity. Do not replace an identity while old write plans still exist. The adapter combines the UUID with your stable deployment namespace to avoid collisions between isolated schemas sharing a bucket.
+Apply `REPORTING_LEDGER_MIGRATION`, the applicable Core writer-fence migration, `REPORTING_MANAGED_DELIVERY_MIGRATION`, `REPORTING_OBJECT_WRITE_MIGRATION`, then `REPORTING_OBJECT_WRITE_AUTHORITY_MIGRATION` from `@adcp/reporting-storage` (`REPORTING_MANAGED_DELIVERY_MIGRATION` is on `@adcp/reporting-storage/managed`). The last migration requires PostgreSQL 13 or later and creates one persistent installation UUID per isolated schema. Reapplying it preserves the UUID. Keep that row in backups and restores. **Never run delivery or cleanup from an independently writable clone of live authorization, inventory or materialization tables.** Such a clone would still address the original objects. Start a fresh isolated schema with a distinct deployment namespace and installation UUID, provision new destination grants, and import only the needed immutable Core facts. A restored replica of the same authority keeps its identity. Do not replace an identity while old write plans still exist. The adapter combines the UUID with your stable deployment namespace to avoid collisions between isolated schemas sharing a bucket.
 
 Core and managed stores must share the exact same PostgreSQL pool, and Core must enable `managedDelivery: true`. The factory probes both stores and the provider policy before returning an adapter. Hosts supply pool acquisition/connect timeouts; transactions started with a signal additionally limit lock and statement waits. Readiness is bounded by the operation deadline, at most 60 seconds.
 
 ```typescript
 import { Storage } from '@google-cloud/storage';
-import { createGcsReportingManagedDeliveryAdapterV1 } from '@adcp/sdk/reporting/gcs';
-import { createReportingManagedDeliveryRuntime } from '@adcp/sdk/reporting/ledger';
+import { createGcsReportingManagedDeliveryAdapterV1 } from '@adcp/reporting-storage/gcs';
+import { createReportingManagedDeliveryRuntime } from '@adcp/reporting-storage/managed';
 
 const adapter = await createGcsReportingManagedDeliveryAdapterV1({
   storage: new Storage(), // ADC/workload identity; no keys in reporting state

package/docs/guides/REPORTING-LEDGER-CUTOVER.md

@@ -3,7 +3,7 @@
 This guide is for a seller that already runs its own Reliable Reporting ledger
 (tables for configuration generations, obligations and revisions, row files in
 object storage and a warehouse, status issues and transitions) and wants
-`@adcp/sdk` to own the ledger from now on. Read the
+`@adcp/sdk` and `@adcp/reporting-storage` to own the ledger from now on. Read the
 [ledger guide](REPORTING-LEDGER.md) first for the SDK side, and the
 [operations runbook](REPORTING-OPERATIONS.md) for production practice.
 
@@ -28,7 +28,7 @@ You have two ways to run the SDK's service on top of what you have.
 | Change feed | `changeFeed: true`: `changesAfter`, current-revision reads, consumer cursors | You implement it, or go without host reads and the warehouse sink |
 | Retention | `maintenance.retention`: period-aligned retirement honouring the change-feed hold | You implement `retireExpiredPeriods` and tombstones, or never retire |
 | Maintenance | `maintenance`: snapshot sweep, abandoned-upload sweep, feed pruning | You write all of it |
-| Warehouse | `@adcp/sdk/reporting/bigquery` sink | Not available: it reads the SDK store |
+| Warehouse | `@adcp/reporting-storage/bigquery` sink | Not available: it reads the SDK store |
 | Correctness | Lease fencing, gap-free status checkpoints, immutable generations and the revision binding are enforced in one tested place | Every one of those guarantees is yours to prove |
 | Existing data | Starts empty; old tables stay behind a read-only hook | Old data served natively |
 
@@ -52,8 +52,8 @@ advertise Managed Delivery or Reconciled Billing today, read
 ```ts
 import { Pool } from 'pg';
 import { Storage } from '@google-cloud/storage';
-import { PostgresReportingLedgerStore } from '@adcp/sdk/reporting/ledger';
-import { createGcsReportingRowObjectProviderV1 } from '@adcp/sdk/reporting/gcs';
+import { PostgresReportingLedgerStore, reportingLedgerMaintenance } from '@adcp/reporting-storage';
+import { createGcsReportingRowObjectProviderV1 } from '@adcp/reporting-storage/gcs';
 import { createReliableReportingService } from '@adcp/sdk/reporting/service';
 
 // Apply once, in order, with your migration owner (PostgreSQL 13+):
@@ -86,10 +86,10 @@ const reporting = createReliableReportingService({
   statusRetentionDays: 90, // the commitment advertised to buyers; retention uses it
   // ...adapters, contact, resolveSource, resolveCurrency, resolveCoverage
   legacyRevisionReader, // see "The legacy fallback hook"
-  maintenance: {
+  maintenance: reportingLedgerMaintenance({
     retention: { enabled: true, recordRetentionDays: 120, limit: 100 },
     changeFeed: { changeRetentionDays: 30, maxFeedHoldDays: 7 },
-  },
+  }),
 });
 ```
 
@@ -118,7 +118,7 @@ state. The bytes live in your bucket.
 
 ### Keeping your BigQuery tables fed
 
-`@adcp/sdk/reporting/bigquery` follows the change feed and loads every
+`@adcp/reporting-storage/bigquery` follows the change feed and loads every
 committed revision's verified rows into BigQuery tables you name
 ([sink details](REPORTING-LEDGER.md#bigquery-warehouse-sink)). The warehouse
 copy is derived and never served.

package/docs/guides/REPORTING-LEDGER.md

@@ -1,8 +1,10 @@
 # Seller Reporting Ledger
 
-`@adcp/sdk/reporting/ledger` turns a conforming reporting source into durable seller-side Reliable Reporting Core. It is separate from the buyer-side `reconcileReporting` API.
+Reliable Reporting Core turns a conforming reporting source into durable seller-side reporting. It is separate from the buyer-side `reconcileReporting` API.
 
-> **Stability:** the storage, row, change-feed, managed-delivery and warehouse-sink exports (`@adcp/sdk/reporting/gcs`, `s3`, `azure`, `bigquery`, and the `@experimental` exports of `ledger`) are experimental and may change in minor releases. Pin with `~`. See the [Reliable Reporting stability policy](REPORTING-STABILITY.md).
+Two packages make it up. `@adcp/sdk` holds the protocol layer: the `ReportingLedgerStore` interface, the protocol handlers, the producer, `createReliableReportingService` and row encoding (`@adcp/sdk/reporting/ledger`, `@adcp/sdk/reporting/service`). [`@adcp/reporting-storage`](https://github.com/adcontextprotocol/adcp-client/blob/main/packages/reporting-storage/README.md) holds the storage behind it: the PostgreSQL ledger store and migrations, row storage and its GCS, S3 and Azure providers, managed delivery, notification activity, the BigQuery sink and the production composition. Install both (`npm install @adcp/sdk@beta @adcp/reporting-storage@beta pg` while SDK 16 is in beta). Moving from the pre-split `@adcp/sdk/reporting/*` imports? See [Reliable Reporting storage moved to `@adcp/reporting-storage`](../migration-reporting-storage-package.md).
+
+> **Stability:** `@adcp/reporting-storage` is pre-1.0 and every export of it is experimental: breaking changes ship in its minor releases. Pin it with `~`. The store, transaction, lease and row-read interfaces in `@adcp/sdk/reporting/ledger` that it implements are `@experimental` too. See the [Reliable Reporting stability policy](REPORTING-STABILITY.md).
 
 ## Recommended: install the lifecycle service
 
@@ -13,7 +15,7 @@ producer, handlers, and decisioning-platform account resolver.
 
 ```ts
 import { Pool } from 'pg';
-import { PostgresReportingLedgerStore } from '@adcp/sdk/reporting/ledger';
+import { PostgresReportingLedgerStore } from '@adcp/reporting-storage';
 import { createReliableReportingService } from '@adcp/sdk/reporting/service';
 import { createAdcpServerFromPlatform } from '@adcp/sdk/server';
 
@@ -53,7 +55,7 @@ const reporting = createReliableReportingService({
   },
 });
 
-await pool.query(reporting.setup.migrations[0]);
+for (const sql of reporting.setup.migrations) await pool.query(sql);
 const installedPlatform = reporting.install(platform);
 const server = createAdcpServerFromPlatform(installedPlatform, serverOptions);
 
@@ -86,7 +88,7 @@ still use an `accountIds` roster. Production setup requires
 `activity.tenantScopeForAccount`; when an offering uses `consumer_receipt`, it
 also requires a trusted `obligatedConsumers` callback so lifecycle health can
 become reconciled only after every obligated consumer has accepted.
-See the [integrated seller example](../../examples/reliable-reporting-service/README.md#integrated-seller-production-service)
+See the [integrated seller example](https://github.com/adcontextprotocol/adcp-client/blob/main/packages/reporting-storage/examples/reliable-reporting-service/README.md#integrated-seller-production-service)
 for the full option shape.
 
 Install a buyer declaration after the account and its media-buy scope have
@@ -135,6 +137,8 @@ import {
   PostgresReportingLedgerStore,
   REPORTING_LEDGER_MIGRATION,
   sweepExpiredReportingLedgerState,
+} from '@adcp/reporting-storage';
+import {
   createReportingDeliveryHandler,
   createReportingProducer,
   createReportingStatusHandler,
@@ -162,7 +166,7 @@ const getMediaBuyDelivery = createReportingDeliveryHandler(store);
 await sweepExpiredReportingLedgerState(pool);
 ```
 
-Pass `getReportingStatus` and `getMediaBuyDelivery` directly to the matching `createAdcpServer` slots. The delivery helper serves only exact `reporting_revision_id` reads and returns the row payload bound by the ledger revision. Advertise `media_buy.reporting_delivery` in `experimental_features` together with a `media_buy.reporting_delivery` capability whose Reliable Reporting version is `1.0` only after both handlers are wired. Configure account resolution on the server: both handlers require the framework-resolved, caller-scoped account identity and never trust a request-body identity as an authorization boundary. If two callers can name the same upstream account, the resolver must issue distinct internal account IDs for their ledger namespaces. Install immutable delivery-configuration generations through `producer.installConfiguration`, call `planObligations()` after period close, and run `runWorker()` from a durable scheduler. Multiple workers are safe: PostgreSQL claims use `SKIP LOCKED`, expiring leases, and fencing generations.
+Pass `getReportingStatus` and `getMediaBuyDelivery` directly to the matching `createAdcpServer` slots. The delivery helper serves only exact `reporting_revision_id` reads and returns the row payload bound by the ledger revision. Both handlers take `pagination.max_results` as AdCP defines it, from `core/pagination-request.json`: an integer from 1 to 100, 50 when omitted. Any other value (and a `pagination` that is not an object or a `cursor` that is not a string) is refused with `VALIDATION_ERROR` (`field: 'pagination.max_results'`, `'pagination'` or `'pagination.cursor'`) before the ledger is read, so the same request behaves the same on every seller; page with `pagination.cursor`. The buyer-side walkers ask for the schema maximum, 100. Advertise `media_buy.reporting_delivery` in `experimental_features` together with a `media_buy.reporting_delivery` capability whose Reliable Reporting version is `1.0` only after both handlers are wired. Configure account resolution on the server: both handlers require the framework-resolved, caller-scoped account identity and never trust a request-body identity as an authorization boundary. If two callers can name the same upstream account, the resolver must issue distinct internal account IDs for their ledger namespaces. Install immutable delivery-configuration generations through `producer.installConfiguration`, call `planObligations()` after period close, and run `runWorker()` from a durable scheduler. Multiple workers are safe: PostgreSQL claims use `SKIP LOCKED`, expiring leases, and fencing generations.
 
 The planner supports fixed millisecond schedules and an explicit source-calendar
 day schedule. For the latter, set the existing schedule identity fields to
@@ -291,7 +295,7 @@ rows as verified canonical JSONL chunks (the shared SDK persistence layout,
 adcontextprotocol/adcp#7996):
 
 ```ts
-import { REPORTING_ROW_STORAGE_MIGRATION } from '@adcp/sdk/reporting/ledger';
+import { REPORTING_ROW_STORAGE_MIGRATION } from '@adcp/reporting-storage';
 
 await pool.query(REPORTING_ROW_STORAGE_MIGRATION); // after REPORTING_LEDGER_MIGRATION; PostgreSQL 13+
 const store = new PostgresReportingLedgerStore(pool, {
@@ -364,7 +368,7 @@ point reads or writes at a destination the host did not configure.
 import {
   PostgresReportingLedgerStore,
   createFilesystemReportingRowObjectProviderV1,
-} from '@adcp/sdk/reporting/ledger';
+} from '@adcp/reporting-storage';
 
 const store = new PostgresReportingLedgerStore(pool, {
   acknowledgeIsolatedDatabase: true,
@@ -462,6 +466,14 @@ await store.readyRowStorage();
   version at the recorded size is the same bytes) instead of downloading it
   while holding the account and object locks. A provider without `stat` falls
   back to reading the whole object there. All bundled providers implement it.
+  Also implement the optional `list({ prefix, pageToken, pageSize })`, which
+  returns `{ objects: [{ objectRef, nativeVersionRef, sizeBytes, createdAt }],
+  nextPageToken? }`: every stored version under the prefix once, in a stable
+  order (on a versioned store, noncurrent versions too, never delete markers),
+  with the version exactly as `putIfAbsent` recorded it and the time it was
+  written. The orphan collector needs it; a binding whose provider has no `list`
+  is reported as unsupported there. The conformance suite checks it (`list`) when
+  present. All bundled providers implement it.
 
 #### Cloud providers
 
@@ -472,12 +484,12 @@ reference fails `UNSAFE_BINDING`. Provider errors surface only as stable
 `ReportingRowStoreError` codes. Row buckets are separate from Managed Delivery
 buckets.
 
-**Google Cloud Storage** (`@adcp/sdk/reporting/gcs`, optional peer
+**Google Cloud Storage** (`@adcp/reporting-storage/gcs`, optional peer
 `@google-cloud/storage`):
 
 ```ts
 import { Storage } from '@google-cloud/storage';
-import { createGcsReportingRowObjectProviderV1 } from '@adcp/sdk/reporting/gcs';
+import { createGcsReportingRowObjectProviderV1 } from '@adcp/reporting-storage/gcs';
 
 const gcs = createGcsReportingRowObjectProviderV1({
   storage: new Storage(), // keyless credentials (workload identity / ADC)
@@ -500,12 +512,12 @@ const gcs = createGcsReportingRowObjectProviderV1({
 - The client needs `storage.buckets.get` for the probe plus object create, get
   and delete on the bucket.
 
-**Amazon S3 and S3-compatible stores** (`@adcp/sdk/reporting/s3`, optional peer
+**Amazon S3 and S3-compatible stores** (`@adcp/reporting-storage/s3`, optional peer
 `@aws-sdk/client-s3`):
 
 ```ts
 import { S3Client } from '@aws-sdk/client-s3';
-import { createS3ReportingRowObjectProviderV1 } from '@adcp/sdk/reporting/s3';
+import { createS3ReportingRowObjectProviderV1 } from '@adcp/reporting-storage/s3';
 
 const s3 = createS3ReportingRowObjectProviderV1({
   client: new S3Client({ region: 'us-east-1' }), // default credential chain
@@ -542,13 +554,13 @@ const s3 = createS3ReportingRowObjectProviderV1({
   `s3:GetBucketPolicyStatus` is optional. For stores without flexible
   checksums, construct the client with `requestChecksumCalculation: 'WHEN_REQUIRED'`.
 
-**Azure Blob Storage** (`@adcp/sdk/reporting/azure`, optional peer
+**Azure Blob Storage** (`@adcp/reporting-storage/azure`, optional peer
 `@azure/storage-blob`):
 
 ```ts
 import { DefaultAzureCredential } from '@azure/identity';
 import { BlobServiceClient } from '@azure/storage-blob';
-import { createAzureBlobReportingRowObjectProviderV1 } from '@adcp/sdk/reporting/azure';
+import { createAzureBlobReportingRowObjectProviderV1 } from '@adcp/reporting-storage/azure';
 
 const azure = createAzureBlobReportingRowObjectProviderV1({
   client: new BlobServiceClient('https://acmerows.blob.core.windows.net', new DefaultAzureCredential()),
@@ -677,7 +689,7 @@ an unknown ID. A revision in (a) to (d) whose content cannot be served is
 // Core-only service
 createReliableReportingService({
   // ...
-  maintenance: { compaction: { enabled: true, limit: 100 } },
+  maintenance: reportingLedgerMaintenance({ compaction: { enabled: true, limit: 100 } }),
 });
 
 // Production service
@@ -751,7 +763,8 @@ and `compactSupersededSnapshots` re-check before compacting.
 
 You do not need the production service (managed delivery, notifications and
 activity) to keep a ledger tidy. Build the store with the options you want and
-give `createReliableReportingService` a `maintenance` option. The production
+give `createReliableReportingService` a `maintenance` option built by
+`reportingLedgerMaintenance` from `@adcp/reporting-storage`. The production
 service does the same work automatically; the two share one implementation, so
 partial-failure reporting, the `maxFeedHoldDays` that retention honours, per-task
 limits and abort handling are identical.
@@ -762,7 +775,8 @@ import {
   REPORTING_LEDGER_MIGRATION,
   REPORTING_ROW_STORAGE_MIGRATION,
   REPORTING_LEDGER_CHANGES_MIGRATION,
-} from '@adcp/sdk/reporting/ledger';
+  reportingLedgerMaintenance,
+} from '@adcp/reporting-storage';
 import { createReliableReportingService } from '@adcp/sdk/reporting/service';
 
 // Apply the three migrations, then:
@@ -777,11 +791,11 @@ const reporting = createReliableReportingService({
   store,
   statusRetentionDays: 90, // the commitment advertised to buyers; retention uses it
   // ...adapters, contact, resolveSource, resolveCurrency, resolveCoverage
-  maintenance: {
+  maintenance: reportingLedgerMaintenance({
     intervalMilliseconds: 300_000, // default: at most one pass per 5 minutes
     retention: { enabled: true, recordRetentionDays: 120, limit: 100 },
     changeFeed: { changeRetentionDays: 30, maxFeedHoldDays: 7 },
-  },
+  }),
 });
 
 reporting.start({ intervalMilliseconds: 60_000, deploymentWide: true, onError });
@@ -813,12 +827,18 @@ Tasks, in order:
 | `change-feed pruning` | when `maintenance.changeFeed` is set              | `pruneChanges` with `changeRetentionDays` and `maxFeedHoldDays`.     |
 | `retention`           | when `maintenance.retention.enabled` is `true`    | `retireExpiredPeriods` with the service's `statusRetentionDays` and the feed's `maxFeedHoldDays`. |
 | `snapshot compaction` | when `maintenance.compaction.enabled` is `true`   | `compactSupersededSnapshots` with the service's `statusRetentionDays` and `automatedRecoveryWindowSeconds` (see [Compacting superseded snapshots](#compacting-superseded-snapshots-opt-in)). |
+| `orphan object collection` | when `maintenance.orphanCollection.enabled` is `true` | `collectOrphanedRowObjects`: lists each object binding under `{prefix}/{namespace_key}/` and deletes old objects nothing names. Opt-in, rate-limited and resumable; see [Orphaned object collection](REPORTING-OPERATIONS.md#adopting-row-storage-retention-and-the-change-feed). |
 
 Notes:
 
-- `maintenance` requires a `PostgresReportingLedgerStore` (or a store with the
+- The service's `maintenance` option takes a factory, not an options object:
+  the SDK does not know what maintenance a store needs, so it calls the factory
+  once at construction with the store and the retention and recovery-window
+  commitments it advertises. `reportingLedgerMaintenance(options)` is the
+  PostgreSQL one. It requires a `PostgresReportingLedgerStore` (or a store with the
   same `retireExpiredPeriods`, `pruneChanges` and `sweepRowWriteIntents`
-  methods) and fails at construction otherwise. `maintenance.changeFeed` also
+  methods, plus `collectOrphanedRowObjects` when `orphanCollection` is set) and
+  fails at construction otherwise. `maintenance.changeFeed` also
   requires `changeFeed: true` on the store, since pruning is otherwise a silent
   no-op.
 - Retention takes `statusRetentionDays` from the service, so it can never retire
@@ -838,7 +858,7 @@ In-process consumers such as pacing, alerts and warehouse loaders read from the
 ledger, never from a warehouse copy.
 
 ```ts
-import { REPORTING_LEDGER_CHANGES_MIGRATION } from '@adcp/sdk/reporting/ledger';
+import { REPORTING_LEDGER_CHANGES_MIGRATION } from '@adcp/reporting-storage';
 
 await pool.query(REPORTING_LEDGER_CHANGES_MIGRATION); // PostgreSQL 13+
 const store = new PostgresReportingLedgerStore(pool, { acknowledgeIsolatedDatabase: true, changeFeed: true });
@@ -860,30 +880,60 @@ await store.saveFeedConsumerCursor('pacing', page.cursor); // holds back pruning
   highest-numbered snapshot. An official revision is terminal, so this is always
   one index lookup.
 - `changesAfter` lists committed obligation, revision, adjustment and retirement
-  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. 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.
+  changes. Every feed, account-scoped or deployment-wide (omit `account_id`),
+  orders by `(xid, seq)` and returns only changes whose transaction precedes
+  every transaction still in flight (`xid` below the reading snapshot's
+  `xmin`), so a slow commit is never skipped. The order does not depend on the
+  account lock, on the order a writer drew `seq` in, or on which lock key a
+  writer took: a change with a lower `seq` and a higher `xid` that commits late
+  is simply returned on a later page, after the cursor. The cost is that any
+  older open transaction on the cluster, including an idle one in another
+  database, holds every 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. The account scan is served by the
+  `(account_id, xid, seq)` index that `REPORTING_LEDGER_CHANGES_MIGRATION`
+  creates.
 - **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.
+  row under the account advisory lock. The feed no longer needs that lock for
+  its order, but a second SDK is still unsupported: it can write rows the first
+  SDK's lifecycle, retention and idempotency logic does not know about. Give
+  another SDK (for example a Python deployment) 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 an ordering assumption.
+- **Upgrading from account cursors that carry only `seq`.** Account feeds used
+  to order by `seq` and cut each page before the first in-flight change. An old
+  account cursor is `{ seq }` with no `xid`. `changesAfter` accepts it and maps
+  it to the position `(xid, seq)` where `xid` is the smaller of the oldest `xid`
+  among the account's changes after that `seq` and the reading snapshot's `xmin`.
+  Every change after the old `seq` has an `xid` at or above both (a change that
+  has not committed yet belongs to a transaction at or above `xmin`), so nothing
+  is skipped. The cost is that changes the consumer already read can be returned
+  again: those with a lower `seq` and a higher `xid`, and, when a long
+  transaction was open at that moment, every change committed since it began.
+  Treat redelivery as normal, as for any at-least-once consumer. The returned cursor is in the new
+  format, even on an empty page. A legacy cursor fails with `CURSOR_EXPIRED` if
+  any change with a higher `seq` was pruned (`adcp_reporting_change_account_horizon.pruned_through_seq`
+  still records the highest pruned `seq` for this check). A consumer row saved
+  before the upgrade has a NULL `cursor_xid` and holds retention by `seq` until
+  the consumer saves its next cursor; `saveFeedConsumerCursor` given a legacy
+  cursor maps it the same way. Re-apply `REPORTING_LEDGER_CHANGES_MIGRATION`
+  before starting the new binary: it adds the account horizon's `xid` columns,
+  replaces the consumer table's check constraint, and creates the new index. On
+  a large changes table, create the index first with `CREATE INDEX CONCURRENTLY
+  IF NOT EXISTS adcp_reporting_changes_account_xid ON adcp_reporting_changes
+  (account_id, xid, seq)`, because a plain `CREATE INDEX` blocks appends while it
+  builds; the migration then skips it. The older
+  `adcp_reporting_changes_account (account_id, seq)` index is left in place and
+  serves the legacy-cursor mapping; drop it once no legacy cursor remains.
+- **Do not run the old and new SDK's change-feed maintenance together.** An older
+  host's `pruneChanges`, `retireExpiredPeriods` and compaction hold an account
+  consumer's changes by `seq` alone and record only `pruned_through_seq`, so
+  against a consumer that holds new-format cursors they can prune a change the
+  consumer has not read and never advance the horizon the new reader checks.
+  Stop the older hosts' maintenance (or the hosts) before the new binary reads
+  the feed. Rolling back is not supported once a consumer has saved a new-format
+  account cursor: the older SDK rejects it, so reset those consumers.
 - `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
@@ -918,7 +968,7 @@ await store.saveFeedConsumerCursor('pacing', page.cursor); // holds back pruning
 
 ### BigQuery warehouse sink
 
-`@adcp/sdk/reporting/bigquery` loads committed revisions into your own BigQuery
+`@adcp/reporting-storage/bigquery` loads committed revisions into your own BigQuery
 tables for analysts. The warehouse copy is derived and non-authoritative. It
 is never read for serving or verification, so its table names, columns,
 partitioning and retention are yours.
@@ -928,7 +978,7 @@ import { BigQuery } from '@google-cloud/bigquery';
 import {
   REPORTING_WAREHOUSE_SINK_MIGRATION,
   createBigQueryReportingWarehouseSinkV1,
-} from '@adcp/sdk/reporting/bigquery';
+} from '@adcp/reporting-storage/bigquery';
 
 await pool.query(REPORTING_WAREHOUSE_SINK_MIGRATION); // after REPORTING_LEDGER_CHANGES_MIGRATION
 const bigquery = new BigQuery({ projectId: 'analytics-prod' }); // ADC / workload identity
@@ -1109,9 +1159,13 @@ Core remains the default and has no destination, external-resource, or receipt d
 ```ts
 import {
   PostgresReportingLedgerStore,
+} from '@adcp/reporting-storage';
+import {
   PostgresReportingManagedDeliveryStore,
   REPORTING_MANAGED_DELIVERY_MIGRATION,
   createReportingManagedDeliveryRuntime,
+} from '@adcp/reporting-storage/managed';
+import {
   reportingManagedDeliveryBindingV1,
 } from '@adcp/sdk/reporting/ledger';
 
@@ -1182,7 +1236,7 @@ A seller often delivers one feed through several transports: one buyer takes fil
 import {
   createReportingManagedDeliveryAdapterRouterV1,
   createReportingManagedDeliveryRuntime,
-} from '@adcp/sdk/reporting/ledger';
+} from '@adcp/reporting-storage/managed';
 
 const adapter = createReportingManagedDeliveryAdapterRouterV1({
   routes: [
@@ -1262,12 +1316,14 @@ only for health changes:
 ```ts
 import { createPostgresPersistentNotificationRuntime } from '@adcp/sdk/server';
 import {
-  createPostgresReportingNotificationActivityRuntime,
-  createPostgresReportingNotificationAttemptCheckpoint,
   PostgresReportingLedgerStore,
   REPORTING_LEDGER_FINALITY_WRITER_FENCE_MIGRATION,
   REPORTING_LEDGER_MIGRATION,
-} from '@adcp/sdk/reporting/ledger';
+} from '@adcp/reporting-storage';
+import {
+  createPostgresReportingNotificationActivityRuntime,
+  createPostgresReportingNotificationAttemptCheckpoint,
+} from '@adcp/reporting-storage/notifications';
 
 // Build the durable pre-POST checkpoint first. The notification runtime needs
 // it, and the activity runtime verifies it targets the same durable store —