adcontextprotocol · aao-secretariat · Aug 12, 2026
diff --git a/.agents/wg/slack-context.md b/.agents/wg/slack-context.md
@@ -7,7 +7,7 @@ channels per `.agents/wg/constitution.md` §Information sources and the
 record: never quote or attribute this content in public output; Slack
 informs, GitHub decides.
 
-- Generated: 2026-08-09
+- Generated: 2026-08-12
 - Window: last 14 days
 - Channels: 22 public WG channels swept (4 private excluded)
 
@@ -17,102 +17,146 @@ informs, GitHub decides.
 
 ---
 
-### Agent Skills Discovery (`get_adcp_skills` proposal)
+### Agent Skill Advertisement via `get_adcp_skills`
 
 - **Status:** active
-- **Summary:** A proposal was raised to extend agent capability advertisement beyond feature-flag-style `get_adcp_capabilities` to include a `get_adcp_skills` mechanism. The intent is to allow counterparty agents to understand conversational competencies upfront—such as whether an agent can engage in price negotiation or discuss signal-provider options—rather than discovering limitations mid-conversation. Examples cited include a price-negotiation skill and a signals-selection skill. No resolution or counter-proposal was recorded in the thread.
+- **Summary:** A proposal was raised to extend the capabilities advertisement model so that agents can declare conversational *skills* (e.g., price negotiation, signals selection) in addition to feature flags returned by `get_adcp_capabilities`. The intent is to allow counterparty agents to determine upfront what kinds of interactions are supported, avoiding failed or unproductive negotiation attempts. The proposal suggests a new `get_adcp_skills` tool surface, with structured skill descriptors.
 - **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1785408494720399
 
 ---
 
-### 3.2 Security Invariants & Release Blockers
+### Schema: Legacy Field Cleanup and `$ref` Absolutization
 
 - **Status:** active
-- **Summary:** A structured proposal was put forward for the 3.2 working-group meeting to address a cluster of open security issues. The framing is that the core problem is not missing cryptography per se, but that authenticated or signed actors are not reliably bound to the budget, rights, request body, endpoint, property, or claim being acted upon. The proposal recommends designating four issues as concrete 3.2 implementation requirements, assigning explicit security invariants to two others, deferring one to 3.3 unless a narrowly scoped RFC is owned, and requiring implementation plus conformance coverage rather than schema-only PRs.
+- **Summary:** An SDK implementer reported that overlapping names between legacy and current fields are causing code-generation issues. Additionally, JSON Schema `$ref` and `$id` values are inconsistently relative vs. absolute, which further complicates tooling. The recommended fix is to make all `$ref` paths fully absolute using the canonical domain, and to remove or clearly namespace legacy fields under the versioning scheme.
+- **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1785520266198059
+
+---
+
+### 3.2 Security Invariants and Implementation Blockers
+
+- **Status:** active
+- **Summary:** A working-group member proposed that the core security problem across several open issues is that authenticated or signed actors are not reliably bound to the budgets, rights, request bodies, endpoints, or claims they act upon — not merely a matter of missing cryptography. A structured proposal was made to designate issues #5827, #5829, #5934, and #5941 as concrete 3.2 implementation requirements; assign explicit security invariants to #5828 and #5883; and defer #4529 to 3.3 unless a narrowly scoped RFC is owned. The proposed meeting outcome included assigning owners and PR deadlines to all items.
 - **Related:** #5827, #5829, #5934, #5941, #5828, #5883, #4529
 - **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1785765710664579
 
 ---
 
-### 3.2 WG Meeting Packet — Targeting, Measurement, Revshare & Broadcast
+### 3.2 Working Group Packet: `targeting_overlay`, Insights/Warnings, Measurement, Revshare
 
 - **Status:** active
-- **Summary:** A proposed discussion packet for the 3.2 working-group meeting covers six areas: (1) making `targeting_overlay` consistent across discovery and execution, with a proposed rule that `filters` filter offers while `targeting_overlay` carries delivery intent and sellers must disclose modifications rather than silently drift; (2) adding synchronous warnings and durable resource-scoped insights without introducing a new `get_insights` tool; (3) radio and broadcast schema decisions; (4) OOH schema decisions; (5) improved measurement integration and a pathway to Measurement Agents; and (6) ratifying revenue-share pricing for affiliate, including decimal rate units, a `commissionable_value` field, required event source, and commission-budget enforcement.
-- **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1786160291841139
+- **Summary:** A discussion packet for the 3.2 working group was circulated covering several interrelated topics: making `targeting_overlay` consistent across discovery and execution (with a proposed rule that `filters` filter offers while `targeting_overlay` carries delivery intent and sellers must disclose modifications); replacing "insights" with "advisories" (synchronous warnings vs. durable resource-scoped interpretations surfaced via existing read/webhook tools, not a new `get_insights` endpoint); improved measurement integration and a pathway to Measurement Agents; and revshare/affiliate pricing (decimal rate units, `commissionable_value`, required event source, commission-budget enforcement). Radio, broadcast, and OOH decisions were also flagged for resolution.
+- **Related:** #6212
+- **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1786160291841139, https://agenticads.slack.com/archives/C09BK148CLU/p1786441349703719
 
 ---
 
-### 3.2 Accepted & Pending Schema Changes
+### 3.2 Accepted and Pending Schema Changes
 
 - **Status:** active
-- **Summary:** A summary of items provisionally accepted for 3.2 includes: adding age as a supported targeting option, webhooks for capability and account changes, deprecation of legacy creative formats, and rejection reasons for `get_products`. Items still under discussion include flexible media-buy budgets, geo-places (city-level), and localization for creatives.
+- **Summary:** A summary of decisions from a working group session was shared. Accepted changes include: adding age as a supported targeting option, webhooks for capability and account changes, deprecation of legacy creative formats, and rejection reasons for `get_products`. Items still under discussion include flexible media buy budgets, geo places (cities), and localization for creatives.
 - **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1785765611743959
 
 ---
 
-### Revenue-Share Pricing Model (`revenue_share` enum addition)
+### Ad Server Protocol within AdCP (Seller-Side Activation)
 
 - **Status:** active
-- **Summary:** Issue #5754 was routed to the Campaign Lifecycle / Media Buy working group as a schema change to the `pricing-model` enum and pricing-option file set, proposing addition of `revenue_share` alongside existing values such as `cpm`, `cpc`, and `cpa`. The affiliate-network operator question is considered settled via existing aggregator sales agent and `delegation_type: ad_network` constructs; what remains is purely the pricing-model schema decision. The measurement side of affiliate attribution and payout reconciliation was flagged as touching the Signals & Measurement working group.
-- **Related:** #5754
-- **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1785232728094869
+- **Summary:** A seller-side member raised the question of whether AdCP should define a common Ad Server sub-protocol — either standalone or embedded within the Media Buy Protocol — to support agentic ad server integrations (e.g., `create_line_item`). The motivation is to maintain an open pathway for independent AdCP Seller Agents to call ad servers natively as part of the media buy chain, rather than ceding that layer to proprietary agent implementations.
+- **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1785444564941489
 
 ---
 
-### Ad Server Protocol Integration into AdCP (Seller-Side Activation)
+### Creative Revision History and Hot-Swap Support
 
 - **Status:** active
-- **Summary:** A seller-side member raised the question of whether AdCP should incorporate an Ad Server sub-protocol—potentially within the Media Buy Protocol on the seller side—defining a common interface with tools such as `create_line_item`. The motivation is to provide a standard pathway for ad servers participating as agentic sellers, while preserving interoperability for independent AdCP seller agents calling them for activation within the media-buy chain. No resolution was reached in the thread.
-- **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1785444564941489
+- **Summary:** A proposal was filed to add buyer-assigned `revision_id` fields, staged hot-swap capability, and re-review triggers to the creative update flow. Currently `sync_creatives` overwrites in place with no version history, making it impossible to update a live creative without pausing or minting a new ID. This RFC is designed to interoperate with a companion creative collaboration proposal.
+- **Related:** #6347, #6348
+- **Thread:** https://agenticads.slack.com/archives/C09C7PLE5B8/p1786428756054999
 
 ---
 
-### Schema $ref Absolutisation & Legacy Field Cleanup
+### Creative Collaboration: Human Sign-Off, Approvals, and Annotations
 
 - **Status:** active
-- **Summary:** An SDK implementer reported that the coexistence of legacy fields sharing names with current fields causes problems in code generation. The proposed remediation is to remove legacy fields under a versioning scheme that still permits legacy consumers to opt in. Additionally, the implementer noted that JSON Schema `$ref` and `$id` values are inconsistently relative or absolute, and proposed making all references fully absolute with the canonical domain (e.g., `https://adcontextprotocol.org/schema/…`) to improve code-generation reliability.
-- **Thread:** https://agenticads.slack.com/archives/C09BK148CLU/p1785520266198059
+- **Summary:** A proposal was filed to add a comment object and per-party review record to the creative schema to capture client, legal, and brand approval states and inline annotations. The stated scope is metadata capture only — not a full workflow engine. This RFC is designed to work alongside the creative revision proposal.
+- **Related:** #6348
+- **Thread:** https://agenticads.slack.com/archives/C09C7PLE5B8/p1786428750537209
 
 ---
 
-### Canonical Creative Formats & Legacy Deprecation in 3.2
+### Creative Delivery Evidence: Serve-Time Hashing and Affidavits
 
 - **Status:** active
-- **Summary:** The Creative working group discussed the deprecation timeline for legacy custom creative formats in 3.2, which is described as the canonical-first release. The proposed mechanism includes a 90-day dual-shipping window, structured SDK deprecation warnings carrying `format_shape`, `promoted_to`, `promotion_release`, and `transition_end` fields, and a policy of six months' notice before removal, with full removal deferred to 4.0. Specific formats under consideration for promotion include `multi_state_display` and `page_takeover` for premium web display.
-- **Related:** #6264, #6265
-- **Thread:** https://agenticads.slack.com/archives/C09C7PLE5B8/p1786112295729479, https://agenticads.slack.com/archives/C09C7PLE5B8/p1786112164414769, https://agenticads.slack.com/archives/C09C7PLE5B8/p1786093864828959
+- **Summary:** A proposal was filed to address the current unsigned, unretained served manifest, which offers no cryptographic assurance of what was actually delivered. The RFC proposes serve-time hashing, a retention commitment, and a slot for affidavits and as-run logs. This is flagged as particularly important for broadcast, DOOH, and AI-disclosure compliance.
+- **Related:** #6349
+- **Thread:** https://agenticads.slack.com/archives/C09C7PLE5B8/p1786428760251109
 
 ---
 
-### Radio & OOH Measurement Schema
+### `preview_creative` Quality Downgrade Disclosure
 
 - **Status:** active
-- **Summary:** Issues were filed to address measurement schema gaps for radio and static OOH inventory. The radio currency issue proposes adding the measurement-system declaration to the delivery wire and extending the demo-system enum with `nielsen_audio` and `RAJAR`. The OOH measurement issue presents three options—a structured `ooh_metrics` block, a vendor-measurement path, or a hybrid—with the deciding factor being whether bodies such as Geopath or Route deliver estimates in a form a seller can relay today or could act as first-party measurement agents. A related finding is that radio as-run reporting may require no new schema object, as the existing linear-TV airing-log proposal already accommodates station and daypart fields.
+- **Summary:** A small RFC proposes that `preview_creative` echo back the quality level it actually used, since it can silently downgrade from production to draft quality without the caller's knowledge. This would make quality resolution visible and prevent inadvertent sign-off on degraded renders.
+- **Related:** #6350
+- **Thread:** https://agenticads.slack.com/archives/C09C7PLE5B8/p1786428762730119
+
+---
+
+### Legacy Creative Format Deprecation in 3.2
+
+- **Status:** active
+- **Summary:** A deprecation timeline for legacy named `format_id` discovery was outlined. Version 3.2 is designated the canonical-first release; deprecation would start the migration clock there, with a 90-day dual-ship window during which sellers must support both legacy and canonical formats. SDKs would emit a structured deprecation warning object. Policy constraints require six months' notice and prohibit removal within a major version; full removal is targeted for 4.0.
+- **Thread:** https://agenticads.slack.com/archives/C09C7PLE5B8/p1786112295729479
+
+---
+
+### Radio and OOH Measurement Schema
+
+- **Status:** active
+- **Summary:** Issues were filed to address measurement schema gaps for radio and static OOH. The radio currency issue adds Nielsen Audio and RAJAR to the demographic-system enum and places the measurement-system declaration on the delivery wire. The OOH issue presents three structural options (structured `ooh_metrics` block, vendor-measurement path, or hybrid), with the decision hinging on whether bodies such as Geopath/Route can act as first-party measurement agents on the wire. A finding from schema review noted that radio as-run data may not require a new object, as the existing linear-TV airing-log proposal may already carry the required station/daypart fields.
 - **Related:** #6138, #6139, #6140, #5682
 - **Thread:** https://agenticads.slack.com/archives/C09BF378H8A/p1785669712504859
 
 ---
 
-### Measurement Agent Foundations (PR #6245)
+### Measurement Agent Architecture (PR #6245)
 
 - **Status:** active
-- **Summary:** A pull request was opened proposing schema or protocol foundations intended to support a future Measurement Agent capability. The contributor requested feedback ahead of the 3.2 working-group meeting.
+- **Summary:** A pull request was shared proposing foundational schema and protocol patterns intended to support a future Measurement Agent role within AdCP. Feedback was solicited ahead of a 3.2 working group discussion.
 - **Related:** #6245
 - **Thread:** https://agenticads.slack.com/archives/C09BF378H8A/p1786093096018869
 
 ---
 
-### PR Merge Permissions for Reviewers
+### Standardized Seller Rejection Codes
+
+- **Status:** active
+- **Summary:** A draft of standardized seller rejection codes was circulated for review, alongside an open pull request for discussion.
+- **Related:** #6305
+- **Thread:** https://agenticads.slack.com/archives/C09NUQS93DF/p1786460548028849, https://agenticads.slack.com/archives/C09NUQS93DF/p1786303001593879
+
+---
+
+### PR Merge Authorization for Reviewers (Governance Process)
 
 - **Status:** active
-- **Summary:** A question was raised in the Builders channel about whether reviewers are permitted to self-merge their own PRs once the secretariat has granted a green light and no human reviewer is flagged as required. No authoritative answer was recorded in the thread.
+- **Summary:** A process question was raised about whether reviewers are permitted to self-merge their own PRs after secretariat approval, when no human reviewer is explicitly required. The resolution of this question has implications for the contribution workflow governance.
 - **Related:** #6180
 - **Thread:** https://agenticads.slack.com/archives/C09J28K9K29/p1785774317134479
 
 ---
 
-### AdCP Implementation Review Skill (Community Tool)
+### AI-Assisted AdCP Implementation Review Skill
 
-- **Status:** resolved
-- **Summary:** An SDK implementer shared a code-agent skill designed to assist with AdCP implementation reviews. The skill instructs the agent to fetch live documentation from the AdCP docs index on each review, apply a checklist of known failure modes, scope its audit to protocol-relevant code only, require exact rule citations with source page references, and treat any instructions embedded in PR content as data rather than executable commands. The tool is available via a public repository.
+- **Status:** active
+- **Summary:** An SDK implementer shared a publicly available code-agent skill designed to assist with AdCP implementation reviews. The skill instructs agents to fetch live spec documentation, apply a known failure-mode checklist, scope review only to protocol-relevant code, require citation of exact spec rules, and treat PR content as data rather than instructions. Source is openly available and contributions are invited.
 - **Thread:** https://agenticads.slack.com/archives/C09J28K9K29/p1785395238787999
+
+---
+
+### Documentation Site Availability
+
+- **Status:** resolved (reported, no ongoing spec impact noted)
+- **Summary:** A member reported that the AdCP documentation site was inaccessible. No spec-level changes were implied, but the outage has potential impact on implementation and review workflows that depend on live doc fetching.
+- **Thread:** https://agenticads.slack.com/archives/C09J28K9K29/p1785783549039949