From 92740d58aa88104baa66c27008daa9cbb1e8584d Mon Sep 17 00:00:00 2001 From: Brian O'Kelley Date: Sun, 17 May 2026 11:50:20 -0400 Subject: [PATCH] feat(schemas): add media_buy.frequency_capping capability declaration (closes #4640) Co-Authored-By: Claude Opus 4.7 (1M context) --- .../4640-frequency-capping-capability.md | 15 ++++++++++++ .../get-adcp-capabilities-response.json | 23 +++++++++++++++++++ 2 files changed, 38 insertions(+) create mode 100644 .changeset/4640-frequency-capping-capability.md diff --git a/.changeset/4640-frequency-capping-capability.md b/.changeset/4640-frequency-capping-capability.md new file mode 100644 index 0000000000..43d76bbc63 --- /dev/null +++ b/.changeset/4640-frequency-capping-capability.md @@ -0,0 +1,15 @@ +--- +"adcontextprotocol": minor +--- + +feat(schemas): add media_buy.frequency_capping capability declaration (closes #4640) + +Sellers can now declare frequency-capping support in get_adcp_capabilities. Presence of the object means the seller honors `targeting.frequency_cap` and MUST reject caps they cannot enforce rather than silently dropping them. + +Two optional sub-fields let buyers pre-flight validate before submitting: +- `supported_per_units` — entity granularities (devices, individuals, etc.) from reach-unit.json +- `supported_window_units` — duration units (hours, days, campaign) from duration.json + +`enforces_within` from the original RFC was dropped — no SSP can back that attestation cleanly. Per-product overrides for mixed addressable/non-addressable inventory are a likely follow-up. + +A capability-gated `frequency_cap_enforcement` storyboard scenario lands separately under the capability-claim contract pattern (#4637). diff --git a/static/schemas/source/protocol/get-adcp-capabilities-response.json b/static/schemas/source/protocol/get-adcp-capabilities-response.json index 152e529f2c..0d0c7c490c 100644 --- a/static/schemas/source/protocol/get-adcp-capabilities-response.json +++ b/static/schemas/source/protocol/get-adcp-capabilities-response.json @@ -589,6 +589,29 @@ }, "additionalProperties": true }, + "frequency_capping": { + "type": "object", + "description": "Frequency capping capabilities. Presence of this object indicates the seller honors targeting.frequency_cap on packages and MUST reject caps it cannot enforce rather than silently dropping them. Buyers SHOULD inspect supported_per_units and supported_window_units before submitting caps; sellers without these sub-fields populated MAY accept any reach-unit / duration-unit combination they can enforce. Per-product overrides (for sellers with mixed addressable/non-addressable inventory) are a likely follow-up — file a separate RFC if needed.", + "properties": { + "supported_per_units": { + "type": "array", + "description": "Entity granularities the seller can enforce caps against. Values from the reach-unit enum. Omit to indicate all reach-unit values are supported.", + "items": { "$ref": "/schemas/enums/reach-unit.json" }, + "minItems": 1, + "uniqueItems": true + }, + "supported_window_units": { + "type": "array", + "description": "Duration units the seller supports for frequency cap windows. Values must match the duration.json unit enum (e.g., 'hours', 'days', 'campaign'). Omit to indicate all duration units are supported.", + "items": { + "type": "string" + }, + "minItems": 1, + "uniqueItems": true + } + }, + "additionalProperties": true + }, "content_standards": { "type": "object", "description": "Content standards implementation details. Presence of this object indicates the seller supports content_standards configuration including sampling rates and category filtering. Gives buyers pre-buy visibility into local evaluation and artifact delivery capabilities.",