Background
The AdCP schema already uses BrandRef ({ domain, brand_id? }) as the canonical identity primitive for vendors in measurement reporting ((vendor.domain, vendor.brand_id, metric_id)). RFC #4324 (audience activation method) extends the same pattern to activation vendors (Snowflake, LiveRamp, AMC, etc.) and cloud providers (AWS, GCP, Azure).
But other places in the schema reference vendors and products by name in free-text descriptions or string fields, without using BrandRef. This drifts as new vendor mentions land and creates inconsistency for buyers/sellers trying to filter or match on vendor identity.
What this audit should find
- Inline vendor names in description text — e.g.,
description: "...identity provider (ID5, LiveRamp, UID2)..." in tmp/identity-match-request.json line 52. Decide: is this a real reference that should be structured, or is it just illustrative text?
- Free-form fields where structured vendor identity would be cleaner — string fields holding "snowflake" or "liveramp" or "AMC" that should be
BrandRef.
- Adjacent schemas missing a vendor field — places where a vendor identity is conceptually present (clean room operator, signal provider, identity match service) but not modeled.
- Inconsistency between vendor and cloud-provider treatment — places that conflate them or mix them.
Suggested grep starting points
Snowflake, LiveRamp, Habu, InfoSum, Databricks, BigQueryAWS, Amazon Web Services, S3, GCP, Google Cloud, Azure, CloudflareAMC, Amazon Marketing CloudSnap, Meta, Google Ads, TTD
Deliverable
A list of locations + recommendation per location: leave as illustrative text, restructure to BrandRef, or extend schema with new vendor field. Doesn't need to be one big PR — can be a tracking issue with sub-PRs as fixes land.
Context
Surfaced during RFC #4324 discussion. The activation/reporting symmetry and "no enum bottleneck" benefits depend on BrandRef being the consistent vendor identity across the spec.
🤖 Generated with Claude Code
Background
The AdCP schema already uses
BrandRef({ domain, brand_id? }) as the canonical identity primitive for vendors in measurement reporting ((vendor.domain, vendor.brand_id, metric_id)). RFC #4324 (audience activation method) extends the same pattern to activation vendors (Snowflake, LiveRamp, AMC, etc.) and cloud providers (AWS, GCP, Azure).But other places in the schema reference vendors and products by name in free-text descriptions or string fields, without using
BrandRef. This drifts as new vendor mentions land and creates inconsistency for buyers/sellers trying to filter or match on vendor identity.What this audit should find
description: "...identity provider (ID5, LiveRamp, UID2)..."intmp/identity-match-request.jsonline 52. Decide: is this a real reference that should be structured, or is it just illustrative text?BrandRef.Suggested grep starting points
Snowflake,LiveRamp,Habu,InfoSum,Databricks,BigQueryAWS,Amazon Web Services,S3,GCP,Google Cloud,Azure,CloudflareAMC,Amazon Marketing CloudSnap,Meta,Google Ads,TTDDeliverable
A list of locations + recommendation per location: leave as illustrative text, restructure to
BrandRef, or extend schema with new vendor field. Doesn't need to be one big PR — can be a tracking issue with sub-PRs as fixes land.Context
Surfaced during RFC #4324 discussion. The activation/reporting symmetry and "no enum bottleneck" benefits depend on
BrandRefbeing the consistent vendor identity across the spec.🤖 Generated with Claude Code