WG consultation: seller obligation on vendor methodology_version pins (append-only on change) — signal, notification, acceptance

[bokelley]

Consultation: do sellers accept the methodology-pin obligation on vendor metrics?

Raised by @geneticallymodifiedfoodforthought on the #7177 review (question 4). Filing it as a WG item so the answer comes from the seller membership rather than from a schema default.

What #7177 introduces

committed_metrics[] vendor-scope entries gain an optional methodology_version that pins the vendor catalog's measurement.metrics[].methodology_version. The docs say: a vendor methodology change that alters the value definition is a contract change — the seller appends a new committed entry with its own committed_at, never silently substitutes. Nielsen's 3-Minute Qualifier is the motivating case: a crediting-rule change moved AQH by roughly a fifth mid-cycle with zero change in actual listening and nobody renegotiating anything.

#7177 ships this at SHOULD, with an explicit out: where a vendor publishes neither a version string nor change notifications, sellers SHOULD decline to commit a pin. Nothing is graded in conformance yet.

Why it cannot be settled by schema alone

An obligation with no defined signal is aspirational, not enforceable. Two things need answers from the people who would carry it:

1. What is the observable event? Today it is the methodology_version string in the vendor's own get_adcp_capabilities.measurement.metrics[] catalog, which the seller has to poll, plus the agent-level capabilities.changed webhook where the vendor supports it. The measurement block is still x-status: experimental, so vendors are not obliged to publish a version or to notify.
2. Will sellers accept tracking it? Concretely: for every pinned (vendor, metric_id) on every live package, re-read the vendor catalog on a schedule (or subscribe), detect a version change, and append a new committed entry. Sellers with many vendor integrations may reasonably ask that the obligation only bite where the vendor notifies.

Questions for seller members

• Do you accept the append-only-on-change obligation at MUST level if — and only if — the vendor is required to publish methodology_version and fire capabilities.changed on change?
• If a vendor publishes neither, is "decline to pin" the right seller behaviour, or should the buyer be able to pin anyway and accept untracked risk?
• Is polling the vendor catalog acceptable as the fallback signal, and at what cadence?
• Should a methodology change surface to the buyer as a notification (e.g. a media-buy or reporting status event), not just as a new committed entry the buyer discovers on the next read?

Proposed sequencing

1. feat(schema): typed vendor_relationship and play-based coverage denominators for vendor metrics #7177 ships the field at SHOULD (3.2). No conformance grading.
2. When the measurement surface graduates and measurement-verification returns (Re-add preview specialisms (streaming-tv, exchange, retail-media, measurement-verification) #2511, 3.3), require measurement agents to publish methodology_version and to fire capabilities.changed on methodology change — the vendor-side half that makes the seller-side half enforceable.
3. With the answers above, graduate the seller obligation to MUST plus a storyboard step, or leave it advisory.

Refs: #7177, #7150, #2511. Related: #5758 (confidence is a data-quality fact, not a relationship fact — different layer, but the two compound if both are self-declared, which is why the attestation follow-up matters).

[bokelley]

Triage

Classification: Discussion — WG policy consultation
Bucket(s): spec / protocol
Status: ready-for-human
Milestone: 3.3.0

What the experts said:

• ad-tech-protocol-expert: SHOULD→MUST sequencing is correct (DR-0001: can't grade without normative basis); capabilities.changed mechanism exists but the vendor→seller event relay is indirect — Re-add preview specialisms (streaming-tv, exchange, retail-media, measurement-verification) #2511 must close that gap before MUST lands; polling needs a normative floor cadence (24h suggested); buyer-initiated untracked-risk pins should be a seller MUST NOT, not advisory decline; Q4 (buyer notification on methodology change) is the most consequential WG call and is required for makegood_policy remediation to work.
• adtech-product-expert: Nielsen AQH case is representative; the "decline to pin" opt-out is operationally hollow — buyer agents cannot wire-distinguish vendor-doesn't-publish from seller-chose-not-to-commit from pre-feat(schema): typed vendor_relationship and play-based coverage denominators for vendor metrics #7177 entry; MUST graduation risks advisory limbo if Nielsen/comScore/IAS don't ship capabilities.changed (no public commitment today); Q4 should decouple from the seller obligation timeline.

My take: Both experts agree: the sequencing is sound, and the four WG questions are Normative-class decisions requiring seller member consensus — not engineering calls. The single most concrete unresolved gap: the current shape leaves no wire signal distinguishing a deliberate decline from a missing version, which blocks buyer agents from invoking makegood_policy remedies correctly.

Wire question for seller members — implicit vs. explicit decline:

Current #7177 shape (implicit — ambiguous to buyer agents):

{
  "vendor": "nielsen",
  "metric_id": "aqh"
}

methodology_version absent could mean: vendor doesn't publish, seller declined to pin, or entry predates #7177.

Explicit decline signal (proposed — not yet in schema):

  {
    "vendor": "nielsen",
    "metric_id": "aqh",
+   "methodology_tracking": "declined"
  }

Adds a typed status ("declined" | "unsupported" | "pinned") so buyers can distinguish and choose whether to accept untracked-risk inventory.

Seller members: is implicit absence sufficient for your use cases, or do you need the explicit status field before the MUST path can be ratified?

---

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

---

Generated by Claude Code

[bokelley]

Human triage refinement

Keep this in 3.3 and keep #7177's new field at SHOULD/no-conformance for 3.2.

The central rule should be stronger than “append on change”: a pinned methodology version is part of the buyer's contract. A seller must not begin reporting under a changed value definition merely by appending a row. It needs either:

• explicit buyer notification and acceptance; or
• a transition policy the buyer accepted when the package was contracted.

The 3.3 work should separate four stages:

1. vendor publishes a stable methodology version;
2. vendor signals a change and/or supports bounded polling;
3. seller identifies affected live commitments and pauses or marks them pending;
4. buyer accepts, declines, or invokes the agreed remediation/makegood path before the new methodology is used.

Do not standardize an arbitrary polling cadence or a methodology_tracking enum until seller members validate that workflow. pinned is already derivable from the presence of methodology_version; any additional status must communicate an actionable distinction rather than duplicate it.