RFC: Signal epistemic model — framing the questions behind in-flight signal RFCs

[bokelley]

Summary

AdCP's signal schema today models the publishing and authorization of a signal — who published it, who's allowed to resell it, what's discoverable about it. It does not model the epistemic content of the signal: what's being counted, how it was built, against what reference system, in whose vocabulary, with what verifiability.

Two in-flight RFCs (#4472, #4475) and a follow-up question from @lszczesiak on #4475 are each picking off one piece of this gap. This issue exists to frame the full picture so each row-shaped RFC can be evaluated in context, and so the WG can make a small number of shared decisions once instead of re-litigating them per-RFC.

This is not a competing RFC. It does not propose schemas. It exists to organize.

What we already have

The publishing half of the framework is solid:

• signal-source — catalog (verifiable via the provider's adagents.json) vs agent (trust-based)
• signal-catalog-type — marketplace (resold third-party) / custom (agent-built composite) / owned (first-party)
• signal-definition — published via adagents.json; carries value_type, restricted_attributes, policy_categories, allowed_values, range
• adagents.json authorized_agents — the chain-of-authority primitive

A buyer agent can today verify who is authorized to sell what. That part is done and good.

What's not modeled

Layer	Question it answers	Status
Publisher identity	Who stands behind this signal?	✅ adagents.json
Authorization chain	Who can sell / activate it?	✅ authorized_agents
Signal definition	What does it claim to be?	✅ structurally; ❌ shared vocabulary
Identity substrate	What unit is being counted — household, person, device, browser, hashed email, ID-graph node?	❌ Not modeled
Construction methodology	Deterministic match, panel projection, modeled, lookalike off what seed, at what freshness, with what cell confidence?	❌ Not modeled (half of #4472)
Reference frame	Against whose licensed system are boundaries defined — Nielsen DMA, IAB taxonomy v3, RampID, currency, panel?	❌ Not modeled (#4475)
Cross-system fidelity	What survives the trip from discovery to activation when the destination uses a different reference frame?	❌ Not modeled (deployment-side half of #4475)
Verifiability of content	Can a third party validate claimed counts, freshness, or identity unit?	❌ Only authorization is verifiable today

How the in-flight RFCs slot in

• RFC: Structured metadata fields for Projected Broadcast Audiences (PBAs) signals #4472 — proposes `audience_model` covering model vintage, seed data range, ranking reference, cell confidence, market, station, daypart, demographic. Mixes the construction methodology row (general — applies to any modeled audience) with broadcast-specific taxonomy (station/daypart). Worth splitting.
• RFC: Structured geographic market identifiers for signals with market-bounded audiences #4475 — proposes structured market identifier `{ system, id, name }` on the signal item and `market_fidelity` (`exact` / `approximated` / `unsupported`) on `deployments[]`. Picks the reference frame row and the cross-system fidelity row, scoped to geography.
• @lszczesiak's comment on RFC: Structured geographic market identifiers for signals with market-bounded audiences #4475 — observes that the same fidelity mechanic applies to ID-graph translation. That's the identity substrate row.

Each is correct on its own row. The umbrella exists so they get factored consistently rather than producing three incompatible per-dimension types.

Three decisions the WG needs to make once

Every row-level RFC will keep re-asking these until they're settled:

1. Reference-system shape

Do we adopt a single primitive — roughly `{ system, id, version? }` — reused across markets, ID graphs, taxonomies, measurement currencies, panel frames? Or do we ship per-dimension types (`market`, `id_graph`, `taxonomy_version`, ...) that happen to look similar?

A shared primitive forces a consistent enum-extension story across signals, deployments, buy terms, and delivery reporting. Per-dimension types are easier to ship one at a time but invite drift.

2. Vocabulary policy

When a signal claims "Female 25-54," whose vocabulary is that?

• Adopt a canonical taxonomy (e.g., IAB Audience Taxonomy) and require providers to map to it
• Carry the vocabulary by reference (`{ taxonomy: { system, version }, value }`) — the same shape as the reference-frame decision above
• Accept fragmentation and rely on description text (the status quo)

Without a decision here, structured fields just relocate the fragmentation from `description` to typed strings.

3. Verifiability model

Authorization is verifiable today (third-party fetch of adagents.json). Content claims — count, freshness, identity unit, model vintage — are self-reported and unfalsifiable. Is the long-term direction:

• Declarative-only (what every RFC in flight currently assumes)
• Attestation-capable — a primitive for signed claims from independent measurers, layered on top of the declarative fields

The row-level RFCs don't need to solve this, but the umbrella should declare which direction we're heading so we don't paint ourselves into a corner.

Non-goals

• Not a redesign of `adagents.json`, `signal-definition`, or `signal-source` / `signal-catalog-type`. Those are the foundation; this fits underneath them.
• Not a proposal for new schemas — that's what the row-shaped RFCs (RFC: Structured metadata fields for Projected Broadcast Audiences (PBAs) signals #4472, RFC: Structured geographic market identifiers for signals with market-bounded audiences #4475, future ones) are for.
• Not a proposal to block the in-flight RFCs. They should proceed. The umbrella is context for evaluating them, not a gating dependency.

Suggested sequencing

1. Now — WG agreement on the reference-system shape (Decision 1). This unblocks RFC: Structured geographic market identifiers for signals with market-bounded audiences #4475 and any future RFC on identity substrate / taxonomy version.
2. Now-ish — split RFC: Structured metadata fields for Projected Broadcast Audiences (PBAs) signals #4472 along the construction-methodology / broadcast-taxonomy seam. Land the general half against the construction-methodology row.
3. Next — identity-substrate RFC (@lszczesiak's prompt), using whatever shape Decision 1 produces.
4. Later — vocabulary policy (Decision 2) once we have ≥2 row-level RFCs in flight that hit the same vocabulary surface.
5. Research — verifiability / attestation model (Decision 3). Not for this cycle.

Related and adjacent

• The same `{ system, id, version }` shape is already showing up in adjacent work — measurement currency in buy terms negotiation, ID-graph references in identity-match flows. Worth deciding the shape once across all of them.
• Cross-links: RFC: Structured metadata fields for Projected Broadcast Audiences (PBAs) signals #4472, RFC: Structured geographic market identifiers for signals with market-bounded audiences #4475

[EvgenyAndroid]

Implementer voice from a signals-only agent (`adcp.signal-stack.io`) that's already shipping ~half of the epistemic-content surface this umbrella formalizes (via IAB DTS v1.2 `x_dts` labels — provider, audience criteria, privacy mechanisms, precision levels, data sources, inclusion methodology). The framing in this issue maps cleanly onto where we hit ambiguity in our own implementation; happy to vote on the three decisions and contribute reference implementation work once row-level RFCs land.

D1 — shared primitive `{system, id, version?}`: strong yes

The shape is already being reinvented in adjacent work (measurement currency in buy terms, ID-graph references in identity-match, market identifiers in #4475). Each row-level RFC re-discovers it. The migration cost is N PRs across many agents either way — the question is whether the N is "once now" or "once per dimension forever."

Three implementer-side observations:

1. `version?` is load-bearing, not optional polish. Nielsen DMA boundaries differ 2020 vs 2024. IAB Audience Taxonomy v2 ≠ v3. Modeled-audience definitions evolve with each retrain. Without `version`, "is this the same DMA?" becomes "probably." Buyer-agent comparators degrade to fuzzy matching that drifts silently.
2. The fidelity-on-deployments pattern in RFC: Structured geographic market identifiers for signals with market-bounded audiences #4475 generalizes cleanly under D1. A destination that resolves `nielsen_dma` but not `comscore_market` returns `market_fidelity: "unsupported"`. The same shape works for ID graphs (`identity_fidelity: "unsupported"` when destination accepts UID2 but not RampID) and for taxonomies (`taxonomy_fidelity` when destination uses IAB v2 vs v3). Generalizing the deployment-side fidelity flag is itself a reason to vote shared primitive — per-dimension fidelity flags multiply.
3. Buyer-agent comparator under shared primitive: `a.system === b.system && a.id === b.id && (a.version ?? null) === (b.version ?? null)`. One loop, works everywhere. Under per-dimension types: N loops, drifts.

D2 — vocabulary policy: carry by reference

Falls out naturally from D1. `{taxonomy: {system, version}, value}` is the same shape. AdCP shouldn't pick taxonomy winners; let buyer agents filter to canonical (`taxonomy.system === "iab_audience"`) or handle provider-specific themselves.

Less coercive too — providers with genuinely richer or differently-scoped taxonomies (panel-based age buckets, broadcast-currency demos) don't have to map down to IAB just to be representable on the wire.

D3 — verifiability: declarative-only now, attestation extension hook designed in

The attestation infrastructure (#4205 RFC 9421 webhook signing chain-of-custody, #4206 JWKS adoption baseline) is exactly the on-ramp problem you reframed earlier this month — installed base of live buyer agents is ~empty, so requiring attestation is premature. But the declarative shape should have an obvious extension point for `attestations: [{measurer: {system, id}, claims: [...], signature}]` later, without breaking the existing fields. "Don't paint into the corner" applies here directly.

Row-level RFCs

• RFC: Structured metadata fields for Projected Broadcast Audiences (PBAs) signals #4472 split — agreed. Construction methodology (`model_trained_at`, `seed_data_from/to`, `ranking_reference`, `cell_confidence`, `demographic`) is general for any modeled audience. Broadcast-specific (`station`, `daypart`) is a sibling RFC. Mixing pollutes general modeled-audience schema with broadcast shapes.
• RFC: Structured metadata fields for Projected Broadcast Audiences (PBAs) signals #4472's `demographic` field is D2 in miniature. Whose age buckets, whose gender enum? If D2 lands as "carry by reference," demographic naturally becomes `{taxonomy: {system, version}, value}` — same shape as everything else.
• RFC: Structured geographic market identifiers for signals with market-bounded audiences #4475 benefits massively from D1 landing first. Its proposed `system` enum (`nielsen_dma | nielsen_msa | omb_msa | comscore_market | zip_aggregate | custom`) IS the shared-primitive shape. If D1 punts, RFC: Structured geographic market identifiers for signals with market-bounded audiences #4475 ships its own enum, the identity-substrate RFC ships its own `graph` enum, the taxonomy-version RFC ships its own `taxonomy` enum, and AdCP owns N parallel enum-extension surfaces forever.
• @lszczesiak's ID-graph follow-up slots in as the third sibling. `identity: {system: "ramp_id" | "uid2" | "id5", id, version?}` mirrors `market: {system, id, version?}`. The fidelity-on-deployments mechanism transfers cleanly.

Sequencing endorsement

Your suggested order looks right: D1 now → split #4472 → identity-substrate RFC under whatever D1 produces. D2 / D3 sequence later, but D3 needs an extension hook designed into D1 from the start.

Implementation offer

We're already encoding much of this via DTS v1.2 (x_dts blocks on every signal carry provider, audience criteria, privacy mechanisms, precision levels, data sources). Adopting the canonical shape from D1 would let our signals federate cleanly with the next wave of buyer agents. Happy to contribute reference implementation once row-level RFCs land — particularly the deployment-side fidelity flag, which is the most novel mechanism and the one most likely to surface implementation edge cases.

[EvgenyAndroid]

On process — sharing a concrete proposal since the 3.1 beta clock is real (milestone due 2026-05-29, ~13 days).

The unblocker question is whether D1 (`{system, id, version?}` shape) lands in 3.1.x as foundational schema so row-level RFCs (#4472, #4475, the identity-substrate RFC @lukasz will file) build against a stable primitive in their 4.0 window — OR whether D1 ships alongside the first row-level RFC in 4.0 and the WG re-litigates the shape inside each row review.

Strong implementer preference for the first option. The cost of getting the shape wrong in 3.1.x is one unused schema. The cost of re-litigating it three times across row-RFCs is real WG time at a moment when there are 68 open 3.1 issues.

Proposed sequencing

Window	Action	Owner / Status
Days 1–3 (now → 5/19)	Strawman draft-PR — concrete static/schemas/source/core/system-reference.json proposing the {system, id, version?} shape, plus system-reference-fidelity.json enum (exact / approximated / unsupported) generalizing the #4475 deployment-side mechanism. Concrete is faster than abstract — gives the WG something to thumbs-up or counter-propose in one review pass.	Happy to take this. Drafted as discussion artifact, not a merge bid; needs-wg-review label gates the eventual merge.
Days 4–7 (5/19 → 5/22)	D1 vote on the strawman. Comments-as-vote on the PR. Default-merge if quorum + no normative objection.	@bokelley calls quorum.
Days 8–13 (5/22 → 5/28)	D1 lands in 3.1.x patch line. Patch-eligible — additive schema, no breaking change to 3.x agents; type is referenced by 4.0 schemas but adds zero normative constraint on 3.x callers.	Standard release flow.
Post-3.1-beta	Row-level RFCs proceed against the decided D1 shape. #4475 PR adopts the primitive for market + uses the fidelity enum on deployments. #4472 splits as planned; construction-methodology half adopts the primitive for taxonomy / ranking_reference. @lukasz's identity-substrate RFC files using both.	RFC authors.
Open	D2 (vocabulary) + D3 (verifiability) — research-tier, no 3.1 / 4.0 commitment. Conversation continues on this issue but doesn't gate either milestone.	This issue stays open as the parking lot.

Why strawman-first

• It's what worked for fix(schema,skill): align HMAC framing to RFC 9421 default in reporting-webhook, auth-scheme, call-adcp-agent SKILL.md #4271 closing Storyboard / SDK skill on-ramp inventory: HMAC vs RFC 9421 #4270's inventory inside ~48h. Concrete diff → fast triage → faster decision than abstract spec text.
• A draft PR labeled needs-wg-review makes the conversation surface concrete: comment threads attach to specific lines, not abstract bullet points.
• Risk-bounded: if the WG counter-proposes a different shape, the strawman is one file — close it and re-draft. No sunk-cost.

What I'll have in the strawman

1. core/system-reference.json — the {system, id, version?} primitive, with system as an open string (no enum constraint at the primitive level; constraint lives in each consuming schema's oneOf).
2. enums/system-reference-fidelity.json — exact | approximated | unsupported, generalizing the RFC: Structured geographic market identifiers for signals with market-bounded audiences #4475 market_fidelity shape.
3. core/system-reference.md doc — non-normative notes covering: when to use, when NOT to use (vendor-specific IDs that don't deserve a system axis), how the fidelity enum interacts with deployments.
4. No row-level adoption in this PR — that's row-RFC scope. Strawman is the shape only.

Will file tomorrow unless you'd prefer a different shape — e.g., D1 in 4.0 with the re-litigation cost accepted, or a longer discussion window before the strawman. Easy to adjust; the implementer-side priority is just knowing which way the WG is leaning before we wire D1 into our signal emission.

[EvgenyAndroid]

Strawman draft-PR is up: #4622. Per the process proposal above — discussion artifact, not a merge bid. Adds the system-reference primitive + system-reference-fidelity enum with no row-level adoption. Design choices (open system string, optional version, fidelity as separate enum) are called out explicitly in the PR body for line-level review.

The four open questions for WG (shape / open-vs-closed / fidelity naming / 3.1.x-vs-4.0 landing) are at the bottom of the PR description. Happy to revise on any signal.

[lukasz-pubx]

D1 — I would also support a shared primitive but I have a feeling that using the term id is confusing in {system, id, version?}, I would maybe suggest value i.e. {system, value, version?}. In the shared fidelity enum proposed I would consider adding convertedoption to["exact", "approximated", "unsupported"]` for when a exact conversion has taken place i.e. Nielsen to Comscore or ID5 to RampID. I'm not sure if in this case it should be indicated somehow from what to what was the conversion and/or how was it done i.e. ID Graph / by name / custom?

[EvgenyAndroid]

Thanks for the D1 vote @lukasz-pubx — strong convergence signal. Folded both pieces of your feedback into a revision push on #4622 (5a0ebfe7):

• id → value — accepted. Three reasons: (1) AdCP's existing *_id fields point at AdCP-issued entities with AdCP lifecycle, so reusing id for external-system values creates a connotation collision; (2) taxonomy authors (IAB) call them "values"/"terms" — value matches established vocabulary; (3) value is cross-axis-neutral, id is identity-axis-coded.
• converted + structured conversion descriptor — accepted. Factored your two questions as separate concerns:
  • Fidelity enum (exact | converted | approximated | unsupported) answers "how preserved?"
  • New core/system-reference-conversion.json answers "via what?" with {from, to, method, method_details?} where method ∈ id_graph | name_match | crosswalk | custom.
  • The structure is REQUIRED when fidelity is converted, OPTIONAL when fidelity is approximated (so buyers can see WHY a deployment is approximated, not just that it is).

One open question I left in the PR thread that's worth surfacing here: are those four method values the right set for the ID-graph cases you'd want to model, or are there method types worth adding — inferred (ML-predicted match), aggregation (geographic upscaling), sampled (panel projection)? Lockin the method enum now is cheaper than post-row-RFC adoption.

Strawman is still draft and still labeled discussion-only — happy to revise further or close + re-draft if the WG wants a fundamentally different shape.