RFC: reliable reporting status and managed delivery

[bokelley]

Status (2026-08-30): staged for ratification — one data model, three conformance tiers. The architecture below stands, but conformance splits into tiers and only Core is required. PR #6953 is draft until the merge gates hold.

Staging decision

Implementation review (5,295-line protocol PR; ~11k and ~15k-line SDK prototypes) showed this RFC had grown into three products. The model is preserved; conformance is tiered:

Tier	Capability	Contains	Required?
Core	reporting.core	Obligations, revisions, materializations, five health states, get_reporting_status — over transports sellers already have (get_media_buy_delivery, existing reporting_webhook). The reporting.delivery_ready doorbell is optional: a polling-only seller is fully Core-conformant.	Yes
Managed delivery	reporting.managed_delivery	Files, dataset shares, warehouses, manifests — binding to principal-layer destinations (#6966 / #7015)	No
Reconciled billing	reporting.reconciled_billing	Canonical digest, consumer receipts, sync_reporting_receipts	No

Core alone solves the original problem — "where is yesterday's reporting, and is anything missing?" — and a basic webhook/polling seller implements it without understanding destinations, manifests, canonical hashing, or receipts.

Merge gates for #6953:

1. Proposal: unify operational snapshots and official delivery as revisioned facts #6122's finality model receives WG agreement (critical path).
2. Destination/verification vocabulary consolidated onto principal-layer $refs from feat(protocol): add agent configuration sync #6966.
3. An independent human protocol review approves the scope.
4. A minimal Core fixture demonstrates a polling-only seller passing reporting.core conformance with no destination, manifest, hashing, or receipt code.

---

Product goal

AdCP should make reliable reporting feel like one product surface:

A consumer asks “do I have definitive reporting for this period?”, gets a machine-checkable answer, and only involves a human when production, delivery, or reconciliation cannot recover automatically.

Moving bytes is not enough. The contract must distinguish:

1. what reports were supposed to exist;
2. what immutable logical content the seller published;
3. where each publication was materialized; and
4. whether each intended consumer independently observed matching data.

The SDK should orchestrate those facts. Applications should not build their own reporting state machine.

Minimal protocol surface

Reuse configuration and notifications

• get_adcp_capabilities advertises atomic managed-reporting offerings.
• sync_accounts.reporting_delivery_configs[] selects and authorizes independently scheduled pacing, analytics, and billing feeds for one account.
• reporting.delivery_ready is registered through existing account notification configuration and acts only as a signed, secret-free doorbell.
• Existing reporting_webhook and get_media_buy_delivery remain the low-latency and compatibility data APIs.

The authenticated transport principal is the buyer/governance agent identity. It is not repeated as an untrusted payload field.

Agent-scoped reusable destinations are complementary, not a replacement for account configuration. The separate sync_agent_configuration proposal in #6966 lets a caller prove and register one BigQuery dataset, S3 prefix, Snowflake account, or Databricks recipient once for its relationship with a seller. Each account-level reporting configuration still authorizes which account, feed, media-buy scope, and schedule may use the resulting seller-issued destination reference. This allows consolidation across many accounts without making destination possession equivalent to data access.

Add one authoritative read task: get_reporting_status

The task has explicit views:

• summary: operational health for an exact account/feed/time denominator;
• periods: a stable cursor-paginated ledger used for complete reconciliation; and
• revision: exact retained revision/resource resolution.

The five health states remain simple:

State	Meaning
healthy	Due obligations in an open scope are current and automatic delivery is working.
waiting	Nothing in the selected open scope is due yet.
delayed	Something is late but still inside automatic recovery.
action_required	An SLA/retry boundary was crossed and a structured responsible party/action is available.
complete	The scope is closed, retained, and every obligation satisfies finality, delivery, and any required consumer reconciliation.

Add one narrow write task: sync_reporting_receipts

SDK prototyping confirmed that the seller cannot infer consumer agreement from successful publication. This is especially clear for a buyer-owned destination: the seller may be allowed to write but correctly forbidden from reading it.

sync_reporting_receipts therefore records an authenticated consumer's accepted or rejected observation of one exact materialization. It is not a webhook acknowledgement. An accepted receipt includes row count and profile-defined control totals plus the selected verification evidence. A rejected receipt records stable mismatch codes. The consumer then reads the receipt back through get_reporting_status.

This is the minimum back-and-forth needed for the seller to know “the buyer says it has the same numbers.” It is still an attestation, not cryptographic proof that the buyer used those rows correctly after its stated downstream commit.

A replay mutation remains deferred. Retained immutable resources and the authoritative ledger provide ordinary missed-event recovery.

Capability declaration, snapshots, and mixed-source coverage

Managed delivery advertises exact reporting products, not a generic promise that a transport can carry every report.

• The seller-wide media_buy.reporting_delivery.offerings[] catalog declares atomic combinations of report definition and row grain, feed purpose, cadence/alignment/SLA, supported snapshot and/or official finality, reconciliation profile, and delivery method. Hourly snapshots to object storage and daily official billing through a warehouse share are separate offerings.
• Product.reporting_capabilities.reporting_delivery_offering_ids declares which seller-wide offerings packages using that product can satisfy. An empty list means none; omission means unknown, not universal support.
• Account, seat, credential, provider, and API constraints may narrow eligibility during sync_accounts.
• Each period obligation freezes the resulting media-buy and package coverage so later capability changes do not rewrite history.

A configuration selects coverage_requirement: full | allow_partial. Coverage is returned independently as full | partial | none | unknown, together with exact covered, unsupported, and unknown package/media-buy sets. A fresh, successfully delivered partial snapshot remains partial. Covered-subset metrics MUST NOT be presented as complete whole-buy totals, and implementations MUST NOT silently weaken the selected profile to a lowest common denominator.

Event-level or exposure-log access is a distinct reporting profile with its own privacy and authorization requirements. Advertising a clean-room or warehouse transport does not imply that profile is available.

Reliability data model

Obligation

One destination/configuration-specific report that should exist for an exact period, scope, finality, and due time. Obligations exist before delivery, which makes a missing first webhook or missing first file detectable.

Revision

One immutable logical publication. Revisions are deliberately destination-independent. They contain the report-definition/profile identity, account and media-buy scope, exact period, finality, observation/data-through boundary, row count, control totals, optional canonical content digest, and supersession lineage.

One canonical revision can fan out to S3, BigQuery, Databricks, Snowflake, a buyer agent, and a governance consumer without acquiring a different logical identity. A restatement creates a new revision and points to the immediately superseded revision. A zero-row revision is real and distinct from no revision.

Materialization

One attempt to expose a revision for one obligation and destination. Delivery configuration, destination, method, retry attempt, resource descriptor, and producer-side verification belong here. A retry creates a new materialization while preserving revision identity.

Receipt

One authenticated consumer's observation of one exact materialization. Buyer and governance consumers receipt independently; neither principal's result implies the other's.

Definitive-period algorithm

A buyer does not establish completeness by trusting one seller boolean. An SDK must:

1. derive the exact expected periods from its saved delivery-configuration generations and resolved calendar boundaries;
2. request that account/config/feed/time scope;
3. require scope_closed: true and full retained-ledger coverage;
4. exhaust a cursor bound to one immutable ledger_snapshot_id and ledger_as_of;
5. deduplicate obligation, revision, materialization, and receipt records by immutable IDs;
6. require the unique record count to equal pagination.total_count;
7. require each obligation's declared revision/materialization/receipt counts to equal the associated records actually returned;
8. require one obligation for every locally expected period;
9. select exactly one current revision and require the configured finality;
10. require a verified, unexpired exact materialization; and
11. when configured for consumer reconciliation, require an accepted matching receipt for that current revision/materialization.

This answers “do I have all of yesterday?” even when the first report never existed. For an open hour or month, the same surface reports current health and conservative data_through; it does not call an unfinished scope complete.

Totals are aggregated once per canonical revision, not once per destination, so fan-out cannot double-count spend or impressions.

Verification profiles

Full canonical hashing is valuable but too expensive to require for every frequent snapshot. Offerings select one explicit profile:

• native_commit: immutable provider-native version/transaction evidence plus row count and control totals;
• manifest_checksums: a digest-valid manifest plus every listed object's cryptographic checksum, row count, and control totals; or
• canonical_digest: a digest of canonical logical rows under a content-addressed canonicalization contract.

Only canonical_digest claims exact logical equality across differently encoded/materialized copies. Billing requires official finality, canonical_digest, reconciliation_mode: consumer_receipt, and an accepted current receipt. Pacing and analytics may use cheaper profiles when the selected atomic offering allows them.

Normative file delivery

file_transfer uses a manifest-last commit. Producers write all immutable data objects first and publish the manifest last. Consumers ignore unlisted objects and do not process a materialization until the exact manifest digest validates.

The v1 manifest binds:

• revision, obligation, materialization, and period identity;
• format and compression;
• the complete object list;
• per-object sizes, row counts, and SHA-256/SHA-512 checksums;
• total size and row count;
• profile-defined control totals; and
• creation time and complete: true.

This is the interoperability contract for S3/GCS/Azure-style delivery, rather than prose saying only “manifest last.”

Destination and orchestration semantics

The open method patterns are:

Pattern	Protocol boundary
file_transfer	A complete immutable manifest and all listed objects are readable and verified.
dataset_share	A versioned relation/share is readable through a representative intended consumer path.
warehouse_materialization	The exact revision is committed in the configured destination with the selected verification evidence.

producer_managed versus consumer_managed says who orchestrates delivery. It does not say who owns the table or which platform service writes it. GAM BigQuery Data Transfer can be consumer-managed even though the transfer service performs the write. A buyer-owned destination may end the seller's technical visibility at verified commit; the receipt reports the consumer's independent observation and optional non-secret downstream checkpoint.

Credentials, signed URLs, bearer profiles, passwords, and private keys never transit AdCP. Provider-native grants or explicit human setup handle access.

Fast path and reliable path

• A short-period snapshot pacing feed gives the fast path. reporting.delivery_ready wakes the consumer quickly; polling repairs missed events.
• Daily or billing-cycle official feeds give the slower authoritative path with longer SLA and retention.
• Buyers may install pacing, analytics, and billing configurations simultaneously and reconcile each independently.
• Event-level exposure logs are deferred until AdCP defines their privacy, authorization, purpose, minimization, retention, and recipient contract.

Campaign-control decisions based on feed health belong to buyer policy or Campaign Pulse. This reporting RFC exposes reliable evidence and never pauses or resumes spend itself.

Live and SDK validation

Live synthetic validation has exercised the two less-obvious destination paths:

• BigQuery warehouse materialization: immutable A/B revisions, duplicate-safe commit, retained A after restatement B, exact replay, row-count and digest agreement.
• Databricks Open Sharing: recipient-observed readiness, retained historical version reads, zero rows, revoke/regrant, and exact replay. The roughly 15-second recipient visibility delay proved that provider-side grant completion is not readiness. Open-client incompatibility with Delta Deletion Vectors proved that reader compatibility belongs in the offering.

The proposed schemas were then generated into current local checkouts of both SDKs:

• JavaScript build and strict typecheck pass. Four end-to-end reconciliation tests pass: receipt write/readback with transient destination retry, missing expected-period detection, incomplete associated-history detection, and destination fan-out without double-counting.
• Python Ruff and strict MyPy pass for the helper, and the same four reconciliation tests pass.
• Python generation also exposed SDK work that must be fixed in its own PR: some current protocol models have renamed generated types still referenced by hand-written aliases, and canonical macro references need corrected $ref rebasing.

S3 uses standard object-store mechanics and is not a remaining schema-design gate, though a small live smoke test should become a conformance fixture before this experimental feature graduates.

Implementation

The first protocol/schema implementation is #6953. It includes the status and receipt tasks, four-record ledger, destination-independent revisions, normative manifest, verification profiles, delivery configuration/capabilities, signed readiness notification, security constraints, and contract tests.

The feature remains experimental while we gain multi-party production experience. The immediate follow-on is to land clean JavaScript and Python SDK PRs around the validated helper behavior, then exercise a seller adapter and an independent consumer/governance adapter end to end.

[bokelley]

Triage

Classification: RFC — feature request
Bucket(s): spec / protocol, media-buy
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Direction sound; discriminated-union delivery config mirrors audience-activation-method.json well. Key concerns: (1) add managed as a new concept rather than renaming offline — avoids silent double-delivery for accounts using both simultaneously; (2) reporting_revision_id needs its own x-entity class with a cycle-detection invariant in the supersedes chain; (3) reporting.delivery_ready requires anchor-classification and an atomic two-file schema update (notification-type.json + notification-config.json); (4) gate schema PRs on Proposal: unify operational snapshots and official delivery as revisioned facts #6122 reaching WG-accepted status.
• adtech-product-expert: Problem is real — connector runtimes (Airbyte/Sling/dlt) answer the pipe but not the protocol-level acknowledgement loop. Key concerns: (1) cut warehouse_write from v1 (no bilateral IAM/auth standard exists yet for producer-commits-into-consumer-warehouse); (2) acknowledgement must be optional capability, not a conformance requirement — buyer agents do not send programmatic acks today; (3) reporting_delivery naming collides with campaign-delivery vocabulary — consider report_transfer or reporting_materialization.

My take: Both experts converge — well-precedented, additive to an experimental surface, clearly non-breaking. Four design questions must be settled before schema PRs open: the offline/managed migration invariant, ack optionality, warehouse_write deferral, and the #6122 finality gate.

---

Decision Memo

---
id: (pending — DR number assigned on ratification)
title: Introduce managed reporting delivery as a new experimental AdCP capability
class: normative
status: recorded
date: 2026-08-27
decided: ~2026-08-27
decided_by: pending WG ballot
refs: ["#6911", "#6122", "#4324"]
dissent: none
---

Decision: Ratify managed reporting delivery as a normative non-breaking addition — new tasks, notification type, and capability fields on an experimental surface — subject to four preconditions below.

Rationale: The existing offline bucket path has no immutable revision identity, no readiness contract, and no repair/replay mechanism. The proposal uses established AdCP patterns (doorbell webhook à la capabilities.changed, discriminated-union delivery config identical to audience-activation-method.json, RFC 9421 signing reuse, BrandRef for vendor identity) and is the natural symmetric sibling to the shipped audience-activation-methods surface (#4324). All changes are additive.

Preconditions before schema PRs open:

1. Proposal: unify operational snapshots and official delivery as revisioned facts #6122 gate. reporting_revision finality and supersedes-chain semantics depend on Proposal: unify operational snapshots and official delivery as revisioned facts #6122's delivery_finality model. Schema PRs for RFC: reliable reporting status and managed delivery #6911 must not open until Proposal: unify operational snapshots and official delivery as revisioned facts #6122 is WG-accepted.
2. Naming: managed is a new concept; offline is preserved. file_transfer under managed = successor path, not a rename. This avoids a migration invariant gap and double-delivery ambiguity for accounts with both paths active.
3. Acknowledgement is optional capability. Sellers MAY require it; buyers MAY send it. No conformance failure for either party that omits it. A timeout-to-stale fallback must be defined for the case where acknowledgement: required is declared but no ack arrives.
4. warehouse_write deferred. Exclude from v1. Earns inclusion when two conformant parties demonstrate an interoperability case with a defined auth model.

Implications: This settles the structural approach — experimental capability, discriminated-union configs, doorbell notifications, BrandRef vendor identity. It does not settle the seven open questions the author lists. WG attention should prioritize Q4 (#6122 relationship, precondition 1 above) and Q5 (ack optionality, precondition 3 above). Event name (reporting.delivery_ready vs reporting.revision_available) and minimum retention are minor and can be resolved quickly. Standalone sync_reporting_delivery_configs task (not a sync_accounts field) matches the sync_audiences precedent and is the recommended structural choice.

Dissent: None.

---

Triaged by Claude Code. Session: https://claude.ai/code/cse_01VCa8yn8XKcdhZBuuMh74pL

---

Generated by Claude Code

[bokelley]

Implementation spike synthesis

Three independent implementation spikes tested this RFC against: (1) GAM reporting plus file/BigQuery materialization, (2) Snowflake and Databricks dataset sharing, and (3) Meta Ads aggregate reporting as a structurally different social source.

All three were executable and test-backed, but fixture/fake-backed only. No result below should yet be read as live platform conformance. Live BigQuery and one live Snowflake-or-Databricks validation are now the remaining proof gate.

What held up

The common architecture survived all three implementations:

1. a source adapter acquires one canonical observation;
2. the producer creates an immutable reporting revision;
3. the same retained revision can feed the fast GET/webhook path and one or more durable materializations without reacquiring upstream data;
4. materialization drivers are independent of GAM, Meta, or another source adapter; and
5. consumer receipt is separate from producer readiness.

The implementation model needs four distinct entities:

• reporting_delivery_config — desired delivery policy and destination/share binding;
• reporting_revision — immutable logical reporting content and lineage;
• reporting_materialization — one method/destination attempt and its native commit proof;
• reporting_receipt — consumer testimony that an exact revision was committed or rejected downstream.

This separation is not aesthetic. Retry/replay creates another materialization attempt without changing the reporting revision; acknowledgement changes a receipt without changing producer readiness.

Method disposition

The spikes support including all three method patterns in the experimental v1, with method-specific commit evidence:

Pattern	Producer claim	Commit evidence
file_transfer	delivered after manifest-last publication and verification	manifest revision plus per-object size/checksum
dataset_share	available after recipient observability is verified	provider/recipient resource identities plus optional native version reference
warehouse_materialization	delivered only when the producer can observe the destination commit; otherwise producer claims available and the consumer receipt records commit	destination relation/partition plus transaction, job, or run identity

warehouse_materialization is a better name than warehouse_write: GAM-to-BigQuery can be a consumer-managed transfer whose platform service performs the physical write. Add an orchestration dimension such as producer_managed / consumer_managed; do not infer orchestration from which process executes SQL or copies bytes.

Dataset-share finding

One provider-neutral dataset_share pattern is viable, but native_version_ref cannot be universally required.

• Databricks can expose a Delta table version/history reference relatively directly.
• Snowflake Secure Data Sharing does not supply the same durable per-share revision primitive. Exact older-revision access therefore needs publisher-managed immutable per-revision objects (or another explicitly retained immutable representation), not merely a mutable shared view/table name.

The common contract should require canonical reporting_revision_id, schema identity, retained content identity, split provider/recipient resource identity, and successful recipient observability before available. Native version/transaction identity is method/platform evidence when available, not the cross-platform revision identity.

Revision-key finding from social reporting

The Meta spike confirmed that source query semantics are part of revision identity. Two rows for the same campaign and date are not the same logical fact when attribution windows, breakdown sets, action definitions, timezone/calendar boundary, or reporting profile differ.

Rather than continually expanding an informal tuple, the revision should reference an immutable normalized report_definition (or carry its canonical fingerprint). The partition plus report-definition identity determines the logical slice; each emitted revision then carries finality, observed_at, data_through, and supersession.

Keep two integrity layers distinct:

• a canonical logical-content digest on reporting_revision, if AdCP defines the canonicalization;
• byte/object/table commit checksums or native transaction evidence on each reporting_materialization.

CSV and Parquet encodings of the same logical revision will not have the same byte checksum.

Fast, durable, and exposure-log paths

Cadence, finality, profile, and method are orthogonal:

• fast operational aggregate snapshots may use GET and inline reporting webhooks;
• daily snapshot/official/restated revisions may use any durable method;
• an official revision can supersede a prior snapshot without acknowledgement changing finality; and
• exposure logs use the same revision/materialization machinery under a distinct privacy-gated reporting profile, not the aggregate media_buy_delivery_v1 schema.

Meta should advertise exposure logs as unsupported unless a separately authorized documented source provides them. A general social Insights API must not be treated as evidence that user/impression-level export exists.

Concrete RFC changes recommended

1. Include file_transfer, dataset_share, and warehouse_materialization; defer the name warehouse_write.
2. Add explicit orchestration/control responsibility independently of destination ownership and executor vendor.
3. Replace the single readiness progression with producer readiness (available / delivered / failed) plus a separate consumer receipt (committed / rejected). Staleness remains a freshness evaluation, not an immutable materialization state.
4. Make every replay create a new materialization attempt while retaining the exact revision ID and canonical content digest.
5. Reuse Proposal: unify operational snapshots and official delivery as revisioned facts #6122 finality/freshness vocabulary, but do not reuse a per-package fact-revision ID as the batch/report-publication identity.
6. Define destination_ref/recipient binding lifecycle: creation, validation, account/principal ownership, rotation, revocation, and secret-free reads.
7. Require an immutable normalized report-definition identity so attribution, breakdown, grain, timezone, metric, and exposure-log semantics cannot collide.
8. Add conformance cases for method-independent source acquisition count, share recipient observability, stable access to an older shared revision, destination commit attestation authority, and canonical-vs-byte checksum separation.

Remaining live gate

Before freezing schemas, validate with tiny synthetic data:

1. one live BigQuery materialization: idempotent repeat, partition restatement, verified commit, and exact retained replay; and
2. one live Snowflake or Databricks share: revision A remains exactly addressable after B, recipient observability precedes readiness, revoke/re-grant works, and replay does not reacquire source data.

If either live path requires substantially different fields or cannot support the claimed readiness/replay semantics, keep the affected method experimental and revise its branch before schema implementation.

[bokelley]

Live validation update — BigQuery warehouse materialization

The BigQuery half of the remaining live gate has now been exercised against a dedicated synthetic dataset in the bok-playground GCP project. No production reporting data or existing dataset was touched. Test tables have a 24-hour expiration.

Validated:

• immutable revision A materialized into a date-partitioned destination;
• repeating the identical materialization was duplicate-safe;
• restatement B committed as a new revision with supersedes_reporting_revision_id: rrv_a while A remained retained;
• both materializations matched their revision ledger's expected row count and canonical SHA-256 digest; and
• replaying retained A into a fresh materialization reproduced the original row count and digest without source reacquisition.

Observed verification:

Revision	Supersedes	Expected/materialized rows	Digest result
rrv_a	—	2 / 2	exact match
rrv_b	rrv_a	2 / 2	exact match
replay of rrv_a	—	2 / 2	exact match to retained A

This confirms the proposed warehouse_materialization semantics on BigQuery for a producer-observed commit: immutable revision identity, idempotent destination commit, restatement lineage, retained exact-revision replay, and separate canonical content verification all map cleanly to native BigQuery tables/jobs.

Scope caveat: this validates the BigQuery destination semantics with synthetic SQL, not the GAM BigQuery Data Transfer Service control plane and not a production ESA driver. The distinction between producer_managed and consumer_managed orchestration therefore remains necessary. The live Databricks dataset-share gate is still pending.

[bokelley]

Live Databricks dataset_share validation

We ran this against a real non-production Databricks workspace with synthetic data. The immutable revision mechanics passed; the end-to-end recipient-read lifecycle did not, due to the account's Delta Sharing configuration.

Passed live

• Revision A: application revision adcp_reporting_validation_app_rev_A_20260827; native Delta table version 1; 4 rows; deterministic digest verified.
• Revision B: application revision adcp_reporting_validation_app_rev_B_20260827; native Delta table version 2; 5 rows; deterministic digest verified.
• After publishing B, A remained exactly addressable via VERSION AS OF 1; its row count and digest were unchanged and B was absent from that version.
• Replay of A from the retained revision, without regenerating or reacquiring upstream data, reproduced the same 4 rows and digest.
• A zero-row revision worked with an explicit empty-content digest.

Recipient lifecycle limitation found live

The metastore has delta_sharing_scope=INTERNAL, so Open Sharing recipient creation correctly failed with External Delta Sharing is not enabled on the metastore. A Databricks-to-Databricks self-recipient, share, table WITH HISTORY, and provider-side grant could be created, but the same metastore produced no incoming provider/catalog surface. That matches Databricks' cross-metastore model for Databricks-to-Databricks sharing; same-metastore consumers use Unity Catalog directly.

Provider-side revoke and regrant succeeded, but recipient-side denial/restoration could not be proven without an incoming recipient catalog. Therefore the full validation is partial, not a pass.

Protocol implications

1. app_revision_id should remain the AdCP-stable revision identity. A native Delta version is a useful optional implementation reference, but it is table-specific—the replay table had a different native version even though it represented the same AdCP revision.
2. ready must require a successful read through the consumer's actual access path. Creating a share and grant on the provider side is not sufficient evidence.
3. Databricks delivery needs at least two credential/access variants:
   • Databricks-to-Databricks: provider/recipient identity and share metadata; normally no bearer profile exchanged on the AdCP wire.
   • Open Sharing: an ephemeral connector credential/profile handled outside the AdCP payload, not a bearer token embedded in protocol messages.
4. Same-metastore Databricks delivery is practically closer to a Unity Catalog grant than cross-metastore Delta Sharing. The transport should describe the access mode/capability instead of assuming every dataset_share has the same recipient activation flow.

Relevant Databricks docs: Delta Sharing overview, read shared data in Databricks.

Cleanup was verified: all validation shares, recipients, catalogs, and tables were removed, and the existing serverless warehouse used for the test was stopped. No compute was created.

[bokelley]

Follow-up: live Databricks Open Sharing validation passed

After enabling external Open Sharing on the test metastore (INTERNAL_AND_EXTERNAL), we completed the previously blocked recipient-side validation using a real external Open Sharing client and synthetic data.

Live results

• External recipient grant completed in 1.347s; the exact shared revision was readable by the recipient 14.643s later on the first read attempt. The test emitted its readiness marker only after that read succeeded.
• Revision A: application revision A backed by native Delta version 1, 4 rows, deterministic digest verified from the external client.
• Revision B: application revision B backed by native Delta version 2, 5 rows, deterministic digest verified.
• The external client could still read historical A exactly after B was published; A's row count/digest were unchanged and B was absent at A's native version.
• Revocation became observable to the existing external client in 0.711s with HTTP 403 / PERMISSION_DENIED.
• Regrant completed in 0.973s; restored access became observable after 15.904s on the first read attempt.
• Replay of A used the retained revision without upstream reacquisition and reproduced the same 4 rows/digest using the existing recipient credentials.
• A zero-row revision was read and verified by both provider and recipient with the expected empty-content digest.

Additional interoperability findings

1. External access is not instant even after the provider grant succeeds. available should be asserted only after an actual consumer-path read, and implementations need a bounded verification/retry interval. The roughly 15-second grant/regrant delay observed here makes provider-side grant completion an unsafe readiness boundary.
2. WITH HISTORY made the native Delta version useful for externally reading an exact historical revision. The AdCP application revision remains the stable cross-materialization identity; the Delta version remains an optional, table-specific native reference.
3. The current token-recipient activation URL serves an HTML-backed download flow rather than returning the credential profile directly as JSON. That is connector implementation detail and another reason not to place activation URLs or profiles on the AdCP wire.
4. Default Delta Deletion Vectors were incompatible with the tested open-client path. The successful run explicitly disabled that feature. Delivery capabilities therefore need format/reader-compatibility constraints, and readiness verification must use a representative supported client.

This validates the proposed dataset_query/dataset_share reliability envelope in #6911: provider-hosted immutable revisions, consumer-observed available, exact native-version resolution where supported, destination-only replay, and secret-free readiness events all worked live.

Cleanup was verified: the 0600 temporary credential profile was deleted, all validation shares/recipients/tables/catalogs were absent, and the serverless warehouse was stopped.

[bokelley]

Product direction update: one status surface, SDK-managed reliability

The product goal should be simpler than the initial task list suggests:

A buyer asks “where is my reporting?”, receives an automatic answer, and only has to involve a human when the automated recovery path is exhausted.

The protocol still needs immutable revisions, delivery evidence, and missed-event repair underneath, but those concepts should not each become a user-facing task. SDKs should handle capability negotiation, webhook verification and deduplication, polling repair, resource resolution, checksum verification, retry, and local consumption bookkeeping.

Proposed minimal v1 surface

1. Reuse existing configuration surfaces

• Keep per-buy inline delivery configured through the existing reporting_webhook.
• Put account-scoped durable delivery desired state on sync_accounts alongside the existing account notification and reporting-bucket configuration. Do not add a standalone sync_reporting_delivery_configs task in v1.
• Register reporting.delivery_ready through the existing account notification_configs[] mechanism.

The SDK can expose one high-level method such as client.reporting.ensure(...) and translate it into the appropriate existing configuration fields for the seller's advertised capabilities.

2. Add one read/recovery task: get_reporting_status

This replaces separate list and get tasks. With no narrow filters it answers the operational question; with a reporting-period or revision filter it returns exact revision and resource details for repair.

Example default response:

{
  "account_id": "acc_123",
  "health": "action_required",
  "data_through": "2026-08-26T00:00:00Z",
  "next_expected_at": "2026-08-28T04:00:00Z",
  "issues": [
    {
      "code": "REPORT_OVERDUE",
      "media_buy_ids": ["mb_123"],
      "period_start": "2026-08-26T00:00:00Z",
      "period_end": "2026-08-27T00:00:00Z",
      "expected_at": "2026-08-27T04:00:00Z",
      "responsible_party": "seller",
      "recommended_action": "contact_seller"
    }
  ]
}

The compact health vocabulary should be understandable without reconstructing the state machine:

• healthy — reporting is current and automated delivery is working;
• waiting — no report is due yet;
• delayed — a report is late but remains inside a declared automated recovery/delay path;
• action_required — an SLA or retry boundary has been crossed and structured human action is supplied; and
• complete — all required periods and applicable final revisions are complete.

An optional detail mode returns period-level records. Each record joins the expected reporting obligation to any produced revision and its delivery methods:

{
  "period_start": "2026-08-26T00:00:00Z",
  "period_end": "2026-08-27T00:00:00Z",
  "expected_at": "2026-08-27T04:00:00Z",
  "production_status": "published",
  "reporting_revision_id": "rrv_01K...",
  "finality": "snapshot",
  "materializations": [
    {
      "method": "inline_webhook",
      "status": "delivered",
      "delivered_at": "2026-08-27T04:01:12Z"
    },
    {
      "method": "file_transfer",
      "status": "available",
      "resource_ref": "rptres_01K..."
    }
  ]
}

The same task can resolve an exact reporting_revision_id or resource_ref, so SDKs do not need a second get_reporting_delivery task. Pagination and filters cover account, media buy, period, health, finality, and revision.

3. Keep the readiness webhook as a doorbell

reporting.delivery_ready remains valuable for low-latency operation. It points to an immutable revision; the SDK verifies it and calls get_reporting_status for authoritative state/resource resolution. Periodic calls to the same task repair missed or duplicate webhooks.

The existing get_media_buys(include_webhook_activity: true) remains the attempt-level debugging surface. A compact reporting_status summary MAY also be included on get_media_buys so an operator viewing a buy can see its health, data_through, and next_expected_at without loading the detailed ledger.

4. Do not require separate acknowledgement and replay tasks in v1

• Consumer acknowledgement is local SDK state by default. A future optional receipt capability can be added when a bilateral use case actually requires seller-visible downstream-commit testimony.
• Sellers automatically retry failed delivery within their advertised policy.
• Producer-hosted immutable resources remain readable for the retention window, so ordinary missed-event repair is a read, not a replay command.
• Destination-only replay can remain a later optional action. If automated recovery is exhausted in v1, get_reporting_status returns action_required with a structured responsible party and recommended action.

This removes acknowledge_reporting_delivery and replay_reporting_delivery from the initial required surface.

The internal model still needs three distinct facts

Simplifying tools must not collapse the reliability model. The seller/SDK still needs to distinguish:

1. Reporting obligation — what period/revision was expected and by when. This is what makes a missing first webhook observable.
2. Reporting revision — the immutable reporting content produced for that obligation. A committed zero-row revision is different from no revision.
3. Materialization — where that revision was exposed and whether that transport succeeded (inline webhook, file transfer, dataset share, or warehouse materialization).

These are wire/data-model concepts behind one read surface, not three things an end user should have to orchestrate.

SDK experience and conformance target

The intended SDK experience is approximately:

await client.reporting.ensure({ account, destination });

const status = await client.reporting.status({ account });
if (status.health === "action_required") {
  surfaceToHuman(status.issues);
}

for await (const revision of client.reporting.consume({ account })) {
  await process(revision.data);
}

consume hides webhook/poll selection, deduplication, manifest/file reads, exact-revision resolution, checksum validation, cursor persistence, and retries. Conformance should grade the observable outcome—no missed committed revision, no duplicate consumer publication, accurate overdue detection, zero-row distinction, and actionable escalation—rather than require applications to call a prescribed sequence of low-level tasks.

Change from the original proposal

Initial required task additions drop from five to one:

• Retain/add: get_reporting_status (summary + list + exact read/resource resolution).
• Reuse: sync_accounts, reporting_webhook, notification_configs[], and get_media_buys.webhook_activity.
• Defer as optional extensions: explicit acknowledgement and destination-only replay.

This keeps #6911's reliability guarantees while making “make reporting work, tell me where I am, and tell me when a human is needed” the primary contract.